The file init.php

The file may contain the initialization of event handlers and connection of additional functions that are common for all websites. In this case, it shall be located in the path /bitrix/php_interface/init.php. Each particular website may have its own similar file. In this case, it shall be located in the path /bitrix/php_interface/website ID/init.php. If both files are there, the system will connect them both, but the file /bitrix/php_interface/init.php will be the first.

A code in init.php should be located according to logical grouping by files and classes.

The following very general rules should be followed:

1. init.php contains only file connections. These files are better connected through __autoload. It can be done as follows using the standards means

   CModule::AddAutoloadClasses(
           '', // we do not indicate the name of the module
           array(
              // key – a class name, value – a path from the website root to the file with the class
                   'CMyClassName1' => '/path/cmyclassname1file.php',
                   'CMyClassName2' => '/path/cmyclassname2file.php',
           )
   );

2. If the functionality is used only on one of the websites in the system, it should be placed in its own init.php;
3. Event handlers should be grouped in the same file and accompanied with a detailed note indicating where they are used and what task they solve.

How to avoid problems during editing init.php without ftp/ssh access

An error in the file init.php results in the complete inoperability of the website and it is impossible to correct anything without access to the file through ftp/ssh. This may occur in the following cases:

• The client has a Windows-based hosting, and you have a “gray” IP and ftp will not work.
• The hosting is Linux-based, but php and ftp work from different users, and the file is unavailable for editing through ftp.
• The client has its own server that is denying you access through ftp.

If the access is available only through Web, one of the simplest ways is to place all of your code in an external file and connect it like this:

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

With such an approach you will be able to safely edit and make errors in the file functions.php without fear of getting an inoperable website that cannot be recovered without ftp.

init.php or Own Module?

A project developer has two ways to use already created solutions: own module or the file init.php. Both options have their advantages and disadvantages.

init.php. When you have classes that are common for several websites (in case of multiple websites or on the same server), the files containing classes are located in the same folder for the sake of convenience. Later on, symbolic links are created.

In case of multiple websites, there is one more way: to use already created folders. For example, folders with templates.

Both in the second and the first ways the code include $_SERVER["DOCUMENT_ROOT"]."/bitrix/templates/..." will lead to the same place for all websites where the files that are common for all projects can be located. In addition, own folder may be created for own classes, and connect classes from there by accessing /bitrix/templates/my_classes/....

Module. The use of init.php is preferable if you create projects that are sure to be located on the same server throughout the entire existence of such projects, and you want to keep the expenses associated with the support of custom libraries to a minimum. These libraries are better supported by the same person. However, if you plan to use these solutions for other projects, a separate module should be created.

The module suits more for distributed APIs. In this case, their interface will also have to be supported along with response format and other parameters. Otherwise, an occasional update on one of the websites using the module may be fatal in case of change of interfaces or API response formats. On the one hand, you win; on the other hand, you must create guarantees for all of the websites that use the module API.