242  /  382
Справочник

Файл init.php

Просмотров: 122019
Дата последнего изменения: 10.11.2023
Роберт Басыров
Сложность урока:
3 уровень - средняя сложность. Необходимо внимание и немного подумать.
1
2
3
4
5
Недоступно в лицензиях:
Ограничений нет

Файл init.php

Цитатник веб-разработчиков.

Максим Месилов: С течением времени на проекте накапливается ворох «общих» функций, обработчиков событий, специфических библиотек и т.д. Очень часто всё это валят в init.php и там чёрт ногу сломит.

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

Файл может содержать в себе инициализацию обработчиков событий, подключение дополнительных функций - общие для всех сайтов. В этом случае он располагается по пути /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 не превращался в свалку непонятного кода следует код размещать логически группируя по файлам и классам.

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

  1. init.php содержит только подключения файлов. Причем подключать эти файлы желательно через __autoload. Штатными средствами это делается так:
    session_start();
    CModule::AddAutoloadClasses(
    	'', // не указываем имя модуля
    	array(
    		// ключ - имя класса, значение - путь относительно корня сайта к файлу с классом
    			'CMyClassName1' => '/path/cmyclassname1file.php',
    			'CMyClassName2' => '/path/cmyclassname2file.php',
    		)
    );
  2. Если функционал используется только на одном из сайтов в системе, то он выносится в свой init.php;
  3. Обработчики событий лучше группировать в одном файле и тщательно аннотировать где они используются и какая задача перед ними стоит.

Примечание: Переменная $_SESSION не доступна в init.php, так как ядро стартует сессию позже, совершая определенные настройки и проверки. Настоятельно не рекомендуется самостоятельно подключать сессию "руками".

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

Как избежать проблем при редактировании 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");
}

Примечание: Параметр в адресной строке noinit=Y - отключает подключение, noinit=N - включает подключение. Свой функционал должен быть размещен (в примере) в /bitrix/php_interface/functions.php.

Рекомендуется использовать собственное именование ключа. К примеру, nomysuperinit, так как курс в открытом доступе и любой может ознакомиться с этим методом, в том числе и с неблаговидными целями.

Хорошо если проверки безопасности и прочего не содержатся в этом файле, к тому случаю если злоумышленник все же угадает как отключить init.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 модуля сайтов.

54
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии