PHP

Supported PHP versions Currently, the available versions of PHP on our servers are: PHP 8.4 PHP 8.3 PHP 8.2 PHP 8.1 (default) PHP 8.0 PHP 7.4 PHP 7.3 (obsolete) PHP 7.2 (obsolete) PHP 7.1 (obsolete) PHP 5.6 (obsolete) PHP 5.3 (obsolete) Supported PHP handlers The following PHP handlers are supported on our servers: CGICGI (Common Gateway Interface) allows a web server to work with external programs such as PHP scripts. Compared to FPM, CGI is slower and consumes more server resources, but some scripts may need to run as CGI for compatibility reasons. FPM with OPcache (recommended)FPM (FastCGI Process Manager) uses the FastCGI protocol that allows CGI programs to work with a web server. FPM maintains workers that handle PHP requests to reduce the overhead related to the communication between the web server and CGI programs, resulting in faster PHP execution. It is paired with OPcache - a caching system that keeps pre-compiled script bytecode in the server memory which further improves PHP performance. On our servers, there are two FPM with OPcache handler setups available:• FPM with max OPcache memory - This handler has the recommended maximum amount of memory for storing cached data by OPcache, which makes it the perfect solution for heavy websites that get a lot of traffic/visitors. For plans with dedicated memory (e.g. WebApps-enabled plans), the maximum memory limit can be modified with the opcache.memory_consumption setting in the website's PHP configuration file. More details on the process of changing PHP settings are available in our Changing PHP settings article.• FPM with default OPcache memory - This handler has a default memory allocation for OPcache. It still offers great PHP performance and should be sufficient for most websites. Default PHP version and handler By default, newly-opened hosting accounts will be configured to use the PHP handler that offers the best performance and the latest PHP version that is currently supported on our servers and is widely supported by popular applications. A hosting account will use the PHP version and PHP handler it was initially opened with, unless you change them manually. So, if your account was opened when PHP 7.3 was the default PHP version and CGI was the default PHP handler, it will stay with these settings until you change them. The default PHP version and handler for newly-created subdomains are handled in the same manner - they will be configured automatically to use the latest PHP version currently supported on our servers and the fastest available PHP handler. The FPM with max OPcache memory PHP handler can be enabled only for a set number of websites depending on the hosting plan. If the account reaches this limit, the new default PHP handler for the account will become FPM with default OPcache memory. If you would like to use the FPM with max OPcache memory PHP handler for more websites, you should contact your hosting provider to check the available upgrade options. Changing the PHP version/handler You can change the default PHP version and handler for each subdomain in your account through the Control Panel -> PHP Settings section by selecting the desired PHP version and/or handler next to the subdomains where you want to change the PHP version and/or handler. To save your changes, click on the Save Changes button. If you wish to adjust specific settings for the PHP interpreter, please refer to the PHP Settings article from our online documentation. PHP version for the command line PHP binary By default, the command line PHP binary (php.cli) will use the latest PHP version available on our servers when your account was opened. In some rare cases, due to legacy settings, an account may be configured with an older PHP version for php.cli. You can view or change the default PHP version for php.cli for your account via the PHP CLI version subsection of the hosting Control Panel -> PHP Settings section. A list showing the paths to the command line PHP binary files for all PHP versions supported for your account are available in the hosting Control Panel -> System Information section. You can use these PHP binary files to execute scripts using a specific (non-default PHP version for your account) for php.cli via cron jobs or the command line. For example, if you wish to execute the ~/www/www/directory/file.php script using PHP 7.2 via the command line or a cron job, you should use the following command: /usr/local/bin/php72.cli ~/www/www/directory/file.php Changing the PHP version for a certain folder only The information in this section applies only to subdomains using the CGI PHP handler. More information on the precedence of PHP configuration files is available in our PHP configuration files and priority article. Note: If you wish to change the PHP version for a subdomain altogether, please refer to the Changing the PHP version/handler section from this article. You can "hard code" certain folders to use a particular version of PHP for subdomains using CGI as PHP handler by adding a directive to an .htaccess file (you can create that file if it doesn't exist) in that folder. The table listed below shows the exact directives you need to use for each of the PHP versions supported on our servers: PHP version .htaccess directive PHP 8.4   AddHandler application/x-httpd-php84 .php PHP 8.3   AddHandler application/x-httpd-php83 .php PHP 8.2   AddHandler application/x-httpd-php82 .php PHP 8.1   AddHandler application/x-httpd-php81 .php PHP 8.0   AddHandler application/x-httpd-php80 .php PHP 7.4   AddHandler application/x-httpd-php74 .php PHP 7.3   AddHandler application/x-httpd-php73 .php PHP 7.2   AddHandler application/x-httpd-php72 .php PHP 7.1   AddHandler application/x-httpd-php71 .php PHP 5.6   AddHandler application/x-httpd-php56 .php PHP 5.3   AddHandler application/x-httpd-php53 .php   Obsolete PHP versions PHP 5.3, PHP 5.6, PHP 7.1, PHP 7.2, and PHP 7.3 are in end-of-life status, and there are no security releases for them. That is why we may stop supporting these versions on our servers at any time. We strongly advise any user running an obsolete PHP version to update to a newer PHP version as soon as possible. Please note that the PHP 5.3 and PHP 5.6 branches on our servers may not come with all standard PHP extensions due to server software compatibility issues. PHP 5.3 is available only for the CGI PHP handler. It is not available for the FPM with OPcache PHP handlers due to performance and security concerns. For additional information on switching from PHP 5.3 to a newer version, you can check the Common problems when switching from PHP 5.3 to PHP 5.6 article.

