System requirements

Overview

An overview of system requirements for Drupal 10 and Drupal 11.

Web server requirements

Drupal works on Apache, Nginx, and other web servers.

Drupal works on any web server with a version of PHP that meets the PHP version requirements.

Many hosting providers offer PHP version options. The default PHP version might be less than the version required for Drupal, so check the current version in your host’s control panel, and change it to the latest supported version (if needed).

PHP has occasional security releases, watch for them at php.net and upgrade/patch your servers as needed, or work with a hosting provider that handles PHP updates.

If you want to create and develop Drupal sites on your computer, you can install everything needed locally.

Security note: Some security features are only provided for Apache and (to a lesser extent) IIS through the use of .htaccess and web.config files. You are responsible for recreating these features when not using Apache.

File and folder permissions

Drupal and PHP should have read and write access to the /sites/default/files directory. This area is used to store cached files (compressed CSS and JavaScript) and any file uploads through the Drupal interface

Security note: Universal permission like 0777 is not secure and usage of such is discouraged.

Apache

Apache is the most commonly used web server for Drupal. Drupal requires Apache 2.4.7 or greater hosted on UNIX/Linux, OS X, or Windows.

The majority of Drupal development and deployment is done on Apache, so there is more community experience and testing performed on Apache than on other web servers.

The Apache 'mod_rewrite' extension is required. It is used for clean URLs.

The Apache Virtualhost configuration must contain the directive AllowOverride All to allow Drupal's .htaccess file to be used.

If the Apache server has Options +MultiViews enabled by default, then the Apache Virtualhost configuration should also contain Options -MultiViews (or have -MultiViews added to the existing Options directive).

On some systems, particularly OpenSuse distributions you may have to add SymLink settings to the .htaccess file. Depending on security settings, you may need to add either +FollowSymLinks or +SymLinksIfOwnerMatch (especially on shared hosts). If this is required, the on-screen error messages may be unhelpful, but the error logs identify the problem correctly in both cases. If you edit the .htaccess file remember that you have to re-edit after updates which overwrite the file!

See also Relocated web root on shared hosting with symlink, if you are using shared hosting, and cannot change the DocumentRoot via the GUI, or otherwise.

Nginx

Nginx is a commonly used web server that focuses on high concurrency, performance and low memory usage.

Drupal requires Nginx 1.1 or greater hosted on UNIX/Linux, OS X, or Windows. Nginx is a popular alternative to Apache, so there is also significant community experience and testing performed on Nginx.

Microsoft IIS

Microsoft IIS is a web server and a set of feature extension modules for use with Microsoft Windows.

Drupal core will work with IIS 5, IIS 6, IIS 7, IIS 8 or IIS 10 if PHP is configured correctly.

To achieve clean URLs you may need to use a third-party product. For IIS 7 or 8 you can use the Microsoft URL Rewrite Module or a third-party solution.

On IIS 7 Drupal requires Windows 2008 Server SP2 or later for fastCGI support.

As of Drupal 11.0.0 Drupal does not support the use of Microsoft IIS.

PHP Built-in Web Server (Development Only)

PHP Built-in Web Server is included as a CLI SAPI tool in all recent versions of PHP and was designed to aid in application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server, therefore, it should not be used as a production server for public use.

This web server can be started using the Drupal quick-start command.

Internet Protocol (IP) Version(s)

Drupal Core does not restrict access based on IP format. Specifically, requests using IPv4 and IPv6 are compliant with Drupal Core. Certain add-on (contributed or custom) modules may have their own restrictions or requirements related to the IP version. However, Drupal Core itself has no such restrictions.

Database server requirements

Database server to run Drupal.

MySQL, MariaDB, or Percona Server (Recommended)

Drupal 10

• MariaDB 10.3.7+
• MySQL/Percona 5.7.8+

Drupal 11

• MariaDB 10.6+
• MySQL/Percona 8.0+

Required configuration

• InnoDB as the primary storage engine
• The PDO database extension

