Контекст: корпоративная разработка и аутсорс

Я работаю в крупной компании, где часть проектов ведут внешние подрядчики. Формально всё выглядит прилично: сайт на Битрикс, современный дизайн, аккуратный фронт. Но под капотом — типичные проблемы аутсорса: непредсказуемое качество кода, отсутствие стандартов, странные решения в самых чувствительных местах.

В этом кейсе всё началось с банальной задачи: отредактировать SEO-поля через фронт-панель Битрикс. Казалось бы, безопасный и штатный сценарий.

Как одна правка SEO превратилась в баг

При попытке изменить заголовок и description для конкретной статьи через визуальную панель, данные внезапно «уехали» не в конкретный элемент, а в общий шаблон детального отображения материалов. Слетел весь раздел. Надеюсь того, кто создал данный шедевр, ожидает отдельный котел.

Ошибки разработчиков были на уровне архитектуры:

• логика вывода SEO-мета-данных была «зашита» прямо в шаблон, а не вынесена в отдельную логику или компонент;
• вместо стандартного механизма SEO для элементов разработчики использовали статические или полу-динамические значения в шаблоне;
• фронт-панель была встроена прямо в шаблон, при этом данные записывались не в БД, а в шаблонное окружение.

В результате:

• любые изменения SEO с фронта попадали в общий шаблон;
• одна правка могла сломать мета-данные на всех страницах;
• SEO привязывался к макету, а не к сущности.

Как делать нельзя

• смешивать слой представления и хранение данных;
• делать шаблон «запоминающим» значения из интерфейса;
• обходить стандартные механизмы Битрикс ради быстрых решений.

Как делать правильно

• использовать штатные SEO-поля инфоблоков;
• хранить значения в БД, а шаблон использовать только для вывода;
• разделять админ-интерфейс и шаблон;
• контролировать, куда пишет визуальный редактор.

Попытка исправить шаблон на бою — и блокировка

Логичный следующий шаг — исправить шаблон. Но вмешиваются ограничения безопасности:

• редактирование кода на продакшене запрещено;
• действуют политики безопасности и дополнительные проверки;
• любые изменения через интерфейс блокируются.

Остаётся единственный вариант — развернуть локальную копию и работать через репозиторий.

Локальная версия, которая «не поднимается»

Сайт и база были частично восстановлены через restore.php. Кстати, разработчикам данной системы — тоже отдельный котел в аду. Но возникли проблемы:

• медленная распаковка больших архивов;
• чувствительность к сетевым условиям;
• тайм-ауты и проверки лицензии;
• падения процесса.

Итог:

• база уже развернута;
• файлы — частично;
• restore нестабилен.

Обходной путь: ручное восстановление

1. Объединение архива

• собрать все части в один .tar.gz;
• проверить целостность;
• протестировать распаковку отдельно.

2. Ручная распаковка

• распаковать архив без restore.php;
• использовать уже поднятую БД;
• настроить права и конфиги под локальную среду.

3. Подъём проекта

• настроить контейнер или виртуальный хост;
• проверить работу сайта;
• синхронизировать пути.

Неочевидный момент: данные живут в БД

После запуска выяснилось:

• SEO-данные находятся в базе;
• шаблон их не контролирует;
• git не отслеживает такие изменения.

Вывод:

• репозиторий — это только код;
• данные — отдельная зона ответственности;
• ошибки через админку могут не попадать в git.

Выводы

Что получилось:

• рабочий способ обхода restore;
• сценарий ручного восстановления;
• понимание границы между кодом и данными.

Цена решения:

• вместо 1 часа — 3 рабочих дня;
• основное время ушло на диагностику, ограничения безопасности и работу с архивами.

Как правильно работать с SEO в Битрикс

В Битрикс есть штатные механизмы для работы с SEO, которые позволяют хранить мета-данные в базе данных и выводить их через компоненты.

1. Штатные SEO-поля

• админка: Контент → Инфоблоки → SEO;
• параметры компонентов;
• .parameters.php;
• result_modifier.php;
• template.php.

2. Хранение в БД

• поля инфоблоков;
• классы InheritedProperty;
• header.php с SetTitle и SetPageProperty.

3. Разделение логики

• админка отдельно;
• компоненты редактирования отдельно;
• ограничение прав через .access.php.

4. Контроль редактора

• использовать стандартные компоненты;
• не писать в шаблон;
• работать через API.

5. Практическая схема

1. Определить SEO-поля;
2. Настроить инфоблок;
3. Подготовить данные через result_modifier.php;
4. Выводить через header.php;
5. Запретить правку шаблонов с фронта;
6. Редактировать SEO только через админку.

Такой подход исключает ситуацию, когда SEO-данные начинают влиять на все страницы сразу.