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

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

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

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

А это уже изучайте 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 на месте. Кто сталкивался, помогите?

Вопрос не содержал иного, чем «из консоли», по ssh, соответственно прод каким еще админом? проверь стоит ли у тебя vapor — спасибо, не смешно. я бы советовал переносить сайт стандартным способом — еще раз спасибо.

Под админом, и проверь стоит ли у тебя vapor, я бы советовал переносить сайт стандартным способом, по крайней мере у меня наблюдались глюки и ошибки в дальнейшем использование,

так не запускается: @:/www/vapor$ php vapor/vapor.php Could not open input file: vapor/vapor.php @:/www/vapor$ не смог отредактировать предыдущий коммент, извините.