Note: Drupal itself will generally operate with a default MariaDB/MySQL configuration. A more complex site will likely require configuration changes for the database. You can solve these common configuration issues using this documentation.

PostgreSQL

Drupal 10

Drupal 10 requires PostgreSQL 12 or higher with the pg_trgm extension enabled.

Drupal 11

Drupal 11 requires PostgreSQL 16 or higher with the pg_trgm extension enabled.

See remaining issues with PostgreSQL support in Drupal here.

Note: Some contributed modules include MySQL-specific code. Issue reports can be filed in the contributed modules' queues when this occurs.

Enabling pg_trgm

To enable, run CREATE EXTENSION pg_trgm; as a user with appropriate permissions (CREATE EXTENSION docs). This must be run while you are connected to the database for your Drupal site. Running it on another database on the same server will not work. Connect to your database by running \connect DBNAME in psql.

SQLite

Drupal 10

Drupal 10 requires SQLite 3.26 or higher with the json1 extension enabled.

Drupal 11

Drupal 11 requires SQLite 3.45 or higher.

Note: Some contributed modules include MySQL-specific code. Issue reports can be filed in the contributed modules' queues when this occurs.

Other database servers

Microsoft SQL Server and MongoDB are supported by contributed modules.

Memory requirements

Detailed information about random-access memory (RAM) requirements for Drupal.

Drupal's memory requirements depend on which programs and tools are in use. PHP uses some memory, and if you also use Solr, Memcache, or similar programs, it all adds up. You probably need to run Composer commands occasionally, which require a certain amount of free memory. You can check the memory usage with a Unix command line tool such as htop or with the WebProfiler module.

• Minimum RAM: 1 GB

Composer

Running a Composer command such as composer update used to require a lot of free memory (RAM). Luckily, this was improved in Composer 2, and much less memory is now required.

For a Drupal 10 installation with around 30 contrib modules, Composer may not use more than a maximum of 200 MB of RAM to successfully run composer update, but it is recommended to have at least 1 GB of free memory available, to be on the safe side.

To get an estimate of the memory required, you can run a benchmark test.

Note: Run first without COMPOSER_DISABLE_NETWORK=1 to allow local caches to get populated, and then with:

$ COMPOSER_DISABLE_NETWORK=1 composer update --dry-run --profile
[12.1MiB/0.07s] Loading composer repositories with package information
[...]
[23.3MiB/5.01s] No installed packages - skipping audit.
[23.2MiB/5.01s] Memory usage: 23.2MiB (peak: 194.72MiB), time: 5.01s

In the example above with 30 contrib modules in composer.json, Composer's memory usage maxed out at ~200 MB.

PHP

PHP memory requirements can vary significantly depending on the modules in use on your site. The minimum required memory size is 64 MB, typically 128 MB or 256 MB are found in production systems. For more, see PHP memory requirements.

Solr, Memcache, etc.

Memcache and Solr can require a lot of memory, depending on the amount of data. Check usage with htop or the WebProfiler module.

Composer requirements

Composer requirements for installing and updating Drupal

Installation and updates of Drupal sites should be performed using the Composer dependency manager.

Drupal 10 requires Composer 2.3.6 or higher, since this will be the requirement for using Automatic Updates. Composer can be updated by running composer self-update.

Older versions of Composer may continue to install or update Drupal successfully but bug reports will only be accepted for supported versions.

PHP requirements

Detailed information regarding the PHP requirements for Drupal.

Some individual modules may have specific requirements for PHP extensions and configurations beyond those listed below, so, please check the module's documentation as well.

See Drupal 7 PHP requirements for information about Drupal 7.

PHP versions supported

1. Drupal 10 requires at least PHP 8.1. PHP 8.1.6 is recommended.

What does it mean for a PHP version to be supported? What does it mean for the PHP installation to be "too old"?

Drupal minor versions receive a predefined window of security coverage (typically 12 months) as long as a supported PHP version is used. 