PHP versions over 5.3 introduced some major changes and backward incompatibilities. That's why making older software compatible with PHP 5.4+ can be troublesome sometimes. You can read more about the available PHP versions on our servers in the PHP Version article. Generally, if you are using a popular third-party software such as WordPress, Joomla, Drupal, or similar, what you need to do is to make sure that your software and all its modules/themes/plugins are updated to their latest versions. The developers of such software usually do that is needed to make their software compatible with newer PHP versions. If you are using custom software, you must make sure that it is compatible with PHP versions over 5.4. Below you can find some problems that we have found as most common when switching between PHP 5.3 to 5.6. register_globals and magic_quotes not supported The register_globals and magic_quotes settings are no longer supported. Attempts to enable any of the two, either in a php.ini file or through an ini_set() function, will raise an error. If your software relies on register_globals or magic_quotes, it should be rewritten. Date/Timezone issues As of PHP 5.4, the server timezone is no longer automatically guessed in PHP, and it should be explicitly set. This should be done either in a php.ini file, or in the code of the software. PHP encoders/decoders If your software requires a PHP encoder/decoder to run (such as Zend Guard Loader or ionCube), you would need to obtain a version of your software for PHP 5.6. Please contact your software vendor about that. Also, you must make sure that you have the correct decoder binary set in the PHP settings for your account. More information about Zend Guard Loader and ionCube can be found in the Using Zend Guard Loader and Using ionCube articles. Error reporting level E_STRICT is now a part of E_ALL. If the error_reporting of your PHP settings is set to display E_ALL errors, this means that E_STRICT errors will now be displayed as well. You can suppress this by adjusting the error_reporting settings in your php.ini file to exclude E_STRICT. The developers of PHP have listed the backward incompatibilities between PHP 5.3 and PHP 5.4 here: http://php.net/manual/en/migration54.incompatible.php Lists of the functions and features deprecated in PHP 5.5 and PHP 5.6 can be found at: http://php.net/manual/en/migration55.incompatible.phphttp://php.net/manual/en/migration56.incompatible.php

To set your .html and .htm files to be parsed as PHP, you can use a .htaccess file. If this file does not exist in the directory where you want to apply the change, you should create it first. You can easily create and edit the file via the File Manager section of the Control Panel.Add this line of code to the file: AddHandler application/x-httpd-php .html .htm If you want to use a different PHP version than the default one for the server, you should refer to the PHP Version article for more details. Here is the format that you should use to utilize PHP 5.6 for example: AddHandler application/x-httpd-php56 .php

The most common reason for а "500 server error" message, output by a PHP script, are incorrect file permissions. You need to make sure that the PHP script itself and every other file or directory on the account does not have world-writable permissions (666, 777).On our servers, scripts are run with the username of their owner, and not with the user of the web server ("apache"). Thus, if a script has to write to a file/directory, world-writable permissions are not needed. A file/directory with world-writable permissions is considered insecure, and cannot be used/executed.

