-
What is Bitrix Framework?
-
Production Architecture
-
Production Architecture
-
Structure of files
-
Access Rights
-
A Site in Terms of Bitrix Framework
-
-
Processing Techniques
-
Core D7
-
Modules
-
Name Spaces
-
Core Parameter Setup
-
Exceptions
-
Events
-
Code Writing Rules
-
Applications and Context
-
Errors
-
ORM
-
API
-
Highloadblock
-
-
Design Integration
-
Using Access Rights
-
Site Design Template
-
Using message files for localization
-
Editable areas
-
Navigation tools
-
Advertisement
-
Managing Template Service Data
-
Editing Service Areas
-
Managing Page Encoding
-
Managing Document Header
-
Managing Metadata Values
-
CSS management
-
-
Setup of External Appearance of Additional Elements of the Site Design
-
-
Information Blocks
-
Working with Infoblocks Using Standard Means
-
Infoblocks 2.0
-
Action Plan in Case of Problems
-
Sorting
-
Work with Infoblocks through API
-
Examples
-
-
Components
-
Simple and composite components
-
Location of a Component in the System and Its Connection
-
Component Structure
-
Composite Component Structure
-
Component Description
-
Component Parameters
-
Component Templates
-
Support of Component Classes
-
result_modifier.php
-
component_epilog.php
-
Operation of a Composite Component in a SEF Mode
-
Frequent Errors
-
Component Caching
-
Working with Components
-
Template Customization
-
Component Customization
-
Creating Components
-
Additional Methods
-
Redefinition of Incoming Variables
-
User-Defined Templating Engines
-
Operation of a Composite Component in SEF Mode
-
Ways of Data Transmission among Components
-
A Simple Example of a Component Creation
-
Component Creation Example
-
TinyMCE Visual Editor Integration Component
-
Caching in own components
-
-
CUSTOM Parameter Type
-
More examples
-
Errors When Working with Components
-
-
-
Modules
-
Programming in Bitrix Framework
-
Golden Rules
-
The file init.php
-
UTF-8 or a National Encoding?
-
Working with Databases
-
Setup of SEF for URLs
-
Language Files
-
JS Library
-
Interface of the Control Panel Toolbar as Seen by a Developer
-
Some Theory
-
Performance
-
Security
-
Examples, tricks, and advice
-
Custom Fields
-
Gadgets
-
Project Testing
-
Project Quality Control
-
Debugging Web Applications
-
-
Push and Pull module
-
Version Control System
-
-
Multiple Sites
-
Introduction
-
Use of Multiple Site Version
-
How many sites can I create?
-
Language versions (mirrors)
-
Sharing visitors between sites
-
Configuring the multisite system
-
Working with the Data in a Multiple Site Configuration
-
Frequent Questions Arising When Working with a Multiple Site Configuration
-
-
Business Processes for Developer
-
Template of a Business Process
-
Business Process
-
Activities
-
Executing a business process activity using API
-
Arbitrary PHP Code in a Business Process
-
-
Additional Information and Examples
The file init.php
Lesson 156 out of 253
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.
/bitrix/php_interface/website ID/init.php
is not connected in the administrative section because there is no notion of a website. Please also take into account that SITE_ID is equal to the current language and, consequently, a wrong file can get connected.A code in init.php should be located according to logical grouping by files and classes.
The following very general rules should be followed:
- 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', ) );
- If the functionality is used only on one of the websites in the system, it should be placed in its own init.php;
- 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"); }
/bitrix/php_interface/functions.php
.
It is recommended to use an own key name. For example, nomysuperinit, because the training course is in open access, and anyone can get to know this method, including those who have malign purposes.
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.