We prefer to allow sites to receive security updates even if they are using a version of PHP that is no longer supported. However, Drupal's upstream dependencies may drop support for older PHP versions before the Drupal major version reaches its end of life. If this happens, the Drupal site will no longer be able to install security updates for that dependency, so we can no longer guarantee its security coverage.

Site owners will receive warnings on their site status report that their PHP installation is "too old" if the site's PHP version is old enough that a dependency is likely to drop support for it.

If a dependency does drop support for a PHP version that was initially supported by the Drupal major version, an unscheduled minor release may be created to require the new PHP and dependency versions. For example, Drupal 9.0.0 supported PHP 7.3, so if a Drupal 9 dependency drops support for PHP 7.3 before Drupal 9's end-of-life date in November 2023, we may create a new minor version outside the normal schedule that increases the PHP version requirement to 7.4 and the dependency's version requirement to the supported version.

What does it mean for a version of PHP to be "recommended"?

Drupal will work on all supported PHP versions. Recommended PHP versions are the best choice for building a Drupal site because they will remain supported longer.

PHP extensions needed

Extensions used by Drupal core are defined in Core's composer.json file - see for example the file for Drupal 11.x. Look at the "require" section and the keys starting with "ext-".

Note: Adding a PHP extension to your system, at least on Linux (and Mac), means finding and installing the relevant PHP package using your package manager. Typically the package name for the Foo extension is named "php-foo" or "php83-foo", but this isn't always the case. Some extensions are part of the core PHP package and hence are enabled by default. 

Database extensions

The PHP Data Objects (PDO) extension must be activated for Drupal 9 and higher to install and run correctly. The PECL version of PDO is not compatible with Drupal 9 and cannot be used. In addition, a PHP extension for connecting to your chosen database must be installed and enabled.

Drupal's currently supported database connectors are SQLite, mysql (the original MySQL extension), mysqli (an improved connector for newer MySQL installations), and pgsql (for PostgreSQL).

XML extension

PHP XML extension (for Blog API, Drupal, and Ping modules). This extension is enabled by default in a standard PHP installation; the Windows version of PHP has built-in support for this extension. Enabling the XML extension also enables PHP DOM. DOM is now a system requirement.

Image library

An image library for PHP such as the GD library is a required extension in Drupal 9 and higher, and is needed for image manipulation (resizing user pictures, image and image cache modules). ImageMagick is also supported for basic image manipulations in Drupal core but there is much less support from contributed modules.

OpenSSL

The PHP OpenSSL extension is recommended to allow Drupal to make outgoing requests using HTTPS and is required when using the Update Manager. Read PHP OpenSSL requirements for more information.

JSON

Drupal 9 and higher require PHP compiled with JSON. JSON support is normally compiled as part of PHP core, but in case you're getting errors like PHP Fatal error: Call to undefined function Drupal\\Component\\Serialization\\json_encode() in ... core/lib/Drupal/Component/Serialization/Json.php try adding the JSON extension.

cURL

The PHP cURL extension is required for automated testing in Drupal 9 and higher, as well as Aggregator and some contributed modules. Many Linux distributions and development stacks will have it enabled by default, but if your system doesn't either enable it in php.ini (typically on Windows) or install it using your package manager (typically on Linux).

Mbstring

The PHP mbstring extension provides multibyte specific string functions used for Drupal installation in other languages except for English and also multilingual sites in Drupal. It helps deal with multibyte encodings in PHP and also handles Unicode based encoding like UTF-8 or UCS-2.

PHP configuration settings

Memory requirements

PHP memory requirements can vary significantly depending on the modules in use on your site. The minimum required memory size is 64MB.

Warning messages will be shown if the PHP configuration does not meet these requirements. However, while these values may be sufficient for a default Drupal installation, a production site with a number of commonly used modules enabled could require more memory. Typically 128 MB or 256 MB are found in production systems. Some installations may require much more, especially with media-rich implementations. If you are using a hosting service it is important to verify that your host can provide sufficient memory for the set of modules you are deploying or may deploy in the future. (See the Increase PHP memory limit page in the Troubleshooting FAQ for additional information on modifying the PHP memory limit.)

