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

Сергей, я считаю вполне обоснованным «недопонимание» со стороны Василия, мне бы тоже не понравился упрёк в мою сторон

Наверно ты прав. Думаю, будет правильнее удалить это. Статья чисто техническая. И не хотелось бы придавать ей какую-то эмоциональную окраску. И у меня нет никакого упрёка или претензий ни к Василию как к разработчику, ни к pdoTools. Многие из нас участвовали в совершенствовании этой библиотеки. Поэтому знаем все её преимущества. А Василий потратил огромное количество своего времени на её развитие. Только неблагодарный может предъявлять какие-то претензии. Я точно к таким не отношусь.

А недопонимание объясняется легко. К сожалению, у нас с Василием давно уже нет взаимопонимания. И уважительного отношения на личностном уровне. Но я от этого не страдаю. Уверен, и он тоже. И в дальнейшем я не планирую повышать нулевой уровень нашего общения.

И в конце статьи тогда стоило бы уточнить про предустановку pdoTools

А бывают сайты без pdoTools? Лендинги наверно? Но про них говорить смысла нет. Просто я в статье закрепил то, о чем много раз говорил и в чатах и комментариях в ответ на вопросы типа насколько быстрее будет работать сайт, если в карточке товара заменить синтаксис MODX на Fenom. В одном из своих последних комментариев тут я как раз и писал, что главная причина ускорения сайта — это pdoTools.

Многие разработчики сами замечают, что после замены ничего не изменилось по скорости. Как и на не заметил прироста на своём сайте. В этой статье я объяснил почему. Да и сам Василий в своём сегодняшнем посте тоже. Цифры для pdoParser до 100 чанков. Большинство сайтов (может даже 90%) использует пагинацию и даже 100 чанков парсить в цикле не будет. Не у всех на каждой странице сайта 890 комментариев.

Так, давайте проясним, чтобы не было недопонимания.
В статье я показал, что если у вас установлен pdoTools, не надо бросаться переписывать все на Fenom и менять [[pdoResources? ...]] на {'pdoResources' | snippet: [...]}, или [[++setting]] на {'setting' | config} ради выигрыша в скорости как советуют некоторые разработчики. Вы его не получите.

П.С. И, да, чанк я взял из теста (тот который с логикой), о чём и написал в начале поста.

Замечание принял. А кроме комментариев есть ещё примеры?

Или это только про удобство, а не скорость?

К самому тесту замечания есть? Я говорю про тест через сниппет в обычном режиме, в котором будут работать 99,9% разработчиков, а не через API.

П.С. Лично я считаю, что эти тесты искуссвенные. В боевом проекте, где куча чанков, сниппетов и т.д., цифры будут совершенно другие. Вот где интересно было бы погонять тесты.Но судя по отзывам разработчиков, которые меняли синтаксис, разницы особо не видно. Даже часто феном немного проседал.

Вспомнился роман Хейли «Колесо». Там создавали новую модель машины и на этапе тестирования возникла проблема — что-то с коробкой передач на определённой скорости. Стоимость доработки 5 долларов. Ерунда. Копейки по сравнению со стоимостью машины. Но разработчики отказались от этой идеи. Причина — планировалось выпустить около 1 миллиона экземпляров. А значит дополнительный расходы составили бы + 5 млн. долларов.

10 лишних запросов для небольшого сайта — плёвое дело. А для высоконагруженного может оказаться непозволительной роскошью.

Подход к кэшированию должен быть вдумчивым. Кэшировать всё подряд также не имеет смысла. Нужно думать об актуализации данных. Поэтому всегда нужно находить баланс. Для этого и нужны опытные разработчики. )

Читаем внимательно и до конца.

Прочитал про размер кэша. Твоё удивление от непонимания. Что такое кэш? Это статичные данные. Если у тебя кэш на феноме в 10 раз меньше, то есть повод задуматься — всё ли закэшировалось? Отсюда и лишние запросы к БД. Конструкция {include 'чанк'} никогда не кэширует чанк.

Просто с таким же успехом можно восхищаться пустой папкой кэша после того, как ты его отключишь.

Наверно поиском [[$ по таблицам контента, шаблонов и чанков. Или заюзать событие 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 из-за правильного механизма шаблонизации и роутинга.

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