Перейти к содержимому
BXWiki

Основы разработки на 1С-Битрикс

Базовый раздел для тех, кто начинает работать с 1С-Битрикс. Пригодится и тем, кто хочет навести порядок в понимании платформы. Здесь - устройство ядра и файловой структуры, окружение и правила кода. Отдельная тема - легаси: старое ядро в реальных проектах встречается повсеместно. CIBlockElement, CUser, CSaleOrder важно уметь читать, безопасно править и постепенно переводить на D7. Статьи раздела рассказывают об одном принципе платформы на разном материале. Это стоит увидеть до того, как читать остальные 46 статей справочника.

Как устроено

Основные статьи раздела повторяют один принцип: «расширяй и переопределяй в отдельном месте, оригинал не трогай». Меняется только масштаб. Так работает файловая структура: /local/ побеждает /bitrix/ при совпадении путей. Так же оформляют код («Стандарты кода»): кастомный код только в /local/. Файлы ядра не редактируются никогда. То же с окружением («Окружение и деплой»): свои настройки nginx и MySQL живут в файлах z_bx_custom.*. Стандартные конфиги обновление перезаписывает. Тем же принципом объясняется сосуществование двух ядер («Старое ядро»). Новый код пишут на D7, а легаси не переписывают. Три статьи о рабочих инструментах повторяют это правило на своём материале. Свой Dockerfile донастраивает официальный образ, а не редактирует его («Docker-окружение»). composer.json выносят за пределы /bitrix/, чтобы обновление его не стёрло («Composer и автозагрузка»). Заглушки для IDE подключают только настройками редактора («Автодополнение и IDE»).

«Архитектура» отвечает, откуда берутся объекты старого ядра. «Старое ядро» - что с ними делать. В «Архитектуре платформы» жизненный цикл запроса расписан по шагам. На одном шаге пролога создаётся $APPLICATION, на следующем открывается сессия и появляется $USER. «Старое ядро» берёт эти же объекты, учит с ними работать и постепенно мигрировать на D7-аналоги. Прочитать «Старое ядро» без «Архитектуры» можно. Но происхождение глобальных объектов и порядок, в котором они становятся доступны, останутся неочевидными. А именно из этого порядка следуют самые частые ошибки вроде «сессия не работает в init.php».

К внешним стандартам платформа избирательна, а не «всё или ничего». Это видно в двух статьях. D7 использует PSR-4, PSR-3, PSR-11, PSR-16 и PSR-18 как контракты интеграции. А PSR-12 сознательно не соблюдает: табы вместо пробелов. Ключи массивов данных - в верхнем регистре, открывающая скобка класса - с новой строки. То же выборочное заимствование - в окружении. Готовый стек BitrixVM собран из обычных nginx, Apache, MySQL и Redis. Но управляется своим консольным меню и моделью ролей, а не голыми конфигами каждого сервиса.

Переход со старого ядра здесь - центральный сценарий. В других разделах легаси - редкий гость на полях. Здесь ему посвящена отдельная статья. Она адресована тем, кто получил в наследство работающий проект, а не начинает с нуля.

Что нужно сделать

НужноСмотрите
Понять, из чего собрана платформа и что где лежитАрхитектура платформы
Поднять рабочее окружение и выкатывать измененияОкружение и деплой
Собрать локальную копию проекта в контейнерахDocker-окружение
Писать код, который переживёт обновление платформыСтандарты кода
Подключить стороннюю библиотеку через ComposerComposer и автозагрузка
Получить подсказки и переход к определению в редактореАвтодополнение и IDE
Разобраться в чужом коде на классах с префиксом CСтарое ядро

С чего начать

Новичок на платформе. Это единственный раздел справочника, где статьи стоит читать по порядку, а не по конкретной задаче. Начните с «Архитектуры платформы». Без картины двух ядер, /local/ и жизненного цикла запроса остальные статьи читаются как разрозненные приёмы.

Переход со старого ядра или унаследованный проект. Сразу к «Старому ядру». Там - таблица прямых соответствий legacy-API и D7. Там же - где легаси остаётся штатным решением, а не кандидатом на переписывание.