.htaccess settings

Some of the memory settings are contained in the default .htaccess file that ships with Drupal, so you shouldn't need to set them explicitly. Note, however, that setting PHP configuration options from .htaccess only works under the following conditions:

• With Apache (or a compatible webserver)
• If the .htaccess file is actually read, i.e. AllowOverride All in the main Apache configuration (usually httpd.conf) is enabled
• If PHP is installed as an Apache module

In some shared hosting environments, access to these settings is restricted. If you cannot make these changes yourself, please ask your hosting provider to adjust them for you.

Other interfaces

See the PHP manual for how to change configuration settings for other interfaces to PHP.

Xdebug

If using Xdebug:

Setting: xdebug.show_exception_trace = 0
Reason: Could cause Drupal's installer to crash.

Using Xdebug with Drupal 9:

Setting: xdebug.collect_params = ?
Reason: Setting xdebug.collect_params too high will prevent Drupal 9 from installing and working properly.

Setting: xdebug.max_nesting_level = 256
Reason: Using the default max_nesting_level of 100 (in xdebug versions < 2.3) causes some pages to crash.

Note: From version 3.0 an onwards, xdebug.collect_params Has been removed. Arguments are now always visible with variable contents and argument name

PHP from different sources

Drupal is designed to work with PHP as distributed on PHP.net. Every effort is made to make it work with PHP versions from other sources but this is only done on a best effort basis. In particular, Suhosin is known to break certain features; and some operating systems move core components into other packages.

PHP requirements details

See the phpinfo() page on Drupal.org to learn how to use Phpinfo to get the details of your system. For example, Phpinfo will tell you if you have a database already installed and what versions of PHP, MySQL, etc. your system is running. Phpinfo will also tell you what PHP variables are set as well as many other helpful things.

It is often possible to update to a newer version of PHP that ships with your Linux distribution. Please read the documentation for your Linux distribution.

Some notable points

• Be aware of the limitations of 32-bit PHP.
• The Drupal 9 Update manager can install/update modules and themes via SSH if the required libraries have been installed on the server. (On Debian the package is named "libssh2-php".)

• If the native opcache is enabled, settings opcache.save_comments must be enabled (set to 1 which is the default), otherwise Annotations will not be saved/loaded. 

   

PHP OpenSSL requirements

OpenSSL PHP configuration needed for Drupal's Update Manager to function properly

Starting with version 9.1.0, Drupal core's Update Manager uses HTTPS to fetch information about available updates. This means that the PHP a Drupal site is using must have OpenSSL installed and properly configured. If PHP does not support OpenSSL, a site with the Update Manager enabled will see a "Failed to fetch available update data" error message at their available updates report.

Image

If you see this error, there are a few steps you can take to get things working:

1. Confirm the site can connect to the Internet
2. Confirm OpenSSL is enabled
3. Confirm the site's certificate files are properly installed and configured
4. If needed, configure Update Manager to fallback to HTTP

Confirm the site can connect to the Internet

Before worrying about OpenSSL and HTTPS, the first step is to make sure the site can reach the public Internet at all. Consider:

• Is this a test site running on a local server or inside a container that doesn't have an Internet connection at all?
• Is the site behind a network proxy server? If so, is the network and the site properly configured to use that proxy?
• ...

The site must be able to access the public Internet at all, or none of the rest of these instructions will help.

Confirm OpenSSL is enabled

First, check if the site's PHP has OpenSSL enabled at all:

Administration > Reports > Status

Click on the "more information" link under PHP version (/admin/reports/status/php)

There should be a section called "openssl" and you should see something like:

OpenSSL support: enabled

If not, you'll have to consult the PHP openssl extension documentation on how to enable this extension in your php.ini configuration file. Basically, you'll need to uncomment or add a line like this: extension=php_openssl.so and probably restart your web server daemon (e.g. Apache). The details will vary depending on your hosting environment. If you're unsure, check with your system administrator or hosting provider.

