14.12.2025
Ниже — подробный практический чек‑лист под коробочный Bitrix (Управление сайтом / Битрикс24), адаптированный под типичные задачи: интеграции, кастомные компоненты, обновления и безопасность.
## 1. Организация среды и обновлений
- Держите минимум две среды: prod и staging (копия боевого портала с теми же версиями PHP, Битрикс и модулей).
- Перед любыми крупными доработками и обновлениями делайте полную резервную копию файлов и БД, а обновления сначала гоняйте на staging.
## 2. Где можно и нельзя править код
- Никогда не правьте файлы ядра и модулей в `/bitrix/modules`, `/bitrix/js`, `/bitrix/components/bitrix`, не меняйте стандартные классы без расширения через события.
- Пользовательский код размещайте только в `/local/php_interface`, `/local/components`, `/local/modules`, `/local/templates`, `/local/tools`, чтобы обновления не затёрли изменения и кастом легко находился.
## 3. Шаблоны, компоненты и интерфейс
- Для изменения верстки стандартных компонентов копируйте шаблон в `/local/templates/
/components/bitrix/...` и правьте там, не трогая исходный шаблон.
- Собственные компоненты делайте в `/local/components//` с корректной структурой, разделением логики (`component.php`) и шаблонов (`/templates/.default/*`).
## 4. Бизнес‑логика и события
- Бизнес‑логику выносите в обработчики событий (например, `OnBeforeUserRegister`, `OnAfterIBlockElementAdd`) и сервисные классы; регистрируйте их через `init.php` или модуль в `/local/modules`.
- Старайтесь не вмешиваться в штатные сценарии через «костыли» в шаблонах или правку системных скриптов; если нужно расширение — ищите подходящий хук/событие или REST/WEB‑hook в Битрикс24.
## 5. Интеграции и внешние сервисы
- Для интеграций используйте REST / веб‑хуки (в Битрикс24) либо отдельные сервис‑классы/модули c чётким логированием запросов, таймаутами и ретраями.
- Храните ключи и токены в настройках модулей, `.settings.php` или переменных окружения, но не в коде и не в публичном репозитории; ограничивайте права интеграционных пользователей.
## 6. Обновления ядра и модулей
- Перед обновлением ядра и сторонних модулей проверяйте целостность ядра, список кастомизаций и changelog модулей на тестовой копии.
- После обновления прогоняйте регрессионные тесты ключевых сценариев (авторизация, оформление заказа, CRM‑воронки, интеграции) и мониторьте логи ошибок минимум несколько дней.
## 7. Минимальные требования по безопасности к коду
- Не пишите прямые SQL‑запросы к БД, используйте ORM/`CIBlockElement`, `UserTable` и прочее документированное API, чтобы не обходить встроенную безопасность и не ломать согласованность данных.
- Фильтруйте входные данные, экранируйте вывод (`htmlspecialcharsbx`, компоненты с `FILTER`/`ESCAPE`) и не смешивайте HTML и PHP‑логику в одних файлах: в шаблоне — верстка и минимальная логика, в классе/компоненте — бизнес‑код.
## 8. Управление кастомом и документация
- Ведите внутренний реестр доработок: где лежит код, какие события задействованы, какие модули и версии требуются, какие интеграции подключены.[5][1]
- Документируйте типовые сценарии деплоя (структура repo, ветки, команды миграций, порядок выката) и не выкатывайте изменения на prod «вручную по FTP» без фиксации в системе контроля версий.
Если нужно, можно дальше развернуть отдельные разделы под твой стек: например, типовой паттерн для кастом‑модуля в `/local/modules` или безопасный пайплайн деплоя (git → CI → rsync/SSH → миграции БД) под твои сервера.