You can manage the PHP settings on your account using php.ini and .user.ini files. In general, we would recommend that you .user.ini files as they work recursively unlike php.ini files; however, you can manage some PHP settings only via php.ini files (e.g. ionCube and ImageMagick extensions). More details about PHP configuration files, their main differences, and the precedence they take are available in our PHP configuration files and priority article. You can create/edit php.ini and .user.ini files in your account manually via the hosting Control Panel -> File Manager interface. Changing the PHP settings for a subdomain To change the PHP settings for a subdomain, access the hosting Control Panel -> PHP Settings section, and click on the Manage button next to the specific subdomain. You will be redirected to the PHP settings management screen where you can use the available interface to manage PHP extensions and directives. You can click on the Edit button next to the subdomain's php.ini file from the Info section to edit the php.ini file as plain text via the hosting Control Panel -> File Manager interface. If you prefer editing php.ini files in plain text mode, you can navigate to the subdomain whose PHP settings you wish to modify using the hosting Control Panel -> File Manager section. Note: If you do not use the hosting Control Panel -> PHP Settings section to change the PHP settings for a subdomain that uses FPM with OPcache as PHP handler, you will need to reload the FPM master process manually by going to the hosting Control Panel -> PHP Settings section, click on the Manage button next to the specific domain, and click on the Reload FPM master process button. Changing the PHP settings for a folder If you wish to change the PHP settings for a specific folder only, you can create a php.ini or .user.ini file inside that folder via the hosting Control Panel -> File Manager section. We would recommend that you also add the directives specified in the Default content of php.ini files on our servers section from our PHP configuration files and priority article for compatibility reasons. Changing the PHP settings for a specific file You can change the PHP settings for a specific PHP file using the ini_set() PHP function. This function allows you to use custom PHP settings for the specific file instead of using the current PHP configuration from php.ini and .user.ini files. Changing the PHP settings in the global php.ini for your account To change the PHP settings in the global php.ini for your hosting account, navigate to the hosting Control Panel -> PHP Settings section, and use the Edit button under the Manage global php.ini file section. If there is no global php.ini for your hosting account, the Edit button will be replaced with a Create button allowing you to create the global php.ini file for your account.

You can use local .user.ini and php.ini configuration files to change various PHP interpreter settings. These files can be easily created via the Control Panel -> File Manager interface. By default, when a new subdomain is created through the hosting Control Panel -> Subdomains section, a php.ini file will be created automatically in its document root. The php.ini file for your main domain (www subdomain) will be created when your account is activated. For some accounts these default php.ini files may not exist due to legacy settings. PHP configuration files Main differences between .user.ini and php.ini files In .user.ini files you can only use directives with the PHP_INI_PERDIR and PHP_INI_USER modes (PHP_INI modes list), while php.ini files can be used for changing all directives supported on our servers. .user.ini files work recursively (for all subfolders). php.ini files do not work recursively (their settings will be valid only for the directory where the php.ini file is located). The values for directives not defined in .user.ini files will be taken from the php.ini file with the highest precedence according to the Priority of PHP configuration files table. This is not so with php.ini files, where the values of all directives that are not defined in the specific php.ini file will be reset to the values of a default PHP installation. For directories using the FPM with OPcache PHP handler, any changes made to .user.ini files will take effect immediately, while you may need to reload the FPM master process for changes to php.ini files to take effect. You can learn more about the FPM master process reloading in our PHP Settings article. Global php.ini file The global php.ini file for your account is located in your home directory (/home/USERNAME/php.ini). The settings in this php.ini file are applied globally for all your PHP scripts, unless they are overridden by a local php.ini or .user.ini file. Default content of php.ini files on our servers Any automatically generated php.ini files on our servers will have the following content: post_max_size = 60Mmemory_limit = 3000Mupload_max_filesize = 60Mmax_execution_time = 120expose_php = Offsession.save_path = /tmperror_reporting = E_ALL & ~E_STRICT & ~E_NOTICE & ~E_DEPRECATEDdate.timezone = ${TZ} Note: If you plan to use local php.ini files, we recommend that you set these directives in them for compatibility reasons. Of course, you can modify the values for these directives to your liking. For example, if you do not want your scripts to use the timezone of the physical location of the server, you can change the default ${TZ} value of the date.timezone directive. Restore global or main subdomain php.ini file settings to default You can restore the global php.ini file for your account or the main php.ini files of subdomains to default by using the Restore to default button from the hosting Control Panel -> PHP Settings section. PHP configuration files priority PHP interpreter (CGI and FPM handlers) The precedence order (from highest to lowest) of configuration files of the PHP interpreter is listed below: PHP configuration file\PHP handler   CGI handler support   FPM handler support .user.ini file in the directory of the executed file   ✓   ✓ php.ini file in the directory of the executed file   ✓   × main php.ini file of the subdomain   ×   ✓ global php.ini for the account   ✓   ✓ server php.ini   ✓   ✓ default PHP configuration settings   ✓   ✓ Note: The values for directives not defined in .user.ini files will be taken from the php.ini file with the highest precedence from the table listed above. Unlike .user.ini files, the values for directives not defined in a php.ini file will be reset to the values of a default PHP installation. PHP-CLI For the command line PHP interpreter (php.cli), the configuration files have the following precedence: php-cli.ini file in the directory of the executed file php.ini file in the directory of the executed file global php.ini for the account server php.ini default PHP configuration settings