Confirm the site's certificate files are properly installed and configured

You might see an error in your site's log files like one of these:

• SSL Certificate Problem: Unable to get local issuer certificate
• SSL Certificate Problem: Verify that the CA cert is OK.

If so, it means your site does not have the correct Certificate Authority (CA) certificates installed or that PHP cannot find the correct certificates. You can install a set of trusted certificates provided by cURL itself:

1. Download cacert.pem
2. Move the cacert.pem file to the affected computer, e.g.:
   • /etc/pki/tls/cacert.pem
   • C:\php\extras\ssl\cacert.pem

3. Edit the php.ini file and change the curl.cainfo parameter, e.g:

   • curl.cainfo = "/etc/pki/tls/cacert.pem"
   • curl.cainfo = "C:\php\extras\ssl\cacert.pem"

   Note that on some PHP configurations, you might need to set openssl.cafile, not curl.cainfo, to point to the cacert.pem file you downloaded.

4. Potentially restart your webserver (e.g., Apache) to get the php.ini changes to take effect.

For more information, see:

• https://docs.bolt.cm/3.7/howto/curl-ca-certificates
• https://curl.haxx.se/docs/sslcerts.html
• https://curl.haxx.se/libcurl/c/libcurl-errors.html
• https://stackoverflow.com/questions/13467648/configuring-curl-for-ssl

If needed, configure Update Manager to fallback to HTTP

If you do not have access to change your site's PHP configuration, or all else fails, you can configure Drupal's Update Manager to fallback to using HTTP. This is not recommended, and less secure (potentially exposing you to a "man-in-the-middle" attack where a malicious site claims to be updates.drupal.org and gives you false information). However, not having any indication that your site is missing available security updates for Drupal core and contributed modules and themes would probably be worse. So if you need to, you can set the following in your settings.php file:

$settings['update_fetch_with_http_fallback'] = TRUE;

In this case, the Update Manager will still try HTTPS first, but if that fails, instead of giving up and printing the error message, it will try again using HTTP and hopefully fetch available update data.

If you've got this setting defined, and you try to "Check manually" (using the link on your site's Available Updates report) and you still see error messages, make sure your website is connected to the internet, that your network settings are correct, etc. Debugging every possible situation where a site cannot make outbound requests is outside the scope of this documentation. Good luck!

Browser requirements

Websites built using just Drupal core are compatible with, and fully functional in, all modern browsers that support CSS and JavaScript.

As a rule of thumb, websites built using just Drupal core (i.e. with no additional, contributed modules) are compatible with, and fully functional in, all modern browsers that support CSS and JavaScript (with minor variations in appearance). Drupal only guarantees support for the list of supported browsers.

Supported browsers

• The latest release of each of the latest two supported major versions of:
  • Desktop browsers:
    • Google Chrome
    • Firefox
    • Safari
    • Microsoft Edge
    • Opera
  • Mobile browsers:
    • Safari for iOS
• The latest supported release of the latest major version of:
  • Desktop browsers:
    • Firefox ESR
  • Mobile browsers:
    • Chrome for Android
    • Chrome for iOS
    • Opera Mini (except for 'extreme data savings' mode)
    • Samsung Internet

Policy

• Drupal accepts bug reports for supported browsers.
• Contributors manually test significant changes in multiple browsers to watch for regressions, but this is somewhat based on the contributors available and the particular issue. We do not yet have full automated browser testing for our supported browsers.
• By default, Drupal core does not accept bug fixes to unsupported browsers. Committers and the security team will assess the risk on a case-by-case basis and make exceptions to this rule when needed.
• Drupal can start using any given browser feature once all the supported browsers have either native support or a polyfill. In each major release, polyfills that are no longer needed (because all supported browsers have added the feature natively) will be removed.

Contributed modules

Some contributed modules and themes may not be compatible with all browsers. If you find a problem with browser compatibility in a contributed module or theme, or some functionality in a contributed module that does not work at all without JavaScript enabled, please submit an issue to report it to the module or theme maintainer.