Новое окружение или первый деплой. «Окружение и деплой»: готовый стек BitrixVM и критические параметры php.ini. Там же - куда класть свои настройки сервера, чтобы пережили обновление. Для локальной разработки в контейнере - соседняя статья «Docker-окружение». Тот же список требований платформы, но применённый к образам, правам на файлы и часовому поясу.

Подключаете библиотеку или IDE не видит классы Битрикса. «Composer и автозагрузка» - куда класть composer.json. Там же - как он уживается со штатным Loader. «Автодополнение и IDE» - откуда берутся заглушки и аннотации ORM, если подсказки молчат или врут.

Темы раздела

  • Архитектура платформы: два ядра, файловая структура, жизненный цикл запроса - точка отсчёта для всего справочника.
  • Окружение и деплой: готовый стек BitrixVM и тот же принцип «своё - отдельно от оригинала», применённый к серверным настройкам.
  • Docker-окружение: тот же список требований платформы, что и у BitrixVM, но собранный вручную из контейнеров - и то, что при этом обычно приходится донастраивать.
  • Стандарты кода: архитектурные соглашения важнее оформления - и то, что платформа берёт из PSR, а что нет.
  • Composer и автозагрузка: второй автозагрузчик классов рядом со штатным Loader - и куда класть composer.json, чтобы обновление платформы его не стёрло.
  • Автодополнение и IDE: почему редактор не видит часть классов Битрикса из коробки и как вернуть подсказки заглушками и аннотациями ORM.
  • Старое ядро: как читать и мигрировать легаси - и где оно остаётся штатным решением навсегда.

Практика раздела

Частые вопросы

С чего реально начинать - с архитектуры или сразу с нужной задачи?

Именно в этом разделе - с архитектуры, в отличие от остального справочника. В других разделах уместно идти от конкретной задачи к нужной статье, но здесь основные статьи выстроены как одна линия: без картины двух ядер и файловой структуры из «Архитектуры платформы» истории про легаси, стандарты и окружение теряют часть смысла. Три статьи о рабочих инструментах - Composer, Docker, IDE - устроены иначе: к ним обращаются по конкретному поводу, а не по порядку, как к остальному справочнику.

Правило «весь свой код - в /local/» - это специфика компонентов, или более общий принцип?

Более общий принцип, который в разделе повторяется на разных масштабах. На уровне кода - это компоненты, модули и шаблоны в /local/. На уровне окружения - тот же принцип, только для конфигурации сервера: свои настройки nginx и MySQL хранят в отдельных файлах с префиксом z_bx_custom, которые обновление окружения не трогает, в отличие от стандартных конфигов.

Роли и пул в BitrixVM - это то же самое, что модули платформы?

Нет, разные уровни абстракции, хотя термины на слух похожи. Модуль - единица функциональности внутри самого приложения: iblock, catalog, sale, каждый со своей ответственностью в коде. Роль в терминах BitrixVM (web, mysql, memcached, sphinx, push-server) - это назначение конкретного сервера в инфраструктуре, а пул - группа таких серверов под общим управлением. Модуль относится к тому, что выполняется, роль - к тому, на чём это выполняется.

Проверка B_PROLOG_INCLUDED в начале каждого файла - это часть жизненного цикла запроса или отдельное правило?

Отдельное правило поверх жизненного цикла, а не его часть. Жизненный цикл описывает, что происходит при обычном обращении к странице через пролог и эпилог. Проверка B_PROLOG_INCLUDED защищает как раз от обхода этого цикла - прямого вызова файла компонента или шаблона по URL, минуя пролог целиком. Без неё чужой файл выполнится изолированно, без прав доступа, без сессии и без остальной инфраструктуры, которую обычно поднимает пролог.

Связанные разделы

  • Ядро D7 - современная часть той же дуальной архитектуры, разобранной в этом разделе только на уровне общей картины.
  • Инфраструктура - тонкая настройка сервера и релизный процесс - продолжение темы окружения на масштаб выше отдельного проекта.
  • Модули - тот же принцип «свой код - в /local/», применённый к модулям, а не только к компонентам и шаблонам.
  • Безопасность - экранирование и права доступа - обязательная часть стандартов кода, вынесенная в собственный раздел.