Файл 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 при этом перестаёт работать.

Код условного отключения по значению $_SESSION в файле init.php не работает, так как эта переменная определяется позже.

Чтобы init.php не превращался в свалку непонятного кода следует код размещать логически группируя по файлам и классам.

Рекомендуется придерживаться следующих самых общих правил:

1. init.php содержит только подключения файлов. Причем подключать эти файлы желательно через __autoload. Штатными средствами это делается так:

   CModule::AddAutoloadClasses(
   	'', // не указываем имя модуля
   	array(
   		// ключ - имя класса, значение - путь относительно корня сайта к файлу с классом
   			'CMyClassName1' => '/path/cmyclassname1file.php',
   			'CMyClassName2' => '/path/cmyclassname2file.php',
   		)
   );

2. Если функционал используется только на одном из сайтов в системе, то он выносится в свой init.php;
3. Обработчики событий лучше группировать в одном файле и тщательно аннотировать где они используются и какая задача перед ними стоит.

Проблемы при редактировании

Как избежать проблем при редактировании init.php без ftp/ssh доступа

Ошибка в файле init.php приводит к полной потере работоспособности сайта и невозможности что-то исправить без доступа к файлу через ftp/ssh напрямую с диска. Такое возможно, например, в случаях:

• У клиента хостинг под Windows, а у вас "серый" IP и ftp не работает.
• Хостинг под Linux, но php и ftp работают из-под разных пользователей и файл недоступен для редактирования по ftp.
• У клиента свой сервер и доступ по ftp он не дает.

Если доступ есть только через веб, то один из наиболее простых способов - вынос всего вашего кода во внешний файл и подключение его примерно так:

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");
}

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

init.php vs собственный модуль

У разработчика проектов есть два способа постоянного использования уже созданных наработок: собственный модуль или файл init.php. Оба варианта имеют свои плюсы и минусы.

init.php. Когда у вас есть классы, единые для нескольких сайтов (при многосайтовости, или на одном сервере), то для удобства сами файлы с классами располагаются в одной папке, далее создаются символические ссылки.

Либо, при многосайтовости, есть и ещё один способ: воспользоваться уже готовыми папками. Например, папками шаблонов. (Теоретически, с точки зрения системы, это "шаблон", для нас - просто общее хранилище файлов.)

И при втором и первом способах код include $_SERVER["DOCUMENT_ROOT"]."/bitrix/templates/..." ведет в одно и то же место для всех сайтов, где можно разместить общие для всех проектов файлы. В том числе никто не мешает создать свою папку для своих классов и уже оттуда их подключать, обращаясь к /bitrix/templates/my_classes/....

Использование симлинков на папки с кастомными библиотеками в точно такой же степени обязаны поддерживать совместимость как и модули. (Не важно где именно, при этом, они будут располагаться). Нет никакой особой разницы в подходах при поддержке и разработке, только охват проектов в первом случае ограничен рамками одного сервера.

Модули. Использование init.php будет предпочтительным если создаются проекты, которые точно всю жизнь проживут на одном сервере, и вы хотите максимально минимизировать затраты на поддержку кастомных библиотек. Желательно также чтобы эти библиотеки поддерживал один и тот же человек. Но если планируется эти наработки также использовать для заказных проектов, то дальновиднее делать модуль.

Модуль больше подходит для распространяемых API. При этом придется поддерживать и их интерфейс и формат ответа и другие параметры. Иначе: случайное обновление на одном из сайтов, использующих модуль, может оказаться роковым в случае изменения интерфейсов или форматов ответов API. Выигрыш спорный. С одной стороны - выигрываете, с другой - должны обеспечить пожизненные гарантии для всех использующих API модуля сайтов.