Дата последнего изменения: 10.11.2023
Цитатник веб-разработчиков. Максим Месилов: С течением времени на проекте накапливается ворох «общих» функций, обработчиков событий, специфических библиотек и т.д. Очень часто всё это валят в init.php и там чёрт ногу сломит. |
Файл может содержать в себе инициализацию обработчиков событий, подключение дополнительных функций - общие для всех сайтов. В этом случае он располагается по пути /bitrix/php_interface/init.php
. Для каждого отдельного сайта может быть свой аналогичный файл. В этом случае он располагается по пути /bitrix/php_interface/ID сайта/init.php
. Если есть оба файла, то система подключит оба, но первым при этом будет файл /bitrix/php_interface/init.php
.
Начиная с версии 14.0.1 рекомендуется размещать этот файл в папке
/local
Чтобы сделать жизнь разработчиков проектов удобнее основные файлы проекта вынесены из папки /bitrix
в папку /local
. Это позволит изолировать изменяющиеся файлы проекта от папки продукта. По сути, в исключения достаточно будет добавить одну папку /bitrix
.
Подробнее ...
по пути /local/php_interface/ID сайта/init.php
. Файл /bitrix/php_interface/init.php
при этом перестаёт работать.
/bitrix/php_interface/ID сайта/init.php
не подключается в административном разделе, так как там отсутствует понятие сайта. Учтите и то, что SITE_ID
равен текущему языку и, следовательно, может подключиться не тот файл, который ожидался.Код условного отключения по значению $_SESSION
в файле init.php не работает, так как эта переменная определяется позже.
Чтобы init.php не превращался в свалку непонятного кода следует код размещать логически группируя по файлам и классам.
Рекомендуется придерживаться следующих самых общих правил:
session_start(); CModule::AddAutoloadClasses( '', // не указываем имя модуля array( // ключ - имя класса, значение - путь относительно корня сайта к файлу с классом 'CMyClassName1' => '/path/cmyclassname1file.php', 'CMyClassName2' => '/path/cmyclassname2file.php', ) );
$_SESSION
не доступна в init.php, так как ядро стартует сессию позже, совершая определенные настройки и проверки. Настоятельно не рекомендуется самостоятельно подключать сессию "руками".Как избежать проблем при редактировании init.php без ftp/ssh доступа
Ошибка в файле init.php приводит к полной потере работоспособности сайта и невозможности что-то исправить без доступа к файлу через ftp/ssh напрямую с диска. Такое возможно, например, в случаях:
Если доступ есть только через веб, то один из наиболее простых способов - вынос всего вашего кода во внешний файл и подключение его примерно так:
if (isset($_GET['noinit']) && !empty($_GET['noinit'])) { $strNoInit = strval($_GET['noinit']); if ($strNoInit == 'N') { if (isset($_SESSION['NO_INIT'])) unset($_SESSION['NO_INIT']); } elseif ($strNoInit == 'Y') { $_SESSION['NO_INIT'] = 'Y'; } } if (!(isset($_SESSION['NO_INIT']) && $_SESSION['NO_INIT'] == 'Y')) { if (file_exists($_SERVER["DOCUMENT_ROOT"]."/bitrix/php_interface/functions.php")) require_once($_SERVER["DOCUMENT_ROOT"]."/bitrix/php_interface/functions.php"); }
noinit=Y
- отключает подключение, noinit=N
- включает подключение. Свой функционал должен быть размещен (в примере) в /bitrix/php_interface/functions.php
.
Рекомендуется использовать собственное именование ключа. К примеру, nomysuperinit, так как курс в открытом доступе и любой может ознакомиться с этим методом, в том числе и с неблаговидными целями.
Хорошо если проверки безопасности и прочего не содержатся в этом файле, к тому случаю если злоумышленник все же угадает как отключить init.php.При таком подходе вы сможете безболезненно редактировать и допускать ошибки в файле functions.php, не боясь оказаться у разбитого корыта неработающего сайта без возможности как-то повлиять на ситуацию.
У разработчика проектов есть два способа постоянного использования уже созданных наработок: собственный модуль или файл init.php. Оба варианта имеют свои плюсы и минусы.
init.php. Когда у вас есть классы, единые для нескольких сайтов (при многосайтовости, или на одном сервере), то для удобства сами файлы с классами располагаются в одной папке, далее создаются символические ссылки.
Либо, при многосайтовости, есть и ещё один способ: воспользоваться уже готовыми папками. Например, папками шаблонов. (Теоретически, с точки зрения системы, это "шаблон", для нас - просто общее хранилище файлов.)
И при втором и первом способах код include $_SERVER["DOCUMENT_ROOT"]."/bitrix/templates/..."
ведет в одно и то же место для всех сайтов, где можно разместить общие для всех проектов файлы. В том числе никто не мешает создать свою папку для своих классов и уже оттуда их подключать, обращаясь к /bitrix/templates/my_classes/...
.
Использование симлинков на папки с кастомными библиотеками в точно такой же степени обязаны поддерживать совместимость как и модули. (Не важно где именно, при этом, они будут располагаться). Нет никакой особой разницы в подходах при поддержке и разработке, только охват проектов в первом случае ограничен рамками одного сервера.
Модули. Использование init.php будет предпочтительным если создаются проекты, которые точно всю жизнь проживут на одном сервере, и вы хотите максимально минимизировать затраты на поддержку кастомных библиотек. Желательно также чтобы эти библиотеки поддерживал один и тот же человек. Но если планируется эти наработки также использовать для заказных проектов, то дальновиднее делать модуль.
Модуль больше подходит для распространяемых API. При этом придется поддерживать и их интерфейс и формат ответа и другие параметры. Иначе: случайное обновление на одном из сайтов, использующих модуль, может оказаться роковым в случае изменения интерфейсов или форматов ответов API. Выигрыш спорный. С одной стороны - выигрываете, с другой - должны обеспечить пожизненные гарантии для всех использующих API модуля сайтов.