Cyrax_02
С нами с 04 августа 2013; Место в рейтинге пользователей: #2501 час назад
не помогло к сожалению, подскажите пожалуйста, в каком направлении вы бы продолжили искать?
msOneClick. Ошибка, не появляется модальное окно 2
Вчера в 15:29
Разобрался!
Использую редактор Tinymcerte
В системных настройках нужно отключить Относительные URL!
Теперь обычные внутренние ссылки корректные...
Jevix чудит 8
Вчера в 14:35
Николай, низкий поклон за время и труд, тебе и всем ребятам, кто приложил руки.
Очень-очень жду и уповаю на ms3, буду рад чем-либо помочь (тестирован...
MiniShop3 - 1.0.0-alpha 16
Вчера в 13:12
Спасибо, точно, забыл про это поле. Может есть пример сниппета на запись в это поле? Не могу понять как обратиться к нужному файлу, получить его поле ...
[UserFiles] - Файлы пользователя. 188
Вчера в 11:13
Спасибо добрейшее. А тип поля «Текстовая область», как-то можно сменить на TinyMCE RTE?
[ExtraFields] Поле "не появляется/не включить" в "Настройках форм/шаблон Това... 2
10 декабря 2024, 22:05
[[!msOptions?
&options=`mount`
&tpl=`tpl.msOptions.Roman...
[Решено] Сортировка параметров опции 2
10 декабря 2024, 17:06
да, работает, спасибо!
[msProducts] Как вывести в каталог только те товары, у которых есть изображения в галерее? 2
09 декабря 2024, 12:36
Я разобрался :)
Достаточно было тупо < img… > обернуть в маркированный список, получилось как то так:
{
"header": "Изобр...
Как отобразить в таблице родительского MIGX изображения из дочернего MIGX? 8
07 декабря 2024, 12:38
Эта проблема возникает если у вас версия mysql ниже версии 8 из за этого не создается таблица при установке.
[SendIt 2.0.0] Пагинация и обновлённая загрузка файлов 25
А нихрена. Нету там всей строки:
[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.