You can enable PHP error logging for your scripts by changing the PHP settings for your account. Details on how to do this can be found in our Changing PHP settings article.To enable PHP error logging, you should add the following directives to a PHP configuration file (php.ini) in your hosting account: error_reporting = E_ALL | E_STRICT log_errors = Ondisplay_errors = Offerror_log = /home/USERNAME/private/php-errors.log Replace USERNAME with your actual hosting account username (you can find your username listed in the upper left corner of your Control Panel). The above settings are recommended, and you can alter them according to your needs. The error_reporting directive defines which errors are to be recorded. The E_ALL constant specifies that all errors and warnings should be logged, and the E_STRICT constant instructs the PHP interpreter to suggest code changes that will make sure the PHP code is compatible with future versions of PHP. You can check all error_reporting predefined constants here:https://php.net/manual/en/errorfunc.constants.php The log_errors = On line enables recording of errors in the log file on the server. If this runtime option is set to Off, no errors will be recorded in the log file. display_errors = Off disables error displaying in the browser. If you set this option to On, then errors will be displayed in the browser when the PHP script is executed. The line error_log = /home/USERNAME/private/php-errors.log will set the PHP interpreter to record its errors in the specified file in the Private directory on your account. Remember to replace USERNAME with the actual username of your hosting account. If you want, you can choose another folder or a different file to store the logs in.

By default, PHP scripts use the timezone of the server, which is set according to the location of the data center. For more details, check our Server Timezone article. To change the timezone setting for your PHP scripts, you need to adjust the value of the date.timezone PHP directive. To do this for a domain/subdomain, you should access the hosting Control Panel -> PHP settings section and follow these steps: Click on the Manage button next to the domain/subdomain. Select your preferred timezone from drop-down menu next to the date.timezone directive under the Directives section. If you cannot see the date.timezone directive, click on the Show additional directives button and all the PHP directives manageable through the interface will be displayed. Click on the Save changes button. You can also change the date.timezone value by manually adding the following line to a PHP configuration file: date.timezone = "custom_timezone" Make sure that you replace custom_timezone with the timezone that is appropriate for your location. The list of valid time zones in the current version of PHP is available at https://php.net/timezones. More details on how to change the PHP settings in your account are available in our Changing PHP settings article. Changing the timezone for PHP 5.3 PHP 5.3 is obsolete, and we encourage all customers to stop using it. If you wish to change the timezone for scripts running on PHP 5.3, besides changing the date.timezone setting in your PHP configuration file, you need to add the following line to an .htaccess file: SetEnv TZ The .htaccess file should be located in the folder that contains your PHP scripts or in an upper level folder as .htaccess files work recursively. Changing the timezone for MySQL sessions Changing the timezone for PHP scripts does not apply to the MySQL server. If you use the internal MySQL date functions, they will return the system time, so any date conversions should be done in your scripts. Please refer our Setting MySQL session time zone article for instructions on doing so.

