Мне часто приходится слышать о такой проблеме. Аналогичная проблема возникает со своими шаблонами компонентов. Ситуация обычно усложняется тем, что техподдержка отказывается решать проблему ссылаясь на то, что стандартные компоненты системы работают нормально.
Предлагаю окончательно разобраться в этом вопросе и расставить все точки над "i".
[spoiler]
Прежде пару слов о том, что привносит приставка "авто" к кешированию компонентов. Не стоит питать иллюзий относительно того, что Битрикс сам будет выбирать время кеширования и подходящий момент для очистки кеша. Это может делать только разработчик решения, основываясь на реальных потребностях конкретного проекта: необходимо указывать в настройках компонентов время кеширования, адекватное периодичности обновления информации.
Автокеширование появилось в 6-й версии продукта для замены стандартного кеширования компонентов. Единственное отличие в том, что автокеширование может выключаться глобально на весь сайт одной кнопкой в админке. Т.е. на этапе разработки оно выключено, перед сдачей проекта включается и, условно говоря, всё полетело!
Устройство и место хранения
Кеш компонентов хранится в файлах в папке /bitrix/cache.
На основе следующих параметров формируется идентификатор кеша компонента:
- ID текущего сайта,
- имя компонента,
- имя шаблона компонента,
- параметры компонента,
- внешние условия, которые определяются в компоненте (например, список групп, к которым привязан текущий пользователь).
ID кеша определяет путь к файлу с кешем (к слову, есть возможность использовать , но от этого не зависит работа с компонентами). Таким образом, зная все эти параметры, можно очистить кеш любого компонента. Иначе кеш будет сброшен по истечении времени кеширования, кнопкой обновить кеш на панели инструментов публичной части или полной очисткой кеша из административной части.
Когда сбрасываете кеш страницы кнопкой очистить кеш, имейте ввиду, что компонент может использовать привязку к группам для хранения кеша, тогда незарегистрированные пользователи будут по-прежнему видеть не актуальную страницу.
Непосредственно после добавлении/изменении элемента инфоблока в административной части кеш публичных компонентов не сбрасывается. Образно это объясняется тем, что инфоблок "новости" "не знает", где выводятся новости в публичной части и сколько компонентов их отображает. Это не проблема если время кеширования выставлено правильно.
Структурная схема работы компонента
В $arParams содержится набор параметров компонента, component.php работает с входными параметрами запроса и базой данных, формирует результат в массив $arResult.
Шаблон компонента преобразует результат в текст HTML.
При первом хите сформированный HTML попадает в кеш (здесь и далее операции чтения показаны синими стрелками, записи - красными).
Пунктирная линия показывает порядок обработки php кода.
При последующих хитах работает другая схема:
Запросов в базу не делается (или делается мало), данные читаются из кеша.
Ключевой момент: порядок выполнения, в этом случае код шаблона компонента и result_modifier.php не исполняются.
Популярная ошибка, в шаблоне компонента вызываются отложенные функции: $APPLICATION->SetTitle(), $APPLICATION->AddChainItem() и т.д. В этом случае они работают только при выключенном кешировании.
Периодически приходится наблюдать картину: хостер отключает аккаунт за большую нагрузку на сервер, клиент обращается к нам в техподдержку, мы видим, что кеширование компонентов не используется. Клиент объясняет это так: "мне сказали ваши партнёры разработчики компонентов, что для этого компонента нельзя включать кеширование т.к. оно в битриксе криво работает".
При разработке шаблонов надо следовать простому правилу: задача шаблона - на основе входного массива $arResult сформировать текст HTML на выходе.
В собственных компонентах надо формировать такой ID кеша, который однозначно определяет результирующий html. Но не допускайте попадание избыточных данных в ID кеша: это приводит к расходу места на диске и снижает попадания в кеш (а значит эффективность кеширования).
component_epilog.php
Новые возможности кеширования в компонентах освещены отдельно:
Фото:
Добавил новость, появится на сайте, как сбросится кеш. Не думаю, что это проблема если новость появится через несколько минут после добавления. И разработчику не надо заморачиваться ни с какими тегами кеширования.
по событию добавления или удаления очищаете кеш. И не надо ни каких ключей.
с таким подходом можно реализовать практически любую логику очистки кеша.
В итоге мы получаем продукт достаточно дорогой, в котором есть все но по чуть чуть.
Да, вот, дескать, есть хорошие решения, но мы в своей работе используем битрикс. Постоянно им недовольны.
А насчет использования битрикс, пока нет возможности сменить платформу или должность. Приходится ездить на нем.
Много? кеш по событию добавления элемента.
Я прекрасно понимаю что очень многое можно доделать, доработать и тд. Но это как в анекдоте - после сборки тщательно обработать напильником. Только тут во время сборки.
Хотя скорей всего я не прав, битрикс все таки не фреймворк, и не позиционируется как самая универсальная платформа, для любых решений.
Вы как будто на другой планете живете. На которой пользователи сайтов не встречаются. Мне кажется что вы вообще не различате пользователей сайта и администраторов-редакторов.
На умных лекциях рассказываете о долях секунды, задержка на которые может отпугнуть пользователя, а здесь считаете что не нужно заморачиваться с криминальными задержками (которые неошибкой может считать лишь далекий от народа правитель) в самом главном для сайта - работе с информацией.
А за статью - спасибо.
Еще бы такую по работе с множественными свойствами инфоблоков.
Чтобы сбросить кеш страницы, не надо быть админом
1)в режиме автокеширования будут автоматически подключаться стили дочерних компонентов;
2)в режиме автокеширования можно будет исполнять код в шаблоне, в том числе дочерних компонентов.
Это если я к примеру в этом исполняемом файле начну делать запросы к БД и не прикручу CPHPCache к примеру, если он будет необходим.
Вадим, а Вы идеологически предполагаете что «один компонент» делает грубо говоря одну выборку «сущностей нужного типа из БД»(новости, продукты и прочее).
В идеологии компонент получается в конечном итоге N обращений, которые в конечном итоге приводят к формированию одного блока.
Вопрос:
Вы не пробовали смотреть в сторону абстрактного компонента, позволяющего грубо говоря несколько раз исполнить тот блок кода, который отвечает за выборку и формирование $arResult с их последующим объединением. Т.е. что бы в настройках можно было сначала указать один источник данных с настройками, потом нажать + и указать втрой источник данных и уже настройки выборки для него.
Пример:
Иногда может возникнуть потребность в частично «независимой» выборке. Т.е. я вот выбрал элементы из ИБ А и на основании результатов или не учитывая результаты произвёл выборку из ИБ Б
Т.е. это не выборки из связанных ИБ(их вполне успешно делаем на текущем API).
Сейчас подобная вещь реализуется или полностью уникальным компонентом, под конкретные нужны или выводом нескольких компнент.
Да, это несколько отличается от идеи «комплексного компонента», который собирает страницу или её блок из результатов работы отдельных компонент.
Я сейчас на первый взгляд не вижу особых преград для реализации подобной логики самостоятельно, но интересен именно «идеологический» аспект.
1)в режиме автокеширования будут автоматически подключаться стили дочерних компонентов;
Хочу еще напомнить про подключение яваскриптов (script.js) дочерних компонентов.
Данная возможность уже реализована?
Я использую последнюю версию Битрикса 12.5.9, тариф "Малый бизнес".
В шаблоне вывода подробной информации о товаре исполняется код и делается затем вывод мета-тега на страницу.
Однако при включенном автокэшировании результат выполнения кода в шаблоне пропадает.
Думаю, ссылка здесь на неё может кому-нибудь пригодиться.
Так об этом написано.
Кроме того, очень часто кастомизируется только шаблон стандартного компонента (сам компонент не трогается). В таких ситуациях часто приходится в шаблоны добавлять и логику, не только отображение.
Одним словом, правило красивое и идеологически правильное, но только на теории.
Что касается форума, шаблон действительно содержит логику, но он не работает с базой, не ставит заголовок страницы и пр., что не будет работать при кешировании.
У нас один сайт весь сайт построен на отзывах. Посетитель пишет отзыв, и после этого он должен сразу появиться в 4-местах. Так хотят посетители и так хочет заказчик. Сейчас из-за автокэширования этого не происходит. В ближайшее время будем дописывать обнуление кэша через события. Но если бы был тег, как предлагает Андрей, было бы просто здорово!
Ajax тоже недоделанный до сих пор -- с компонентами в связке неудобно работать. Можно сделать много удобнее если дать возможность через параметры присваивать ajax-идентификатор.
- неуправляемый и управляемый кеш (папки /bitrix/cache/, /bitrix/managed_cache и /bitrix/stack_cache) - можно перенести в память (значения - memcache, APC, xCache)
- "HTML-кеш" (папка /html_pages/) - хранится только в файлах, независимо от значения 'cache' > 'type' в .settings.php (пн.1)
?Разработал компонент, в котором подключаю CSS и JS файлы.
$this->addExternalCss('/bitrix/components/..../..../css/styles.css');
$this->addExternalCss($templateFolder . '/colors.css');
$this->addExternalJs('/bitrix/components/..../..../js/script.js');
if($arParams['JQUERY']=='Y')CJSCore::Init(array("jquery"));
Подключаю этот компонент в шаблоне компонента bitrix:catalog, в котором включено кеширование.
Чищу кеш - открываю - всё нормально.
Потом содержимое компонента bitrix:catalog кешируется вместе с моим подключенным компонентом, и мой компонент больше не подключает JS и CSS файлы....
Подскажите пожалуйста, как можно решить эту проблему, не отключая кеш компонента bitrix:catalog, при условии что на странице может быть несколько включений моего компонента (список товаров например).