Сброс и обновление кэша сниппета в определенное время
Уже когда-то задавался этим вопросом, пришел к такому решению (уже без getCache, но с fenom и включенным pdotools_fenom_parser).
UPD Зачем вообще это.
Создаем сниппет differenceBetweenDatesInSeconds:
На странице, где вызывается кэшируемый сниппет, пишем:
Потом cron-ом заходим на страницу каждый вторник в, например, 3:05 утра, тут уже сами гуглите.
Если у кого-то есть более элегантное решение, кидайте в комменты.
UPD Зачем вообще это.
Создаем сниппет differenceBetweenDatesInSeconds:
<?php
$fromDate = new DateTime(); //сегодня по времени сервера
$toDate = new DateTime();
$toDate->modify('next tuesday +3 hours'); //в следующий вторник в 3 часа утра
$difference = $toDate->getTimestamp() - $fromDate->getTimestamp(); //разница в секундах между сегодня и 3-мя утра следующего вторника, в это время истечет срок действия кэша
return $difference;На странице, где вызывается кэшируемый сниппет, пишем:
{var $seconds = '!differenceBetweenDatesInSeconds' | snippet}
{if !$snippet = $_modx->cacheManager->get('snippetName_cache')}
{set $snippet = $_modx->runSnippet('!snippetName', ['someParameter'=>'someValue'])}
{set $null = $_modx->cacheManager->set('snippetName_cache', $snippet, $seconds)}
{/if}
{$snippet}Потом cron-ом заходим на страницу каждый вторник в, например, 3:05 утра, тут уже сами гуглите.
Если у кого-то есть более элегантное решение, кидайте в комменты.
Комментарии: 31
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
У меня так: есть огромная страница, которую нужно спарсить раз в неделю и парсинг занимает много времени, если парсить каждый раз по окончанию действия кэша или ручной очистки кэша с админки, первому посетителю придется ждать десятки секунд (а он не будет ждать). Решил я парсить её cron-ом раз в неделю отдельным php скриптом, результат сохранять в файл на сервере (около 0.5 мб). Таким образом сниппет «snippetName» с примера выше, просто выполняет чтение и возврат этого файла «echo file_get_contents($file);», что существенно ускоряет время загрузки страницы если я очистил кэш вручную или время кэша закончилось. Потом я cron-ом выполняю запуск того самого php скрипта, который сохраняет результат в локальный файл. Вот такой вот многослойный торт.
Тогда этот скрипт хоть в 3 часа ночи запускай, хоть в 12 дня, когда обработка данных закончится он мигом запишет данные в ресурс и пользователь получит актуальную информацию.
мой велосипед это и делает, кроме заноса прямиком в контент и углубления в API MODX
я в этом ничего полезного к сожалению не увидел
Я бы, наверно, поставил в крон что-то типа
из core\model\modx\modresource.class.php
При сохранении ресурса с флагом $cacheFlag= true, кеш ресурса обновляется. Этим занимается метод toCache в core\xpdo\xpdo.class.php.
Наверно, можно при сохранении ресурса в админке сразу создавать его кеш. Переделав плагин Василия bezumkin.ru/sections/tips_and_tricks/351/. Только говорят кеш в MODX чистится весь из-за каких-то проблем. И не понятно, какие проблемы могут возникнуть, если кеш делать при сохранении в админке.
А где делается кеш при загрузке странице в упор не могу найти
А в cron удаляем кэш и парсим страницу сниппетом
Что важно! В данном случае сам сниппет на странице вызывается некэшированным. Поэтому кэш самой страницы обновлять не нужно. Только кэш сниппета!!! Обратите внимание, насколько код стал проще.
Функция snippet() сама проверит кэш. Если его нет, то выполнит указанный сниппет и результат сохранит в кэш. И не нужно вычислять все эти секунды. Cron каждую неделю будет обновлять кэш независимо от того, есть он или нет. Поэтому сниппет differenceBetweenDatesInSeconds не нужен. И даже вреден. Ибо делает ненужную работу для каждого запроса страницы.
П.С. И ещё совет. Не пихайте логику во вьюхи. Это бад практис! Перенесите логику в сниппет и вызывайте его на странице.
Плюс, для совместной работы, надо придерживаться единообразного стиля программирования. Синтаксис php, MODX и fenom знаком многим. А вот modHelpers редко встречается. И, соответственно, его не стоит использовать. Это помешает другим работать над проектом.
Боюсь тебя расстроить, но MODX — это синтаксический сахар над PHP. Юзай последний. Не отказывайся от своих принципов.
Не используй. Сделай мне больно.
П.С. Только щас заметил, что мой коммент почему-то попал не в корень, а залетел в ответ на твой коммент. Видимо глаза уже подводят.
Конечно, в чанки не стоит пихать код, но часто бывает так значительно проще. Например, как тут.
Как минимум ради циклов, расширения шаблонов.
microMODX $_modx ≠ modX $modx
Сергей сказал, что это плохая практика, никто не запрещает делать такие сайты в одиночку. Однако в команде за это могут надавать по рукам.
Лично я не вижу особой необходимости в объекте $_modx как ограничителе функциональности для безопасности. Этого нет ни в одном шаблонизаторе. Видимо никому не понадобилась такая фича. А вот как объект для работы со вьюхами (шаблонами, чанками, ресурсами) он хорош. Для правильной работы, если можно так выразится. И юзер $_modx->user там нужен! Хотя я бы сделал юзера отдельным объектом для удобства. Но считаю, что кэшменеджер тут лишний. Вот такое имхо. Но, как правильно сказал Павел, ты может делать что хочешь и как хочешь. Fenom позволяет юзать даже объект $modx. It's up to you.
Выполняется не быстрей, чем
И у тебя в файле $file уже типо кеш. Зачем его кешировать еще раз на странице. Наверно, можно было 2 ресурс, который показывается, сделать статическим и прикрепить к нему $file.
Что у вас такого тяжелого на странице выполняется? Хочется сделать какое-нибудь универсальное решение проблемы, если это возможно. Действительно тяжелые это фильтры товаров. Какие еще тяжелые сниппеты или случаи есть?
1.7729151 немного. но почему-то временами втупляет до 10с