Cyrax_02

Всегда думал, что $_SERVER содержит в числе своих параметров всю строку запроса целиком.
А нихрена. Нету там всей строки:
[REDIRECT_QUERY_STRING] => q=page.html
[REDIRECT_URL] => /page.html
[QUERY_STRING] => q=page.html
[REQUEST_URI] => /page.html

Всю жизнь $_SERVER['QUERY_STRING'] использовал. А сейчас как будто на другую планету попал. зелёные человечки полезут…

Я хотел на уровне парсера modx это сделать. Только пока не научили его этому.

Кодом, кодом и ещё раз кодом:

return http_build_url($_REQUEST['QUERY_STRING'], array('page' => $page));

Ну уж нет. Лучше всё руками писать.
Пока остановился на этом варианте как самом гибком. Для каждого сниппета — свой индивидуальный набор зависимых параметров, хэширование и прочее (всё это инкапсулировал в 2 функции, одну вызываю в начале сниппета, другую — в конце). Правда, сниппет всё равно вызывается (одно лишнее обращение к БД), но зато реализовывается тонкая индивидуальная логика кэширования.

Да, этот вариант не упомянул в 1-м посте. Способ самый гибкий.
Минусы этого варианта:
1) Всю логику кэширования придётся загонять внутрь сниппетов. Т.е. практически в каждом сниппете придётся реализовывать кэширование.
2) Отходим от модели кэширования modx. Все эти сниппеты придётся вызывать некэшированными, а логику кэширования реализовывать внутри сниппетов
3) Придётся для каждого такого сниппета предусматривать и реализовывать параметр &cache для возможности отключения кэширования.

Т.е. в целом вариант некрасивый и несистемный.

Я как раз и имел ввиду перегрузку. Наследование + перегрузка. Об изменении исходных кодов речи, конечно же, не идёт.
А войнушки касаются необходимости подстраивать свой код под изменяющуюся от версии к версии логику работы modx. Чем больше используешь тонкостей реализации modx, тем чаще придётся корректировать свой код.
К примеру, вон вышла новая версия modx 2.3 — так все компоненты, разработанные Василием, приходится корректировать. Потому что внутренняя логика работы modx несколько изменилась.

$html = $modx->pdoTools->getChunk($chunkName, $placeholders, false);
if($html == print_r($placeholders, true)) {
    $html = "???"
}

Так?

Да, только вот массив может содержать данные, которые нельзя показывать пользователям.

Да, действительно, OnCacheUpdate вызывается. Только вот это событие при ручном обновлении сайта не вызывается. Всегда думал, что обновление сайта это и есть вызов modCacheManager::clearCache(). Как оказалось, при обновлении сайта этот метод вообще не вызывается.

В любом случае, нет пересекающихся событий, генерируемых и при ручном обновлении сайта, и при вызове modCacheManager::clearCache(). Плюс событие OnCacheUpdate — deprecated.
К тому же при очистке кэша в момент сохранения элемента (при установленной галке «Очистить кэш при сохранении») не генерируется никаких событий, связанных с кэшем.

Т.е. единственный вариант решения сабжевой задачи — частное решение. Т.е. вызываем «обработчик» события «после очистки кэша»:
а) в обработчике OnSiteRefresh
б) везде в коде после вызова modCacheManager::clearCache()
в) во всех обработчиках «после сохранения элемента», если установлена галка «Очистить кэш при сохранении»

Всё-таки самым надёжным и приемлемым в плане скорости является modxCacheManager->generateResource().

file_get_contents будет выполняться долго, пока не загрузятся все данные страницы. Более того, php-опция allow_url_fopen может быть отключена, тогда функция с url работать не будет.

А wget — внешняя утилита, которой может не быть в дистрибутиве. И если её запускать в отдельном потоке (асинхронно), то мы не сможем проконтролировать успешность обновления кэша. Если её запускать синхронно, то имеют место все недостатки file_get_contents'а.

Пока вижу 3 варианта обновления кэша ресурса:

1. Через file_get_contents:

$resourceId = 950000;
$resource = $modx->getObject('modResource', $resourceId);
$context = $resource->get('context_key');
$url = $modx->makeUrl($resourceId, $context, '', 'full');
$content = file_get_contents($url);  // загрузка страницы ресурса с генерацией его кэша

2. Генерация кэша ресурса через modxCacheManager->generateResource()
3. Использование внешней утилиты wget