Setting the MySQL transaction isolation level

The recommended transaction isolation level for Drupal sites is 'READ-COMMITTED'.

The preferred way to change the transaction isolation level

Global Value

The first one is to run a database query that sets the transaction isolation level for every session on the database. The query is:

SET GLOBAL transaction_isolation='READ-COMMITTED';

or

SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

To make the setting persist after a reboot, you can use

SET PERSIST transaction_isolation = 'READ-COMMITTED';

and/or add the setting to the config file, as described below.

These queries can only be run by a database user with superuser privileges.  Also note, mysql will respond with "Query OK, 0 rows affected" and if you check the transaction isolation level with the command "SELECT @@transaction_isolation;" you will see the previous setting.  If this happens to you, logout and log back into mysql and run the above SELECT command again and now you should see the READ-COMMITTED setting.  Hope this will save you from a wild-goose chase.

You can check the value has been set by running the MySQL command below.

Config File

Alternatively, you can set this in your MySQL config file in the [mysqld] section. (may require root or administrator access)

transaction_isolation="READ-COMMITTED"

You can check the value has been set by running the MySQL command below.

Command Line

To set the server's default isolation level for all connections, use the --transaction-isolation option on the command line (e.g.: mysqld --transaction-isolation=READ-COMMITTED)

AWS RDS Parameters

If you are using Amazon Web Services (AWS) Relational Database Services (RDS) to set the server's default isolation level for all connections:

Create a new parameter group:

1. go to Amazon RDS Console
2. choose Parameter Groups in the left-nav
3. Click the Create Parameter Group button
4. Give your new group a Group Name (eg: 'custom.mysql8' and a Description)
5. Save your parameter group
6. On the Parameter Groups listing page, click on your new parameter group
7. In the Parameters search box, enter "tx_isolation" to find the proper parameter
8. Click the checkbox next to "tx_isolation"
9. Click the Edit Parameters button
10. In the Values dropdown, select READ-COMMITTED
11. Click Save button

Apply your parameter group to your database:

1. Go to the Amazon RDS->Databases page
2. Click on your database name to go to the database details page
3. Click the Modify button
4. Under the Additional Configurations section, edit the DB parameter group setting and select your newly created parameter group
5. At the bottom of the page click the Continue button
6. Select the Apply Immediately option (unless you need to wait until a maintenance window)
7. Click the Modify DB instance button
8. It will return you to the Database listing page and show a status of Modifying until the change has been saved.  Use the Refresh button to update the status until the status shows as Available.
9. To apply the new parameters to the running database, select your database's radio button and under Actions select Reboot.
10. After the reboot is complete, check your Drupal Reports->Status Page to confirm that the database is no longer showing you the warning.

You can check the value has been set by running the MySQL command below.

Other methods to change the transaction isolation level

The second method is to update the settings.php file. The default location for the file is sites/default/settings.php. The file is created during the installation of your Drupal site.

At the end of the settings.php file is usually the database connection array found. Something like:

$databases['default']['default'] = array(
  'database' => 'databasename',
  'username' => 'sqlusername',
  'password' => 'sqlpassword',
  'host' => 'localhost',
  'driver' => 'mysql',
  'prefix' => '',
  'port' => '3306',
);

To change the database transaction isolation level to "READ COMMITTED" add the following to the database connection array:

  'init_commands' => [
    'isolation_level' => 'SET SESSION transaction_isolation=\'READ-COMMITTED\'',
  ],

The database connection array with the added setting will be something like this:

$databases['default']['default'] = array(
  'database' => 'databasename',
  'username' => 'sqlusername',
  'password' => 'sqlpassword',
  'host' => 'localhost',
  'driver' => 'mysql',
  'prefix' => '',
  'port' => '3306',
  'init_commands' => [
    'isolation_level' => 'SET SESSION transaction_isolation=\'READ-COMMITTED\'',
  ],
);

