Также есть способы обхода (не решения, а именно обхода) проблемы большой карты ресурсов: 2.Хранение кэша в оперативной памяти (memCached) 3.Раскидывание ресурсов по разным контекстам (не всегда удобно, поскольку при необходимости загружать одни и те же ресурсы в разных контекстах придётся либо плодить символические ссылки, либо использовать (OnPageNotFound + sendForward)) Эти варианты обхода практически бесполезны. Во-первых, проблема не только в хранении этого большого кеша, а в самой генерации кеша. Ведь каждый раз при сбросе кеша MODX должен в базе данных обойти все документы и нафигачить их в кеш. Когда у вас будет под сотню тысяч документов, средний сервер просто не справится с этой задачей, кеш соберется не полностью и сайт просто сломается (из-за попытки подгрузки невалидного php-кода). Во-вторых, раскидывая документы по разным контекстам, объем задач по генерации кеша не уменьшается, так что это только снижает объем загружаемого кеша при заходе на конкретный контекст, но нагрузка на сервер при генерации кеша хоть и не на много, но все же увеличится. В-третьих, сколько же вам контекстов понадобится, чтобы раскидать по ним пару сотен тысяч документов? В общем, на сегодня, эти проблемы решает только cacheOptimizer. И да, при обновлении MODX его надо переустанавливать, без этого никак. Не знаю планируют ли разрабы MODX-а что-то придумать на этот счет, но я решение придумал еще в 2011-ом. Там конечно картинок уже нет и код местами плохочитаемый, но суть уловить можно. А вообще, тема кеширования в MODX на столько сложная, что вот так небольшими топиками о ней рассуждать почти нет смысла. Там книги писать можно.

Смотрите лог ошибок веб-сервера. Возможно, у Вас синтаксическая ошибка выше этой строки (сама приведённая строка ошибок не содержит). Либо у вас событие (OnResourceDelete) не генерируется. Проверьте наличие галки напротив (OnResourceDelete) на вкладке «Системные события» плагина. А вообще, в обработчик (OnResourceDelete) уже передаётся переменная $id. Т.е. в плагине её получать не нужно — сразу её можно использовать. Для справки: в обработчик (OnResourceDelete) передаются следующие переменные: $id — идентификатор удаляемого ресурса $children — массив идентификаторов дочерних ресурсов $resource — ссылка на объект modResource, представляющий собой удаляемый ресурс

Классическая схема физического хранения изображений галереи — набор папок для каждого ресурса, внутри — графические файлы. Для отображения на сайте изображений некоторого ресурса просто-напросто берём графические файлы из папки, соответствующей нашему ресурсу. Просто и логично. Но в моём случае: а) каждый графический файл может быть связан с одним и более ресурсами одновременно (а в некоторые моменты времени может быть не связан ни с одним из ресурсов) б) каждый графический файл имеет с десяток характеристик (по которым будет выполняться сортировка/фильтрация) в) каждый графический файл будет иметь комментарии пользователей г) каждый графический файл будет иметь свою собственную страницу на сайте (с описанием, характеристиками, комментариями и пр.) Очевидно, что простым хранением графических файлов в тех или иных папках здесь не обойтись — нужно ещё хранить данные о каждом изображении. Возможны 2 варианта: ВАРИАНТ 1. Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами Преимущества: 1.Обслуживание, управление и формирование характеристик изображений выполняется стандартными средствами modx (характеристики, вычисляемые автоматически путём анализа изображения, легко реализуются на уровне плагинов) 2.Загрузка страниц, посвящённых изображениям, будет выполняться без каких-либо проблем стандартными средствами modx (как и страницы любых других ресурсов) 3.Легко прикрутить готовые компоненты для работы с комментариями (при хранении в собственных таблицах придётся писать свою систему комментариев) 4.Число просмотров, число комментариев и прочие realtime-характеристики будут обрабатываться теми же средствами, которые работают в отношении прочих ресурсов Недостатки: 1.Быстрее себя проявит проблема большой карты ресурсов 2.Чуть медленнее будет выполняться фильтрация и сортировка по TV этих изображений. Впрочем это проблема/особенность архитектуры modx (а вернее, т.н. универсальных БД), а никак не проблема выбранного варианта хранения данных изображений ВАРИАНТ 2. Информация о каждом изображении хранится в отдельной таблице Преимущества:

