Сергей Шлоков

Наверно поиском [[$ по таблицам контента, шаблонов и чанков. Или заюзать событие OnParse.

Точных сроков дать не могу. Как появится свободное время.

Да, есть такое дело. Хотел исправить и забыл. В следующей версии постараюсь не забыть.

Это обычная системная настройка. Ей можно манипулировать в процессе загрузки. Создайте плагин на событие OnHandleRequest и в нем прописывайте нужное значение согласно вашей логике

if ($modx->resource->id == 100) {
    $modx->setOption('pdotools_fenom_cache', false);  // отключить кэширование чанков для ресурса 100
}

Проверим.

Кто-нибудь знает.

В базовой логике так. Но её можно изменить — снимаешь чекбокс «Очищать кэш» и в плагине на OnDocFormSave пишешь нужную логику. Очень гибко.

Нет, код не бессмысленный. Просто не очень качественный.

Я думал, что это какой-то разработчик с форума, который недавно открыл для себя MODX. А оказывается это Боб Рей. Удивлён. (

Мда. Я надеюсь, что лайки поставили автору за труды, а не за это творчество (код). Лично мне, чтобы понять уровень, достаточно этого

/* See if we're in MODX or not */
$inModx = isset($modx) && $modx instanceof modX;

/* All the code below will only execute if
   we're not in MODX */
if (!$inModx) {
    $outsideModx = true;
   ...

Код выше устанавливает переменную $outsideModx на тот случай, если нам нужно будет узнать позже в сценарии, работаем ли мы внутри MODX или нет.

Т.е. переменная $inModx показывает, что мы внутри MODX. А переменная $outsideModx, которая является обратной к $inModx, показывает, что мы снаружи. Шикарно, правда?

А получение ресурса и пользователя указанными методами говорит о том, что автор не понимает как это работает внутри.

На самом деле выигрыш в скорости был не из-за Fenom, а за счёт pdoTools. Fenom как раз наоборот даёт лишнюю нагрузку и небольшой оверхед. Хотя в таблицах и указано наоборот. Лично я не смог повторить эти цифры. Да и тест, конечно, синтетический.

В одной из своих статей давал данные по скорости. Делал тест из pdoTools. Прирост был около 50%. На самом деле это синтетический тест. Но общий выигрыш понятен.

Много раз уже всем объяснял почему так происходит.

Fenom используется в pdoTools не как полноценный шаблонизатор, а как дополнительный парсер шаблонизатора MODX. Т.е. контент парсится двумя шаблонизаторами! Но главным является именно последний. А для него нет понятия «файловый сниппет». Есть обычный сниппет, который хранится в БД. Но сниппет — это php код. А код, чтобы он выполнился, нужно подключать через конструкцию include. Для этого создается файл в папке includes/elements/modsnippet/. И уже он потом подключается.

Когда вызывается файловый сниппет, pdoTools создаёт обычный сниппет MODX с именем в виде хеша. И MODX подготавливает его к исполнению — сохраняет в кэш, чтобы заинклюдить.

Но хочу отметить, что это не кэш результата сниппета. Это кэш кода сниппета. Т.е. создается файл для кэширования другого файла!!! Сам файловый сниппет никогда не кэшируется! Даже если ты очень преочень захочешь.

Это и куча других косяков реализации Fenom заставила меня написать ZoomX. В нём я заморочился этой темой и написал отдельный механизм для файловых элементов. Плюс они могут кэшироваться. Плюс за всё отвечает только один шаблонизатор. Поэтому я всем разработчикам, стремящимся работать по фуншую, советую ставить pdoTools из-за его сниппетов (Fenom сразу выключить) и ZoomX из-за правильного механизма шаблонизации и роутинга.

Да, я продаю компонент, написанный Сергеем Шлоковым. Мы договорились делить деньги пополам )))

Просто не будет элемента meta. В следующей версии сделаю возможность выводить свой формат данных.

Сделаю несколько пояснений.

pdoTools никакого отношения к теме статьи не имеет и для ZoomX не нужен. Я использую его лишь для того, чтобы работать с разметкой шаблона через IDE.

Это только для тех, кто хочет работать с шаблонизатором Fenom. Если есть желание работать в режиме фреймворка, то можно работать с шаблонизатором Smarty, который идёт с MODX из коробки. Я много раз уже говорил, что Fenom в pdoTools — это костыль, который вроде как добавляет возможности нормального шаблонизатора, но работает по правилам MODX шаблонизатора — многократный парсинг и компиляция контента, который ему подсовывает MODX шаблонизатор. В правильном режиме php шаблонизатор парсит страницу один раз, компилирует её в php файл и использует его при следующих запросах, не тратя время на повторный парсинг и компиляцию.

Если в роуте не указан метод контроллера, запрос всегда обращается к главному методу index()

Сначала проверяется наличие магического метода __invoke. Если его нет, то будет вызван метод index.

Метод jsonx всегда возвращает объект с тремя блоками.

Блок meta можно отключить в системной настройке zoomx_include_request_info

Если внимательно прочитать, то так и написано. Просто не совсем корректно.

getService() загружает файл класса (вызывая loadClass()), но также добавляет класс к объекту $modx, вы cможете вызывать его методы с помощью $modx->className->methodName().

Правильнее было бы сказать, что к объекту $modx добавляется не класс, а экземпляр указанного класса. Он же возвращается методом getService().

Соответственно получить доступ к этому экземпляру можно не через $modx->className, а через $modx->aliasName. Ниже в статье именно так и будет указано. Получается небольшое разночтение. Т.е. псевдоним вы можете указать любой (первый параметр), а вот класс (второй параметр) должен быть точным.

Запишите ишу, чтобы зафиксировать проблему.

Кстати есть ли возможность проверить используется ли на странице где то стандартный парсер?

Он используется всегда.

Смешанный режим — это зло. Даже опытные разработчики путают последовательность при работе в этом режиме. Сначала работает феном, потом стандартный.