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
command line
PHP Command line - system tool, allowing to launch arbitrary code on PHP with function calls.
:
Bitrix\Main\Config\Configuration::wnc();.
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.
Starting from the Main module version 24.100.0, the files .settings.php and .settings_extra.php can be replaced in the folder
/local
Core D7 has the user project files moved from the folder /bitrix to the folder /local. This allows isolating updated files of your project from the product folder.
, and the file dbconn.php — in the folder /local/php_interface.
Parameter description
Below are parameters that can be modified:
Parameters that may be changed are described below:
Cache Section
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.
By default, file cache root folder — /bitrix/cache/. Starting from Main module version 24.100.0, it can be replaced with an arbitrary folder 'root_directory'.
By setting the b_group_max_ttl = 0, administrator restricts caching for this entity. By setting the b_group_min_ttl = 86400, admin expands our TTL for up to 24 hours (if the code contains 3600).
Note: In addition to type there may be additional parameters if a specific caching class requires them.
Note: The memcache settings may also be set in the file /bitrix/.settings_extra.php.
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 key is responsible for displaying an error on a browser page. Errors should be displayed only at the development or debugging stage. Otherwise, there is a potential risk of information disclosure.
handled_errors_types
This key is intended for setting error types to be caught by the system (not ignored).
exception_errors_types
The key sets error types for which the system gives an exception.
ignore_silence
The key cancels action of the error management operator (@).
log
The key sets error logging parameters. If there is no key, there will be no logging. If set as in the example:
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
assertion_throws_exception
Enabling support for command assert.
assertion_error_type
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.
Connections section
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.
Parameter
Value
options
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.
handlersocket
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.
className
Class name, that receives the result of handling the specific database type.
host
host name, where the database is located; can be specified with the port
database
database name
login
database user login
password
database user password
Note: Several databases can be handled within the ORM.
To use the handlersocket connection, the HSPHP - PHP HandlerSocket client library must be installed
Root section
General settings are located in the root section.
Parameter
Value
disable_iconv
Restricts the use of iconv library. Equivalent of the BX_ICONV_DISABLE constant in the old core
This section is specifically required only for hosting partners (for deployment automation). For the rest, its recommended to use the setup via administrative control panel interface.
if true - wait for response (by default), otherwise - return the response immediately
socketTimeout
response timeout period in seconds (by default: 30)
streamTimeout
stream timeout in seconds (by default: 60)
version
version http - 1.0 or 1.1 (by default: 1.0)
proxyHost / proxyPort / proxyUser / proxyPassword
parameter group to setup a proxy
compress
if true, sends Accept-Encoding: gzip
charset
encoding for the object body (is used in the header field for the Content-Type request for POST and PUT)
disableSslVerification
if true, ssl certificates verification will not be performed
Config example:
'http_client_options' =>
array (
'value' =>
array (
'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:
use Bitrix\Main\Config\Configuration;
print_r(Configuration::getValue("http_client_options"));
Your array should be displayed.
services section
This section is intended for registering services. Find more details in the lesson
Service Locator
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.