Skip to main content

PHP Migration

As originally presented at the Drupal Community Meeting (7th April 2022), PHP 7.x is reaching end-of-life November 28 2022. This is the default approach by the PHP Group, actively supporting each release branch for two years following its initial stable release. During these two years, bugs and security issues are fixed and released accordingly. Once the two year period of active support is finished, each branch is then supported for an additional year for critical security issues only.

Currently supported PHP versions and their end-of-life dates (via https://php.net/).

Currently supported PHP versions and their end-of-life dates (via https://php.net/).

Currently, CERN uses PHP version 7.4, whose support ends November 28 2022.

In preparation of Drupal 10, CERN is moving directly to PHP 8.1.

Who does this impact?

In short:

  1. If your website relies on the CERN Drupal Distribution, no action is necessary.

  2. If your website utilises custom modules, you must take action.

If you are unsure as to whether or not your website uses custom modules, please confirm that:

  • You, or anyone on your team, has not created and configured a dedicated composer project; and
  • the custom modules list has an empty modules.

If you do have custom modules installed, you must ensure that the version you have installed is compatible with Drupal >= 9.4.0 and PHP 8.1. This can be verified by viewing the dedicated release page of each individual module. If, for instance, you are using a local installation of better_exposed_filters (see https://www.drupal.org/project/better_exposed_filters), version 8.x-5.2 works with Drupal ^8.8 || ^9, whereas version 6.0.1 works with Drupal ^9 || ^10. In this instance, you must ensure that you are using version 6.0.1. In general, it always a good idea to use the newest available release of a module that is not an alpha or beta release. Please refer to this guide in order to update your modules.

You may also refer to the below flowchart:

Flowchart denoting who is affected by the PHP migration

Flowchart denoting who is affected by the PHP migration.

I am impacted, what now?

It is first and foremost important to accentuate how custom modules are your responsibility. This means anything not in the CERN Drupal Distribution, i.e. custom (self-authored or modified) and community contributed modules. In all cases, you must

  1. Ensure compatibility with PHP 8.1;
  2. ensure compatibility with Drupal 9.4 / 10.x;

as well as

  1. ensure continued maintenance.

We recommend the following resources to ensure compatibility:

If you have any questions, please refer to the Drupal Community Forum.

Migration Process

The following steps outline the migration process to PHP 8.1.

  1. A clone of your website, e.g. my-website.web.cern.ch, will automatically be created in a PHP 8.1 environment as my-website-php8-generated-preview.webtest.cern.ch. Once the clone is up and running, you will receive a notification (e-mail via the Notifications Service) with a direct link to your newly created clone. The steps outlined on this page will be included in the e-mail, too.
  2. You must then validate that your website looks and functions as expected. This means browsing through some of your pages and verifying that it behaves as it should. If you are utilising different content types, and perhaps have customised pages, we recommend checking at least one of each type. Please remember to check both as an authenticated and anonymous user to ensure permissions remain unchanged.

The next step depends on whether you use custom modules or not.

Sites without custom modules

  1. If your website does not utilise any custom modules, it is expected to function correctly. However, kindly note that a small selection of modules previously included in the CERN Drupal Distribution has been discontinued due to no compatible releases being available. You may find a complete list here. If you relied on any of these modules, you website should still work, but some functionality will no longer be available. If something unexpected does not work, or it someone looks or behaves weirdly, please submit a SNOW ticket.

If everything looks correct, no further action is needed.

On 14 November, your production website will be upgraded automatically. The preview site will automatically be deleted.

Sites with custom modules

  1. If your website utilises custom modules, you must ensure compatibility.

Website preview is compatible

If your preview website is already compatible, no other action is necessary. This scenario likely means you are already actively upgrading your custom modules: We appreciate you doing this, and encourage you to continue this practice to ensure your website remains secure and compatible moving forward. By 14 November, your production website will be upgraded, and approximately two weeks later, the clone will automatically be deleted.

Website preview is not compatible

If your preview website is not fully compatible, or lacks some functionality, you most likely need to update one or more custom modules. You must then work on the clone to ensure compatibility as your production website does not yet run in a PHP 8.1 environment. Kindly refer to this guide to learn how to update modules. If you face any problems doing this, please post on the Drupal Community Forum, or submit a ticket.

You will have until 14 November to fix your website, before the automated upgrade to PHP 8.1 happens. If this time is not sufficient you can request for an extension until 28 November. This action must be done before 14 November.

danger

New content added to your production website is not automatically mapped to the clone website after its creation!

Upgrading modified website previews to production
  1. If you did not add new content to the primary during the migration period, but you made changes to the clone/preview to ensure compatibility with PHP 8.1, We recommend the following approach: Before the deadline to upgrade ends (either the default 14 November or 28 November, if you requested an extension), go to the Webservices Portal and promote the clone to primary by clicking the Set as primary env toggle.

Note: We consider the migration period to begin on 17 October, date in which the clones were created, until the deadline of the upgrade.

Promote preview to production

  1. You added new content to the primary, and also made changes to the preview instance

In this instance, there is no automated flow. We recommend you either:

  1. a) copy the new content to the preview instance before upgrading as mentioned above in Upgrading custom previews to production, point 1., or
  2. b) create a new clone via Add environment, choose release v9.4-2 and copy the changes you performed to your clone/preview to the new environment instance just created. Once that is done promote it to primary as mentioned above in Upgrading custom previews to production, point 1..

When the deadline is reached, if your production site is already running the v9.4-2, you do not need to perform any other action. Approximately two weeks after, we will cleanup all migration related resources, and upgrade all other environments as well.