![Fi1osof](/assets/images/avatars//7219a3951e6ac0b703e51e5b4c3c7a68-64.jpg?t=1739656589)
Fi1osof
С нами с 05 мая 2014; Место в рейтинге пользователей: #206 минут назад
Заметил баг, если установлен controlErrorLog или modalConsole, то на странице CronTabManager они не работают.
PR отправил github.com/astra-modx/modx-...
CrontabManager - работа из под console ssh 6
14 февраля 2025, 22:35
Сниппет pbResources — это аналог pdoResources, но с возможностью присоединять таблицы по принципу «один ко многим», чего нет у pdoResources. Также пер...
PageBlocks. Выводим SEO-карточки 4
13 февраля 2025, 22:33
Вот было бы неплохо это прописать в описании к компоненту. Два дня ломал голову почему не работает. Ведь форма может быть кастомизирована как угодно, ...
Ошибка ms_cdek2 9
13 февраля 2025, 22:30
С точки зрения производительности это плохая идеяПонимаю, но писать свое решение нет ни времени ни денег.
Сортировка в pdoMenu 6
13 февраля 2025, 19:02
Всем добрый день. Может не совсем в тему, но проблема следующая:
1. Есть контекст web — обычные текстовые страницы
2. Есть контекст catalog — катего...
[update] Общая база товаров для разных контекстов 21
13 февраля 2025, 16:46
Спасибо. Так сработало.
easyComm 1.15.0 большой апдейт: ответы, улучшенные файлы и многое другогое! 23
13 февраля 2025, 15:02
Такая же ситуация, загрузить нельзя на modx 3 не находит такого пакета.
А после установки локально сыпятся ошибки
components/sendit/services/sendit....
Нет возможности загрузить SendIt на modx 3.1 а очень хочется 5
13 февраля 2025, 14:15
Всё откатил. Почистил. Установил заново. Написал в поддержку на modstore.pro
msSortFields 17
13 февраля 2025, 12:55
Планируется под 3 обновление, пока просто надо с 2 до конца разобраться.
[EclipseUI] Обновление до версии 1.1.2 Новая тема "github". 2
Нефиг обновлять. Тогда ОК будет.
И еще у вас дыра серьезная есть: права new_tv true. Можно создать TV-ху с EVAL-ом и обновиться до судо.
Вернул sudo = 0 обратно.
Можете с этим кодом к консоли поиграться.
Вот это еще глянь, должно пригодиться: modx.pro/help/7278/#comment-52671
Очень сомневаюсь, что твой парсер может влезть уже после сохранения кеша, так как кеш сохраняется вообще в самую последнюю очередь, когда уже все отработано и скрипт в принципе завершает свою работу. Для этого навешивается специальный метод. Соответственно, если у тебя есть уже отработанный HTML, ты по тому же принципу можешь передать ресурсу код для кеширования и у тебя в кеше нормальный HTML будет. Важно только чтобы некешируемые элементы так и остались в этом коде элементами.
Конечно нет))
Все верно. Из-за этого и была проблема. Дело в том, что $modx->regClientStartupScript() и подобные методы работают со свойствами самого $modx, а вот при сохранении кеша используются свойства самого ресурса. А так, как в отработанных уже после процессинга тегах выполняется типа $modx->regClientStartupScript() (который устанавливает свойства для $modx, но не устанавливает их для $modx->resource), то при генерации кеша документа этих скриптов в кеше просто нет. joxi.ru/4Ak3wb9tMX8nGA
Решение: пишем плагин на событие OnBeforeSaveWebPageCache, простейший вид:
И тогда при генерации кеша документа будут сохранены все скрипты. joxi.ru/LmGVQx0uRJN1Xr
При чем это будет выполняться только при первом заходе на страницу. Когда документ уже закеширован будет, это не будет выполняться.
UPD: Может даже имеет смысл это в ядро запулить (то есть код кешманагера поправить), так как очень похоже на багу самого MODX-а. Какая-то глупость в двух отдельных сущностях хранить эти переменные и создавать/получать в разных местах на разных этапах.
Я пока не буду ничего отвечать. Мысли есть, но нужны факты. Щас поковыряю сайт и по результатам отпишусь.
Тут ответ однозначный: где-то неверная последовательность вызова/вывода. Ты четко знаешь когда бага возникает. Если не лень, создай тестовый сайт с этой багой (феном + минифи), закомментируй этот свой хак и пришли доступ, я посмотрю. Уверен, найду суть проблемы.
Почему я про этот кусок кода спросил? Во-первых, этот метод парсера в процессе отработки документам может быть вызван не один раз. Во-вторых, в разные стадии вызова его в массивах этих могут содержаться разные наборы скриптов (что не страшно, конечно же, ибо все равно они будут в шаблон подставлены только в одном месте, но как минимум бессмысленно).
Он же не скомпилированный. Кеширование отдыхает тогда в принципе. Это то, что было долгое время в самом MODX (я раньше не однократно писал про его проблемы, из-за того, что он даже кешируемые теги в кеш пишет как есть, и потом все равно каждый раз реплейс делает), и что в MODX наконец-то поправилось (теперь он в кеш пишет сразу конечный HTML из кешируемых элементов), и теперь ты это достижение ломаешь. Шаблоны будут чуть более гибкие, но зато более тормознутые.
Хранить в конечном html очень даже есть смысл, в этом и есть смысл кеширования ресурсов. А вот то, что иначе не будет отрабатываться каждый раз — так вот для этого и были придуманы не кешируемые MODX-теги. Напиши один сниппет вида [[!twig?tpl=`some_tpl`]] и все. И где надо некешируемые блоки вставлять — там его и прописывать в шаблонах.
Еще раз: в MODX с точки зрения шаблонизации только два минуса:
1. нет компиляции в нормальный php (чтобы логика была)
2. нет расширения шаблонов.
В остальном она довольно продвинутая (особенно крут вложенный парсинг).
Ты добавляешь расширяемости и логики, но ломаешь родное кеширование.
Вопрос первый: Зачем тебе вот это? Оно итак в modResponse::outputContent() отрабатывается. (на самом деле я предполагаю зачем оно тебе, но тут несколько вариантов, так что хотелось бы именно твой вариант услышать).