modx cacheManager: где "хранится" время жизни ?
$value = '555';
$modx->cacheManager->set('test', $value, 20);
echo $modx->cacheManager->get('test');Физически, в /core/cache/default лежит файл test.cache.php. А где «лежит» его время жизни ?
25 августа 2014, 16:05
Комментарии: 19
У меня modx глючит.
В шаблоне tpl_test указываю:
Загружаю этот ресурс — в /core/cache/includes/elements/modsnippet появляется кэш сниппета. Удаляю этот кэш-файл, загружаю ресурс — кэш-файл сниппета снова появляется.
Шаблон ресурсу прописываю верный. Если в шаблоне отключить сниппет
Бред какой-то. Сниппет вызываю НЕкэшируемым. А он всё равно кэшируется. При загрузке ресурса отрабатывает сниппет из кэша. Галку «Очистить кэш при сохранении» снял и у шаблона, и у сниппета.
В шаблоне tpl_test указываю:
[[!snp_test]]Загружаю этот ресурс — в /core/cache/includes/elements/modsnippet появляется кэш сниппета. Удаляю этот кэш-файл, загружаю ресурс — кэш-файл сниппета снова появляется.
Шаблон ресурсу прописываю верный. Если в шаблоне отключить сниппет
[[-!snp_test]]Бред какой-то. Сниппет вызываю НЕкэшируемым. А он всё равно кэшируется. При загрузке ресурса отрабатывает сниппет из кэша. Галку «Очистить кэш при сохранении» снял и у шаблона, и у сниппета.
При сохранении шаблона кэш сайта не очищается, потому что галку «Очистить кэш при сохранении» у шаблона я отключил.
У ресурса галку «кэшируемый» снял.
У сниппета галку «Очистить кэш при сохранении снял».
При этом наблюдаю артефакт: некэшируемый сниппет кэшируется.
Т.е. если кэш сайта не очищать, то при загрузке ресурса появляется кэш сниппета. А если измененить код сниппета и сохранить его, то при загрузке ресурса выполняется код из кэша.
У ресурса галку «кэшируемый» снял.
У сниппета галку «Очистить кэш при сохранении снял».
При этом наблюдаю артефакт: некэшируемый сниппет кэшируется.
Т.е. если кэш сайта не очищать, то при загрузке ресурса появляется кэш сниппета. А если измененить код сниппета и сохранить его, то при загрузке ресурса выполняется код из кэша.
Ты хоть в код этого файла посмотри. Видишь там отметку времени, или массив данных, похожий на кэш?
Нет, там лежит сам код сниппета, который и выполняется. Или ты считаешь, что нужно через eval() запускать всё из БД, без сохранения в файл?
Revolution не использует eval(), и правильно делает.
Нет, там лежит сам код сниппета, который и выполняется. Или ты считаешь, что нужно через eval() запускать всё из БД, без сохранения в файл?
Revolution не использует eval(), и правильно делает.
Я не против хранения кода сниппета.
Но какого хрена там хранится старый код? И этот старый код всё время выполняется.
Вот я изменил код сниппета, сохранил его. Вместо '555' он должен возращать '666'. Запускаю ресурс — получаю '555'. Это нормально? При том, что кэширование отключено.
Но какого хрена там хранится старый код? И этот старый код всё время выполняется.
Вот я изменил код сниппета, сохранил его. Вместо '555' он должен возращать '666'. Запускаю ресурс — получаю '555'. Это нормально? При том, что кэширование отключено.
Нет. Это прокол разработчиков modx.
По их замыслу, файл xx.include.cache.php сниппета должен создаваться всегда. В зависимости от запрета кэширования этот файл возвращает либо значение сниппета (полученное при первом выполнении кода сниппета), либо его код.
Только вот позабыли разработчики обновлять этот файл при сохранении сниппета (при отключенной галке «Очистить кэш при сохранении»).
А почему никто, кроме меня, на этот артефакт внимания не обращал — потому что у всех стоит галка «Очистить кэш при сохранении» (при сохранении кэш очищается => при вызове сниппета выполняется актуальный в данный момент код сниппета).
По их замыслу, файл xx.include.cache.php сниппета должен создаваться всегда. В зависимости от запрета кэширования этот файл возвращает либо значение сниппета (полученное при первом выполнении кода сниппета), либо его код.
Только вот позабыли разработчики обновлять этот файл при сохранении сниппета (при отключенной галке «Очистить кэш при сохранении»).
А почему никто, кроме меня, на этот артефакт внимания не обращал — потому что у всех стоит галка «Очистить кэш при сохранении» (при сохранении кэш очищается => при вызове сниппета выполняется актуальный в данный момент код сниппета).
Т.е. вы признаёте, что это кэш сниппета?
Я удивляюсь, что «он» не обновляется (очищаться он и не должен, т.к. галка очистки снята) при изменении сниппета. И не на пустом месте.
В modx мы имеем место с 2 логическими категориями:
1) Кэширование элемента или ресурса. В случае с элементами — это восклицательный знак перед именем элемента. В случае с ресурсом — галка «Кэшируемый». Логика этой категории такова, что что запрет кэширования означает, что ВСЕГДА обрабатываются актуальные на текущий момент данные и выполняется актуальный на текущий момент код.
2) Очистка кэша при сохранении. Означает, что если мы изменяем элемент или ресурс, то при последующей загрузке страницы мы получим актуальные данные и актуальный код.
Но в случае со сниппетом запрет кэширования НЕ означает выполнение актуального кода (нарушена логика #1). Всё встало бы на свои места, если бы при запрете кэширования сниппета и при отключенной галке «Очистить кэш при сохранении» этот самый файл обновлялся (актуализировался). Только в этом случае вышеизложенная логика полностью бы соблюдалась.
Т.е. при запрете кэширования сниппета всегда должен выполняться актуальный на текущий момент код, независимо от того, каким образом физически реализована работа с этим сниппетом. Если бы код сниппета извлекался бы из БД, то проблемы бы не было. Ну а коли код сниппета сохраняется в файле, то этот файл должен поддерживаться в актуальном состоянии (если кэширование запрещено).
Я удивляюсь, что «он» не обновляется (очищаться он и не должен, т.к. галка очистки снята) при изменении сниппета. И не на пустом месте.
В modx мы имеем место с 2 логическими категориями:
1) Кэширование элемента или ресурса. В случае с элементами — это восклицательный знак перед именем элемента. В случае с ресурсом — галка «Кэшируемый». Логика этой категории такова, что что запрет кэширования означает, что ВСЕГДА обрабатываются актуальные на текущий момент данные и выполняется актуальный на текущий момент код.
2) Очистка кэша при сохранении. Означает, что если мы изменяем элемент или ресурс, то при последующей загрузке страницы мы получим актуальные данные и актуальный код.
Но в случае со сниппетом запрет кэширования НЕ означает выполнение актуального кода (нарушена логика #1). Всё встало бы на свои места, если бы при запрете кэширования сниппета и при отключенной галке «Очистить кэш при сохранении» этот самый файл обновлялся (актуализировался). Только в этом случае вышеизложенная логика полностью бы соблюдалась.
Т.е. при запрете кэширования сниппета всегда должен выполняться актуальный на текущий момент код, независимо от того, каким образом физически реализована работа с этим сниппетом. Если бы код сниппета извлекался бы из БД, то проблемы бы не было. Ну а коли код сниппета сохраняется в файле, то этот файл должен поддерживаться в актуальном состоянии (если кэширование запрещено).
В папке core/cache/includes хранится обернутый в функции код сниппетов, плагинов. Сделано для более быстрого вызова. Это не кэш. Кэш сниппетов и плагинов хранится в папке core/cache/scripts. Когда Вы вызываете кешированный сниппет, он берется из core/cache/scripts. Когда Вы вызываете некешированный сниппет он берется из core/cache/includes, если существует, иначе генерируется новый.
Не очистив кеш при изменении сниппета, Вы оставили старым xx.include.cache.php.
Не очистив кеш при изменении сниппета, Вы оставили старым xx.include.cache.php.
Не очистив кеш при изменении сниппета, Вы оставили старым xx.include.cache.php.Как Вы сами же говорите, xx.include.cache.php — НЕ кэш сниппета. Тогда почему этим файлом должна управлять галка «Очистить кэш»?
Согласен, что xx.include.cache.php — не кэш сниппета (если говорить о кэшировании значения, возвращаемого сниппетом). xx.include.cache.php — это фактически зеркало того кода, который хранится в БД. Т.е. код сниппета хранится в 2 местах — в стандартной БД и в файле. Имеет место оправданная избыточность данных.
Но почему Вы считаете, что это самое зеркало и код в БД не должны друг другу соответствовать? И речь не идёт о кэше. Если одни и те же данные в некоторый момент времени оказываются разными, имеет место нарушение целостности, что мы и наблюдаем при изменении кода сниппета в БД.
Вы считаете нарушение целостности данных нормальным?
Потому что очистка кеша — очистка папки core/cache, где все это находится.
В базе код сниппета. В файле — код для инклюда (функция). Никакого зеркалирования тут нет. Код из базы берется 1 раз при первом вызове сниппета (если нет кеша). В остальное время есть кеш и/или готовая к инклюду функция. Если Вы сознательно не обновляете эти данные, как Вы хотите получить свежую информацию?
Специально, чтобы не было нарушения целостности и стоит галочка «Обновлять кеш при сохранении».
Предвосхищая вопросы «Зачем это нужно»
Например, сниппет будет возвращать другое значение (не true|false, а количество элементов). А чанки с вызовом сниппета я не могу менять (прав нет), этим занят фронтенд-разработчик. А я изменил код сниппета. Завтра второй разработчик доделает чанки и обновит кеш, и все будет хорошо.
В базе код сниппета. В файле — код для инклюда (функция). Никакого зеркалирования тут нет. Код из базы берется 1 раз при первом вызове сниппета (если нет кеша). В остальное время есть кеш и/или готовая к инклюду функция. Если Вы сознательно не обновляете эти данные, как Вы хотите получить свежую информацию?
Специально, чтобы не было нарушения целостности и стоит галочка «Обновлять кеш при сохранении».
Предвосхищая вопросы «Зачем это нужно»
Например, сниппет будет возвращать другое значение (не true|false, а количество элементов). А чанки с вызовом сниппета я не могу менять (прав нет), этим занят фронтенд-разработчик. А я изменил код сниппета. Завтра второй разработчик доделает чанки и обновит кеш, и все будет хорошо.
Есть текущие (актуальные) данные и закэшированные данные. Третьего не дано. Если мы работаем с кэшируемыми данными (кэшируемые ресурсы, кэшируемые элементы), то при загрузке веб-страниц отображаются закэшированные данные. Если мы работает с НЕкэшируемыми данными, то при загрузке веб-страниц должны отображаться всегда актуальные данные.
Отделяем мух от котлет:
Если по замыслу разработчиков include-код имеет отношение к кэшу элемента (т.е. является кэшем include-кода), то этот кэш include-кода вообще НЕ должен использоваться при вызове НЕкэшируемого элемента.
Если же по замыслу разработчиков include-код является include-вариантом текущего кода элемента, то он всегда должен поддерживаться в актуальном состоянии (т.е. обновляться при обновлении исходного кода элемента).
Сейчас же мы наблюдаем смешанную логику:
В ходе обработки НЕкэшируемого элемента парсером modx этот файл выступает в качестве include-варианта текущего кода элемента. А при изменении исходного кода сниппета — в качестве кэша include-кода.
Такого быть не должно. Логика должна быть однозначной — либо это кэш-side, либо не кэш-side.
Ну ведь очевидно, что разработчики modx реализовали именно такой вариант работы парсера (не eval'ом из БД, а include'ом из внешнего файла) не для того, чтобы синхронизировать раздельную работу разработчиков.
Ваш пример всего лишь показывает, как с пользой можно использовать эту «особенность» modx.
Всё-таки цель этой галки несколько иная. Не обеспечение целостности данных (целостность данных должна обеспечиваться всегда, везде и в безусловном порядке, а если нужны варианты данных на разные моменты времени, здесь уже вводим категории снимков данных, кэша, версий и пр.), а актуализация кэша (в силу реализации новые кэш-данные физически будут созданы при первом вызове, но смысл именно такой).
В остальное время есть кеш и/или готовая к инклюду функция.
Отделяем мух от котлет:
Если по замыслу разработчиков include-код имеет отношение к кэшу элемента (т.е. является кэшем include-кода), то этот кэш include-кода вообще НЕ должен использоваться при вызове НЕкэшируемого элемента.
Если же по замыслу разработчиков include-код является include-вариантом текущего кода элемента, то он всегда должен поддерживаться в актуальном состоянии (т.е. обновляться при обновлении исходного кода элемента).
Сейчас же мы наблюдаем смешанную логику:
В ходе обработки НЕкэшируемого элемента парсером modx этот файл выступает в качестве include-варианта текущего кода элемента. А при изменении исходного кода сниппета — в качестве кэша include-кода.
Такого быть не должно. Логика должна быть однозначной — либо это кэш-side, либо не кэш-side.
Предвосхищая вопросы «Зачем это нужно»
Например, сниппет будет возвращать другое значение (не true|false, а количество элементов). А чанки с вызовом сниппета я не могу менять (прав нет), этим занят фронтенд-разработчик. А я изменил код сниппета. Завтра второй разработчик доделает чанки и обновит кеш, и все будет хорошо.
Ну ведь очевидно, что разработчики modx реализовали именно такой вариант работы парсера (не eval'ом из БД, а include'ом из внешнего файла) не для того, чтобы синхронизировать раздельную работу разработчиков.
Ваш пример всего лишь показывает, как с пользой можно использовать эту «особенность» modx.
Специально, чтобы не было нарушения целостности и стоит галочка «Обновлять кеш при сохранении».
Всё-таки цель этой галки несколько иная. Не обеспечение целостности данных (целостность данных должна обеспечиваться всегда, везде и в безусловном порядке, а если нужны варианты данных на разные моменты времени, здесь уже вводим категории снимков данных, кэша, версий и пр.), а актуализация кэша (в силу реализации новые кэш-данные физически будут созданы при первом вызове, но смысл именно такой).
Нет никакого оптимизатора.
Я же слежу непосредственно за файлом 200.include.cache.php (сниппет snp_test имеет id 200) в директории /core/cache/includes/elements/modsnippet. А этим файлом и в этой директории управляет исключительно modx. Этот файл после первого создания никогда не меняется. Если только очистить кэш, он пересоздастся.
Я же слежу непосредственно за файлом 200.include.cache.php (сниппет snp_test имеет id 200) в директории /core/cache/includes/elements/modsnippet. А этим файлом и в этой директории управляет исключительно modx. Этот файл после первого создания никогда не меняется. Если только очистить кэш, он пересоздастся.
Ещё один артефакт. Вернее, как уже выяснилось, так было задумано разработчиками.
Галка «Очистить кэш при сохранении» у элементов (сниппеты, плагины, чанки, шаблоны) и галка «Очистить кэш» у ресурсов НЕ имеют собственного поля в БД.
Как следствие:
а) при снятии этой галки и сохранении элемента/ресурса состояние галки в БД запомнено не будет
б) при загрузке (перезагрузке) страницы элемента/ресурса эта галка ВСЕГДА устанавливаются
Это вторая причина, по которой никто не замечал вот этого артефакта:
Галка «Очистить кэш при сохранении» у элементов (сниппеты, плагины, чанки, шаблоны) и галка «Очистить кэш» у ресурсов НЕ имеют собственного поля в БД.
Как следствие:
а) при снятии этой галки и сохранении элемента/ресурса состояние галки в БД запомнено не будет
б) при загрузке (перезагрузке) страницы элемента/ресурса эта галка ВСЕГДА устанавливаются
Это вторая причина, по которой никто не замечал вот этого артефакта:
Нет. Это прокол разработчиков modx.
По их замыслу, файл xx.include.cache.php сниппета должен создаваться всегда. В зависимости от запрета кэширования этот файл возвращает либо значение сниппета (полученное при первом выполнении кода сниппета), либо его код.
Только вот позабыли разработчики обновлять этот файл при сохранении сниппета (при отключенной галке «Очистить кэш при сохранении»).
Гражданин Cyrax_02, у тебя все вопросы такие.
Ты каждый раз находишь тотальные недостатки, которые никто не замечает. И каждый раз выносишь мозг сверлением «а почему так?». То, что обычные люди делают за 2 клика без заморочек, ты декомпилируешь до уровня php модулей.
Честное слово, я больше просто не буду тебе ничего отвечать, надоело. Зануда 60 lvl.
Ты каждый раз находишь тотальные недостатки, которые никто не замечает. И каждый раз выносишь мозг сверлением «а почему так?». То, что обычные люди делают за 2 клика без заморочек, ты декомпилируешь до уровня php модулей.
Честное слово, я больше просто не буду тебе ничего отвечать, надоело. Зануда 60 lvl.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
5 часов назад
если правильно понял то так
{set $rows = json_decode($_modx->resource.constructor_block, true)}
{foreach $r...
Сегодня в 01:42
У вас есть баг при изменении кол-ва позиции в корзине
20 ноября 2024, 16:25
В сниппете rcv3_html достаточно отложить загрузку через setTimeout (хотя кто-то делает через onClick). Не думаю что мой вариант самый правильный и что...
19 ноября 2024, 10:51
Решил свою проблему через имя пользователя, но хотелось бы через права пользователя «Неограниченные права»
<?php
/**
* Системное событие OnMan...
19 ноября 2024, 09:09
Спасибо, тоже очень интерестное решение.
18 ноября 2024, 15:21
'where' => [
'Data.price:!='=>'0'
]
18 ноября 2024, 14:19
miniShop2.Order.add('extfld_delivery_price','100', function() {
miniShop2.Order.getcost();
})
Это вот работает, но чтобы увид...
18 ноября 2024, 10:11
Благодарю за ответы.