Cyrax_02
С нами с 04 августа 2013; Место в рейтинге пользователей: #247Вчера в 20:02
Походу твое решение спустя 4 года все такие стало актуальным
github.com/modxcms/revolution/pull/16571#pullrequestreview-2061133420
Facade Laravel в Modx 2/3 21
Вчера в 08:23
Всё норм работает, надо только заменить в файле core/components/msdsector/controllers/msdsectordeliveryhandler.class.php
if (!class_exists("ms...
[msdSector] - расчет стоимости доставки с учетом секторов. 10
15 мая 2024, 11:50
Немного дополню, для mSearch2 (может кому пригодится)
<script>
var lazyLoadInstance = new LazyLoad({
elements_selecto...
pdopage и vanilla-lazyload 7
15 мая 2024, 11:03
Каждый расходует свое время как хочет. :)
Вижу, что это что-то революционное. И стараюсь смотреть на такие вещи с точки зрения популяризации MODx в...
mmxTwig - еще одна интеграция шаблонизатора 6
15 мая 2024, 05:58
Добрый день,
Подскажите, написано, что «Добавлена автоматическая поддержка пользовательских множественных свойств»
Но при этом нигде не сказано...
[mSync] Новая версия синхронизации с 1С 87
14 мая 2024, 14:50
Спасибо!
Пробовал передать свой плейсхолдер — не работает такой подход.
Сейчас решение сделал в виде сниппета получающего id по pagetitle
cityFields внутри pdoResources и плейсхолдер id 2
14 мая 2024, 10:27
Решил, зашёл в контексты, web, и там создал новый контекст site_url, и там внутри добавил значение своего сайта на https.
Имя и ключ: site_url
Зна...
При добавлении <base href="[[++site_url]]"/>, не работают стили. 6
13 мая 2024, 23:47
Искал ответ примерно на тот же вопрос. Мне нужно было сделать file.php который будет выводить определенный ресурс из modx. Вот, может, кому то пригоди...
Как получить HTML код всей страницы в сниппете? 10
13 мая 2024, 16:14
Путем ковыряния несколько часов поля, что взял заказ, с кучей костылей. Много старых пакетов написаных еще в 14 году, которые не работаю php 5.6 стоял...
Не добавляется запись в MIGX 1
13 мая 2024, 12:48
Установил компонент. PHP 7.4, Modx 2.8.4. Созданные кастомные поля юзера не отображаются, в логе ошибка:
No foreign key definition for parentClass: e...
ExtraFields. Дополнительные поля для ресурса (modResource) и пользователя (modUserProfile). 33
А нихрена. Нету там всей строки:
[REDIRECT_QUERY_STRING] => q=page.html
[REDIRECT_URL] => /page.html
[QUERY_STRING] => q=page.html
[REQUEST_URI] => /page.html
Всю жизнь $_SERVER['QUERY_STRING'] использовал. А сейчас как будто на другую планету попал. зелёные человечки полезут…
Кодом, кодом и ещё раз кодом:
Пока остановился на этом варианте как самом гибком. Для каждого сниппета — свой индивидуальный набор зависимых параметров, хэширование и прочее (всё это инкапсулировал в 2 функции, одну вызываю в начале сниппета, другую — в конце). Правда, сниппет всё равно вызывается (одно лишнее обращение к БД), но зато реализовывается тонкая индивидуальная логика кэширования.
Минусы этого варианта:
1) Всю логику кэширования придётся загонять внутрь сниппетов. Т.е. практически в каждом сниппете придётся реализовывать кэширование.
2) Отходим от модели кэширования modx. Все эти сниппеты придётся вызывать некэшированными, а логику кэширования реализовывать внутри сниппетов
3) Придётся для каждого такого сниппета предусматривать и реализовывать параметр &cache для возможности отключения кэширования.
Т.е. в целом вариант некрасивый и несистемный.
А войнушки касаются необходимости подстраивать свой код под изменяющуюся от версии к версии логику работы modx. Чем больше используешь тонкостей реализации modx, тем чаще придётся корректировать свой код.
К примеру, вон вышла новая версия modx 2.3 — так все компоненты, разработанные Василием, приходится корректировать. Потому что внутренняя логика работы modx несколько изменилась.
В любом случае, нет пересекающихся событий, генерируемых и при ручном обновлении сайта, и при вызове modCacheManager::clearCache(). Плюс событие OnCacheUpdate — deprecated.
К тому же при очистке кэша в момент сохранения элемента (при установленной галке «Очистить кэш при сохранении») не генерируется никаких событий, связанных с кэшем.
Т.е. единственный вариант решения сабжевой задачи — частное решение. Т.е. вызываем «обработчик» события «после очистки кэша»:
а) в обработчике OnSiteRefresh
б) везде в коде после вызова modCacheManager::clearCache()
в) во всех обработчиках «после сохранения элемента», если установлена галка «Очистить кэш при сохранении»
file_get_contents будет выполняться долго, пока не загрузятся все данные страницы. Более того, php-опция allow_url_fopen может быть отключена, тогда функция с url работать не будет.
А wget — внешняя утилита, которой может не быть в дистрибутиве. И если её запускать в отдельном потоке (асинхронно), то мы не сможем проконтролировать успешность обновления кэша. Если её запускать синхронно, то имеют место все недостатки file_get_contents'а.
1. Через file_get_contents:
2. Генерация кэша ресурса через modxCacheManager->generateResource()
3. Использование внешней утилиты wget
1-й способ — самый затратный по времени, т.к. придётся ждать полной загрузки страницы:
— выполняться будут не только кэшируемые элементы, но и некэшируемые (а для получения кэша ресурса некэшируемые элементы выполнять вовсе не нужно — это лишняя трата времени)
— придётся ждать полной загрузки данных со сторонних ресурсов (а сторонние ресурсы могут отдавать данные криво и долго)
2-й способ работает быстрее, т.к. выполняются только кэшируемые элементы.
3-й способ (wget), интересен тем, что можно запустить процесс загрузки страницы ресурса (как в 1-м способе), но при это не ждать завершения загрузки. Т.е. можно будет всего лишь инициировать процесс загрузки (обновления кэша) в отдельном потоке и продолжить выполнение своего кода.
Всё верно?
Пробовал и так:
Тоже кэш ресурса не создаёт. Проверил непосредственно в папке core/cache/resource — пусто
Может, refresh пересоздаёт кэш только если он уже существует?
Мне необходимо создать кэш ресурса. Если кэш существует, то обновить.
В противном случае предупреждения не попадают ни в логи php, ни в логи modx (в настройках php включены все логи: E_ALL | E_STRICT).
В настройках ничего похожего нет.
Можно, конечно, в плагине на OnLoadWebDocument и OnManagerPageInit, но это не кошерный вариант, т.к. плагин придётся вешать и на многие другие события (почти на все).
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 сек]
Всё сходится.
а) старые минимизированные файлы не удаляются (накапливаются)
б) после очистки кэша modx Minify очень долго работает (в 10 раз дольше), даже если при этом выходной файл НЕ пересоздаётся
решил реализацией собственного управления выходным файлом:
1. Самостоятельно проверяю необходимость пересоздания конечного минимизированного файла (если изменились исходные файлы)
2. Если необходимо пересоздать, вызываю сниппет MinifyX
3. После вызова MinifyX получаю имя сгенерированного минимизированного файла
4. Переименовываю этот файл (без всяких хэшей в имени файла)
5. Самостоятельно подключаю его на странице
В результате, подключение css и js выполняется долго только при одновременном выполнении следующих условий:
а) требуется создать (пересоздать) выходной минимизированный файл (изменились исходные файлы)
б) был очищен кэш modx с момента последнего вызова MinifyX 1.3.0
Во всех остальных случаях подключение css и js выполняется так же быстро, как и в версии MinifyX 1.2.2.