1-й способ — самый затратный по времени, т.к. придётся ждать полной загрузки страницы:
— выполняться будут не только кэшируемые элементы, но и некэшируемые (а для получения кэша ресурса некэшируемые элементы выполнять вовсе не нужно — это лишняя трата времени)
— придётся ждать полной загрузки данных со сторонних ресурсов (а сторонние ресурсы могут отдавать данные криво и долго)

2-й способ работает быстрее, т.к. выполняются только кэшируемые элементы.

3-й способ (wget), интересен тем, что можно запустить процесс загрузки страницы ресурса (как в 1-м способе), но при это не ждать завершения загрузки. Т.е. можно будет всего лишь инициировать процесс загрузки (обновления кэша) в отдельном потоке и продолжить выполнение своего кода.

Всё верно?

В логах пусто. И в логах modx (включены все сообщения от warnings и серьёзнее), и в логах php.

Все эти действия выполняются в контексте `mgr`.

$resourceId = 950000
$resource = $modx->getObject('modResource', $resourceId);
$cacheKey = $resource->getCacheKey();  // возвращает mgr/resources/950000

$cacheManager = $modx->getCacheManager();	            
$cacheManager->refresh(array('resource' => array('key' => $cacheKey)));

Физически кэш ресурса не создаётся. Проверил непосредственно в папке core/cache/resource — пусто

Пробовал и так:

$resourceId = 950000
$cacheKey = "web/resources/950000";
$cacheManager = $modx->getCacheManager();	            
$cacheManager->refresh(array('resource' => array('key' => $cacheKey)));

Тоже кэш ресурса не создаёт. Проверил непосредственно в папке core/cache/resource — пусто

Может, refresh пересоздаёт кэш только если он уже существует?
Мне необходимо создать кэш ресурса. Если кэш существует, то обновить.

Точно

Ещё вопрос. Как изменить modX::LOG_LEVEL с LOG_LEVEL_ERROR на LOG_LEVEL_WARN?
В противном случае предупреждения не попадают ни в логи php, ни в логи modx (в настройках php включены все логи: E_ALL | E_STRICT).

В настройках ничего похожего нет.
Можно, конечно, в плагине на OnLoadWebDocument и OnManagerPageInit, но это не кошерный вариант, т.к. плагин придётся вешать и на многие другие события (почти на все).

…

…

1. Да, если НЕ очищать кэш munee при очистке кэша modx, тормозов нет.
2. Если вручную удалить кэш munee (.../core/cache/default/munee), получаем тормоза.
3. Если оставить всю структуру папок и подпапок кэша munee, а кэш-файлы .css и .js из этих подпапок удалить, то по-прежнему наблюдаются тормоза.

Вывод: большой расход времени — из-за пересоздания всех кэш-файлов при первом запуске munee.

Вот сейчас всё понятно, откуда берутся цифры 0,2-0,7 сек (без очистки кэша modx) и 3-5 сек после очистки кэша modx. В первом случае обновляется только кэш одного файла (который изменился), во втором случае обновляются кэши всех файлов, которые передаются MinifyX/munee (их у меня 13 штук). Т.е. получаем разницу в 13 раз:
[0,2-0,7 сек] * 13 = [3-5 сек]
Всё сходится.

Вместо угадаек можно было открыть исходный код дополнения и посмотреть, что там и как работает.

Копаться в исходниках munee? Ну уж нет. Чего он там делает при первом вызове после очистки кэша — это пусть остаётся на его совести. В любом случае, без корректировки исходников его поведение не изменить. Посему то, что я сделал — единственный вариант минимизации этих проявлений для текущей версии minifyX/munee.

Вот эти 2 проблемы, имеющие место в MinifyX 1.3.0:
а) старые минимизированные файлы не удаляются (накапливаются)
б) после очистки кэша modx Minify очень долго работает (в 10 раз дольше), даже если при этом выходной файл НЕ пересоздаётся

решил реализацией собственного управления выходным файлом:

1. Самостоятельно проверяю необходимость пересоздания конечного минимизированного файла (если изменились исходные файлы)
2. Если необходимо пересоздать, вызываю сниппет MinifyX
3. После вызова MinifyX получаю имя сгенерированного минимизированного файла
4. Переименовываю этот файл (без всяких хэшей в имени файла)
5. Самостоятельно подключаю его на странице

В результате, подключение css и js выполняется долго только при одновременном выполнении следующих условий:
а) требуется создать (пересоздать) выходной минимизированный файл (изменились исходные файлы)
б) был очищен кэш modx с момента последнего вызова MinifyX 1.3.0

Во всех остальных случаях подключение css и js выполняется так же быстро, как и в версии MinifyX 1.2.2.