You can review and manage the active PHP configuration of your subdomains on the PHP Settings page of the Control Panel, along with some diagnostic information that is specific to the PHP-FPM handler. When you click on the "Manage" button next to one of your subdomains, a page with the PHP settings that pertain to that particular subdomain will be shown. If FPM with OPcache is chosen as the PHP handler, you can click on the "Status" button to display an additional list of status information. This information is relevant to the performance and load of your website. Here is a list of the diagnostic values that you can review, along with the meaning of each one: Accepted conn Number of requests that have been accepted and processed. Active processes Number of active PHP-FPM processes that accept requests. Idle processes Number of processes that are idle. Listen queue This value shows the number of requests that are waiting to be processed. Listen queue len This is the size of the queue of pending connections. Max active processes This is the greatest number of active processes that has been reached since the PHP-FPM master process was started. Max children reached Shows the number of times the PHP-FPM process limit has been hit when FPM tried to start more processes. Max listen queue Shows the largest number of requests in the queue since the master PHP-FPM process was started. Pool This is the name of the FPM pool. Usually, this will be set to the name of the subdomain. Process manager Type of process management strategy chosen for your website. On our servers, this is set to "ondemand". Slow requests Number of requests that have taken more time to be processed than a configured timeout. Start since Shows how many seconds the master PHP-FPM process has been running for. Start time Shows when the master PHP-FPM process was started. Total processes Number of all PHP-FPM processes that are currently running. The most important metrics you should pay attention to are the "Max children reached" and "Listen queue" ones. Max children reached This value will be incremented whenever the PHP-FPM master process reaches the maximum number of processes it can start in order to handle requests. If this value is not zero, this means that there have been more requests to your website that can be comfortably handled by your hosting service, and requests have started piling up on a queue for processing. This may make your site slower than usual, and it may also be an indication of other problems. Listen queue This value shows the number of requests pending processing. If there are requests in the queue, this may mean that your website is overloaded or there is some other problem that causes it to be slower than usual. Details about running processes You can also review the status of your running FPM processes. This can be done from the command line using the php-fpm-status tool. This way, you can check what requests your website is currently processing. To do that, you have to log in over SSH and run the following command: php-fpm-status www.example.com You should replace "www.example.com" with the name of your website. Here is what the output of the command looks like: Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: no-cache, no-store, must-revalidate, max-age=0 Content-Type: text/plain pool: www.example.com process manager: ondemand start time: 25/Apr/2021:01:37:49 +0800 start since: 1695502 accepted conn: 66673 listen queue: 0 max listen queue: 0 listen queue len: 0 idle processes: 1 active processes: 2 total processes: 3 max active processes: 20 max children reached: 2 slow requests: 0 ************************ pid: 22441 state: Running start time: 17/May/2021:04:14:52 -0400 start since: 871 requests: 127 request duration: 685 request method: GET request URI: /fpm-status-ShOC0gaIVoh0eiH1eEGNahVEK?full content length: 0 user: - script: - last request cpu: 0.00 last request memory: 0 ************************ pid: 22442 state: Idle start time: 17/May/2021:04:14:52 -0400 start since: 871 requests: 127 request duration: 64918 request method: POST request URI: /index.php content length: 36 user: - script: /home/example/www/www/index.php last request cpu: 2.62 last request memory: 2097152 The first part of the output shows the same information as the Status section described above. After that, there is information about each active FPM worker process. The details are as follows: pid This is the system ID of the process. state State the process is in. There are likely to be one or more "Idle" processes that are waiting for requests. start time When the process was started. start since Shows how many seconds the worker process has been running for. requests The number of requests this worker process has handled. request duration How long it took (microseconds) to handle the last processed request. request method The HTTP method of the last processed request. request URI The URI of the request. Note that depending on the configuration of your website, this may not match the exact URI sent to the web server. content length How many bytes long the request is. user N/A on our servers. script File system path to the running PHP script. last request cpu How much CPU time (seconds) it took the server to process the request. last request memory The amount of memory (in bytes) the server used when processing the request. The most important metrics here are the "request duration", "last request cpu", and "last request memory" ones. Request duration This shows how long the PHP FPM worker took to process the last request it handled. This time is in microseconds, so 5,000,000 here would mean five seconds. Last request CPU This shows how many CPU seconds it took the server to process the last request. This metric is important because it can show you if a script is overloading your account. Lower values are better for both performance and load. Last request memory This shows the amount of memory allocated to the PHP FPM worker process during the last request. While the limit on our servers is quite high, you should have in mind that running out of memory may cause your website to become unresponsive. If this value is often high, it can show potential problems with resource usage in your PHP applications.