🛠 Битрикс: подводные камни архивирования событий
В разработке регулярно встречаются задачи, которые на первый взгляд выглядят элементарно. Например: «Нужно показывать предстоящие мероприятия отдельно, а прошедшие автоматически отправлять в архив».
Казалось бы, достаточно сравнить дату мероприятия с текущей. Но в одном из рабочих проектов на 1С-Битрикс выяснилось, что нюансов здесь значительно больше.
📌 С чего всё началось
Есть инфоблок с мероприятиями. У каждого элемента предусмотрены дата проведения ("PROPERTY_DATETIME") и признак архива ("ARCHIVE").
Задача — корректно разделять мероприятия на две группы:
— актуальные, которые ещё не завершились;
— архивные, которые уже прошли или были явно отмечены как архивные.
При этом нужно учитывать не только дату, но и время мероприятия, ручной признак архива и особенности работы компонентов Битрикс.
⚙️ Где возникают сложности
Первый очевидный вариант — использовать фильтр в "CIBlockElement::GetList" или передать его в "news.list".
Например, для отбора предстоящих событий:
">=PROPERTY_DATETIME" — текущая дата и время.
Но здесь возникает первый нюанс: что именно хранится в свойстве — дата или дата со временем?
Если сравнивать только календарные даты, мероприятие, завершившееся утром, может оставаться актуальным до конца дня.
А если использовать точное время, необходимо корректно учитывать формат значения, преобразование даты и часовой пояс.
В Битрикс для этого есть свои инструменты, например "DateTime::createFromUserTime()" и "ConvertTimeStamp()".
🧩 Второй нюанс — ручной архив
Не все мероприятия должны переходить в архив исключительно по времени.
Иногда элемент необходимо скрыть из актуального списка раньше, поэтому используется отдельное свойство "ARCHIVE".
И здесь фильтрация становится составной:
— дата мероприятия ещё не прошла;
— элемент не отмечен как архивный.
Для архивного списка логика обратная: мероприятие уже прошло или явно помечено как архивное.
Причём нужно учитывать, что "ARCHIVE" может быть свойством типа «Список», а значит, при построении фильтра важно правильно работать со значениями перечисления.
🔄 Третий нюанс — кеширование
Даже корректный фильтр не гарантирует, что пользователь сразу увидит правильный результат.
Представим, что мероприятие должно перейти в архив в 15:00, но компонент закешировал список в 14:55.
Если кеш продолжает действовать, элемент может оставаться в актуальных мероприятиях уже после наступления времени перехода.
Поэтому при реализации важно учитывать не только условия выборки, но и жизненный цикл кеша.
💡 Что в итоге
Такие задачи хорошо показывают особенности работы с существующими CMS.
Внешне изменение небольшое: разделить список мероприятий на две части.
Но за ним стоят несколько отдельных вопросов: корректное сравнение дат, логические условия фильтрации, свойства инфоблока и актуальность кешированных данных.
И самое интересное здесь — не количество написанного PHP-кода, а необходимость заранее продумать граничные сценарии.
А вам приходилось сталкиваться с ситуацией, когда корректная логика фильтрации работала неправильно именно из-за кеширования или особенностей хранения дат? Как решали?
