Поменяй на xPDOMemCached и все. Поправочка — cache.xPDOMemCached И еще момент: чтобы сразу есть настройки, которые необходимо и в сам конфиг-файл переносить. Дело в том, что для чтения системных настроек из базы данных требуется инициализация самого MODX-а. Это звучит очень логично, но не все на этом внимание заостряют. Так вот, инициализация требует предварительного чтения конфигов. И вот что получается — пока MODX не получил данные из базы данных, он использует конфиги файловые, в том числе и значения по умолчанию. А так как настройка cache_handler=cache.xPDOMemCached хранится в базе данных, то в момент инициализации MODX еще ничего о ней не знает, и соответственно использует стандартный файловый кеш-провайдер. И получив настройки из БД, он только потом очухивается, и начинает использовать Memcached. Но до этого успевает записать конфиги в файлы, и вообще каждый раз при старте читает конфиги из файлов. Вот чтобы этого не происходило и чтобы он сразу использовал Memcached, зайди в core/config/config.inc.php и в $config_options пропиши эту настройку тоже: $config_options = array ( "cache_handler" => "cache.xPDOMemCached", ); Вот тогда он сразу будет мемкешед юзать.
ну событие сработает один раз когда документ сохраняем, потом из memcache кеш уйдет и тю тю… кеша нет
Кстати, ты memcache ведь используешь? А почему не memcached? Вот сравнительная статья.
да я пока на файловый перешел, чтоб только плагин мне тут мусорил…
Кстати, имей ввиду, что еще в мемкеш можно объекты сохранять. Только там есть тонкости. Нельзя туда сохранить, к примеру, дескриптор соединения с базой данных. Есть в общем ООП-шные методы __sleep() и __wakeup(). __sleep() сработает прям перед сохранением (автоматически). В нем можно будет удалить переменные $modx и т.п., а __wakeup() сработает автоматически, когда будешь получать объект из кеша (в этот момент ему можно будет опять присвоить $modx). Тоже может пригодиться для тюннинга.
Пожалуй, я тоже сейчас попробую это сделать, давно хотел.
А что тебя не устраивает? Наоборот правильное событие. Если документ кешируемый и не был еще закеширован, тогда этот плагин и сработает. А если уже закеширован, то у тебя nginx будет отдавать страницу и все.
А зачем отдельная инициализация мемкеша? Он же в составе MODX-а идет. По умолчанию в настройках MODX-а указано cache_handler=xPDOFileCache, то есть используется файловый кеш-провайдер. Поменяй на cache.xPDOMemCached и все. Кеширование будет на мемкеше. И в плагине спокойно сможешь использовать $modx->cacheManager->set($key, $value); Плюс к этому при сбросе кеша сайта MODX и твой пользовательский кеш будет очищать, не надо ничего дописывать.
В процессоре действительно еще не все параметры созданы, но постепенно будут появляться. В данном случае не cascade нужен, а currentClass (к примеру current), чтобы всегда можно было определить текущий элемент. То есть active — это цепочка активных, но у текущего элемента еще и класс current будет.