1. Проблема большой карты ресурсов будет проявляться в существенно меньшей степени
2. Чуть быстрее будет работать фильтрация и сортировка по характеристикам изображений Недостатки: 1.Интерфейс для формирования и просмотра характеристик изображений придётся разрабатывать свой 2.Систему комментариев придётся разрабатывать свою 3.Существенно урезаются стандартные возможности modx по работе с изображениями на уровне чанков и сниппетов (например, использование тегов [[~id]]) 4.Для изображений придётся разрабатывать отдельную систему управления числом просмотров, числом комментариев и прочими realtime-характеристиками. Либо расширять возможности существующей системы (работающей со стандартными ресурсами modx) в направлении использования пользовательских таблиц. — Склоняюсь к первому варианту. В случае с отдельной таблицей дофига всего писать придётся (и всё написанное придётся постоянно корректировать синхронно с изменениями архитектуры/ядра и логики работы modx). Ваше видение ситуации? Собственно, интересует не только оптимальный с вашей точки зрения вариант, но и другие ньюансы и потенциальные проблемы (в обоих вариантах), которые я не учёл.

До тех пор, пока в modx не появится настройка «cache_resource_map», этот вопрос не потеряет актуальности. 1.Ваше, Николай, решение — патч СacheOptimizer, который меняет оригинальные исходные файлы modx (оригинальный код) и соответственно, после обновления modx этот патч нужно переустанавливать (так ?) Также есть способы обхода (не решения, а именно обхода) проблемы большой карты ресурсов: 2.Хранение кэша в оперативной памяти (memCached) 3.Раскидывание ресурсов по разным контекстам (не всегда удобно, поскольку при необходимости загружать одни и те же ресурсы в разных контекстах придётся либо плодить символические ссылки, либо использовать (OnPageNotFound + sendForward)) Текущая версия modx — 3.3.5. В настройках кэширования ничего нового. По-прежнему отключать можно только карту псевдонимов. На сегодняшний день появились ли новые способы решения сабжевой проблемы? Планируют ли разработчики modx добавить опциональное отключение карты ресурсов на уровне движка ?

Всем привет. Разрабатываю небольшой плагинчик для отлавливания удаляемых ресурсов (OnResourceDelete) и проблема в том что не могу поймать id удаляемого ресурса Делаю так $id = $modx->resource->get('id'); но в итоге все что после этой строки не выполняется, по всей видимости ошибочная строка. Пробовал выводить в лог ошибок $modx->resource->get('id'); — пусто

Пожалуйста:)

не текущую использует точно, спасибо, так и есть!

А это уже изучайте modxclub.ru/topics/vse,-chto-vyi-xoteli-znat-o-proczessorax,-no-boyalis-sprosit-1563.html и modxclub.ru/blog/dokumentatsiya-dlya-spetsialistov/258.html А процессор надо смотреть basket/web/orders/products/getdata. Там как раз для примера есть формирование суммы и т.п.

так не запускается: @:~/www/vapor$ php vapor/vapor.php Could not open input file: vapor/vapor.php Если ls -la vapor/vapor.php выводит файл, то я не знаю по какой причине может не выполняться php vapor/vapor.php Я именно так и собираю. Единственное, попробуйте прописать полный путь, то есть php /path_for_site/vapor/vapor.php А то может пых-пых как базовую директорию не текущую использует.

Добрый день. Заметил такой баг в снипете при попытке $modx->makeUrl(111); Url формируется, но при этом все равно получаю ошибку — 111 was requested but no alias was located. Чистил, проверял кэш context.cache.php, все alias на месте. Кто сталкивался, помогите?