Bitrix Framework has several specific core settings that do not have an edit interface. Such design choice is due to occurrences when settings update or error in them can easily lead to rendering the whole system inoperable (due to database connection setting, caching settings and etc.).
Settings in a Core D7 are entered in the file /bitrix/.settings.php. Please be advised, that in the old core/kernel similar settings were made in the file \bitrix\php_interface\dbconn.php. The file .settings.php differs significantly from the former dbconn.php in terms of structure.
Note: due to the fact that the system uses 2 cores in parallel - old kernel and the new D7, both settings files are used simultaneously. That's is why you must configure both files.
Even if you are using the old kernel's code, the file .settings.php is still must be created. A situation is possible when upon installing the updates, some of the in-built system mechanisms will be re-written to the new core. If this file is not configured correctly, it could lead to system inoperability.
In some cases, the .settings.php file is missing. It can be created automatically, via executing it in
PHP Command line - system tool, allowing to launch arbitrary code on PHP with function calls.
Note: Some sections of the setting file contain the readonly parameter. This parameter means that these settings will not be amended through API.
In addition, these settings can be specified in the file .settings_extra.php. Basic settings file contains invariable settings, with available API. File .settings_extra.php can contain arbitrary code that changes settings dynamically. Accordingly, it doesn't have API functions.
Below are parameters that can be modified:
Parameters that may be changed are described below:
Responsible for caching settings and permits to set the caching method and its parameters.
Before version 18.5.200, the old record format was as follows:
In the version 18.5.200 the record format was updated simultaneously with the option to use Redis in caching. Presently, both formats are operational, however vendor strongly recommends to use new record format.
Examples of new record format for various caching methods.
Base file .settings.php contains invariable settings that have API functions. The file .settings_extra.php may contain arbitrary code that updates settings depending on various factors. Accordingly, this file doesn't contain API for setting updates. Naturally, array with the same base file structure will be returned upon executing this arbitrary code.
the logging will be made into a file with limited size. If site root contains the file error.php and error printing on screen is enabled, this file will be connected in case of unprocessed exception.
If set in a general case, logging can be made to anywhere:
'log' => array(
'class_name' => 'MyLog', // custom log class, must extends ExceptionHandlerLog;
// can be omited, in this case default Diag\FileExceptionHandlerLog will be used
'extension' => 'MyLogExt', // php extension, is used only with 'class_name'
'required_file' => 'modules/mylog.module/mylog.php' // included file, is used only with 'class_name'
'settings' => array( // any settings for 'class_name'
The provided example:
class_name - custom class, descendant from \ExceptionHandlerLog. May not be specified. In this case, uses \Bitrix\Main\Diag\FileExceptionHandlerLog.
extension - PHP extension, use only jointly with class_name.
required_file - enabled file. Used only jointly with class_name.
settings - settings for class, specified in class_name
Enabling support for command assert.
The key specifies only error types for which the incorrect assert throws exception.
Error type must be passed in handled_errors_types, exception_errors_types, assertion_error_type. Error type is a numerical code. For example, parameter exception_errors_types. And what does such record means: E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_USER_WARNING & ~E_USER_NOTICE & ~E_COMPILE_WARNING?
First, let's refer to levels of PHP error interpreter. There are specific values and determined constants matching them. In our case, this record means that E_ALL (constant value 2047), is bit-wise and not E_NOTICE, and not E_WARNING and not E_STRICT and not E_USER_WARNING and not E_USER_NOTICE and not E_COMPILE_WARNING. That is E_ALL with exception of previosuly specified constants that define one or the other PHP interpreter error level.
Database and other data source connection parameters. The class name and connection parameters are specified.
Also, for this purpose, mysqli extension can be installed via PHP. Additional checks for extension availability are not performed! Mysqli can be enabled separately for the old (dbconn.php) and the new (.settings.php) core D7.
Checkboxes of persistent connection and deferred connection with the database. Example:
Connection::PERSISTENT == 1
Connection::DEFERRED == 2
Their combinations can be recorded via bit operations. Example 3 - both PERSISTENT and DEFERRED.
The key specifies which connection must be used for read (read key). Connection must be created, where class, host and port are specified. The example of code above, 'read' parameter is specified with the handlersocket value. Below is the description for the handlersocket connection.
Class name, that receives the result of handling the specific database type.
host name, where the database is located; can be specified with the port
path to connect to server (http) to receive commands
path to connect to server (https) to receive commands
path to connect to server for modern web browsers (http) to receive command
path to connect to server for modern browsers (https) to receive commands
path to connect to server for modern browsers with socket support (http) to receive commands
path to connect to server for modern browsers with web-socket support (https) to receive commands
path to publish commands from the server
path to publish commands from the web browser (http)
path to publish commands from the web browser (https)
queue server version
number of channels to his which the same data will be sent per hit
enables the queue server
allows to send special headers
enables the queue server
activates the web-sockets
secret signature key for messages
signature encryption algorithm
enables module active status for guests
enables new format for messages
maximum size of a message in bytes
maximum number of messages per hit
maximum number of channels per hit
This section specifies by default options for the Bitrix\Main\Web\HttpClient class.
true by default, execute redirect
maximum number of such redirects (by default: 5)
if true - wait for response (by default), otherwise - return the response immediately
response timeout period in seconds (by default: 30)
stream timeout in seconds (by default: 60)
version http - 1.0 or 1.1 (by default: 1.0)
proxyHost / proxyPort / proxyUser / proxyPassword
parameter group to setup a proxy
if true, sends Accept-Encoding: gzip
encoding for the object body (is used in the header field for the Content-Type request for POST and PUT)
if true, ssl certificates verification will not be performed
'redirect' => true,//execute redirects, if required
'redirectMax' => 10,//but not more than 10
'version' => '1.1'//work via the http 1.1 protocol
'readonly' => false,
You can check if your settings are correct as follows:
Your array should be displayed.
This section is intended for registering services. Find more details in the lesson
Service locator is a design template for convenient handling of application services. Instead of creating specific services directly (via new) service locator is responsible for creating and finding services.