Adding the setting of the transaction isolation level to the init commands in the settings.php file has the disadvantage that on every page request the transaction isolation level is set. That is an extra database call for every page request!

To confirm that the setting has been made correctly you can run the mysql command:

show variables WHERE Variable_name LIKE "%_isolation";

You should see the following output:

mysql> show variables WHERE Variable_name LIKE "%isolation";
+-----------------------+----------------+
| Variable_name         | Value          |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+
1 row in set (0.00 sec)

For more information about isolation levels see:

• MariaDB: Isolation Levels and Locks and tx_isolation system variable.
• MySQL: Transaction Isolation Levels documentation and transaction_isolation system variable. 

Important notice regarding binary log format

Changing the transaction isolation level may also change the binary log format of your server because only row-based binary logging is supported with the READ COMMITTED isolation level. Even if you use READ COMMITTED with binlog_format=MIXED, the server automatically uses row-based logging. Source: https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html

For instance, in MariaDB version >10.2.3 the default binary log format is mixed logging. So changing the isolation level here will also change the binary log format in row logging. Source: https://mariadb.com/kb/en/binary-log-formats/

Please be aware that changing the binary log format changes the behaviour of your database server. For instance, row logging requires more storage space than mixed logging. Source: https://mariadb.com/kb/en/binary-log-formats/

Limitations of 32-bit PHP

32-bit PHP can only support a limited range of dates.

If you run Drupal on a system where PHP is compiled or limited to using 32-bit integers, you will only be able to enter dates between 1901 and 2038 (specifically from 20:45:52 UTC on 13 December 1901 to 03:14:07 UTC on 19 January 2038). This is commonly known as the 2038 bug.

The usual symptom is seeing a date displayed or recorded as 1970-01-01 instead of an intended value outside the above range. This will affect all PHP applications. In Drupal specifically, date-based field types are impacted, i.e. Date only and Date and Time, including the "Select list" widget. You can choose years outside the 1900 to 2038 range, but because PHP itself can't handle them, they will be stored/displayed as 1970-01-01 without warning.

Affected products

• Official Windows builds of PHP 5.x/7.x for x86 and PHP 5.x for x64 .
• Any web stack package (XAMPP, Wamp, etc.) with PHP compiled for 32-bit and/or running on a 32-bit system.
• Acquia Dev Desktop 2 prior to the 14 June 2018 release (it now uses 64-bit PHP and MySQL).

Note: It's how PHP itself is compiled that counts: if you have a 32-bit version of PHP running in a 64-bit operating system you'll still experience the problem.

Testing

To test if your PHP is affected, you can run this command (as one line):

php -r "echo (date('y',strtotime('2039-01-01')) == 39 ? 'OK' : 'Y2K38 limitation') . PHP_EOL;"

An unaffected PHP instance prints OK while an affected PHP instance prints Y2K38 limitation.

Relocated web root on shared hosting with symlink

How to configure shared web hosting to work with drupal/recommended-project.

The recommended method of running a Drupal site is with a "relocated document root":

[...] the files "index.php" and the "core" directory and so on are placed inside a subfolder named "web" rather than being placed next to "composer.json" and the "vendor" directory at the project root.

From Securing file permissions and ownership.

This can be a challenge on shared hosting, if you are not allowed to set the DocumentRoot, either via configuration or the GUI.

A workaround is placing the Drupal files in a folder outside the public_html folder, and instead serve the /web-folder via public_html using a symlink. This method requires command line access, via SSH or the browser.

Assuming that when you log in on your shared hosting, this is your home folder:

/var/www/example.org

Assuming this is the path to the public_html folder:

/var/www/example.org/public_html

1. Place your Drupal folder here:
   /var/www/example.org/drupal10
2. Rename the public_html folder:
   mv public_html public_html_OLD
3. Create a symlink from public_html to web:
   ln -s /var/www/example.org/drupal10/web /var/www/example.org/public_html

Now, the files in /web will be served via the symlinked public_html-folder. Run Composer and Drush commands from the drupal10 folder, not public_html.