Skip to content
Snippets Groups Projects
Commit 40d1b7b9 authored by Carina Antunes's avatar Carina Antunes
Browse files

Merge branch 'update-migration-section' into 'master' 

Update migration section

See merge request drupal/paas/drupal-documentation!35
parents b0293a44 84255908
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
docs/docs/7-Migration/2-deprecated-modules.md → docs/docs/7-Migration/1-deprecated-modules.md
+ 11
− 5
View file @ 40d1b7b9
......@@ -4,12 +4,20 @@ slug: /deprecated-modules
# Deprecated Modules
As part of the migration to PHP 8.1, we are also upgrading the modules included in the CERN Drupal Distribution.
As part of all upgrades and migrations, we upgrade the modules included in the CERN Drupal Distribution.
As outlined in [Introduction to Modules](/modules), we always require community-contributed (i.e. third-party) modules to have a proven record and otherwise be actively supported by multiple developers.
Accordingly, in the event that a module stops receiving support, fails to address potential security vulnerabilities, or eventually becomes incompatible with newer versions of Drupal, we may be forced to remove it from the distribution.
Moving to PHP 8.1 means that modules included in the CERN Drupal Distribution **must** support PHP 8.1.
The following modules **are not compatible with PHP 8.1 and have been removed from the CERN Drupal Distribution**:
## Ludwig
Ludwig was officially created in the middle of 2017 by Drupal. It was the standard for module management at the time.
Since Drupal 8 is released, the preferred tool for Drupal site management is Composer [ref](https://www.drupal.org/docs/contributed-modules/ludwig/why-ludwig#s-external-php-libraries-management). Composer takes care of all the required libraries nicely and automatically.
> Can I use both Composer and Ludwig in my project?
No. We use composer to manage all the PHP libraries. All available [documentation](https://www.drupal.org/docs/contributed-modules/ludwig/why-ludwig#s-can-i-use-both-composer-and-ludwig-in-my-project) reports we can only support one or the other. They are not compatible, so in short, you shouldn't use it (or need it)!
## PHP 8.1
The following modules **were not compatible with PHP 8.1 and were removed from the CERN Drupal Distribution**:
| module | link | version |
|--------|------|---------|
......@@ -24,7 +32,5 @@ The following modules **are not compatible with PHP 8.1 and have been removed fr
|contribute|[drupal/contribute](https://drupal.org/project/contribute)|~1.x-dev@dev|
|google_analytics|[drupal/google_analytics](https://www.drupal.org/project/google_analytics)|~3.1|
Of these, `panelizer` is widely used across existing CERN websites.
The Web Team is actively monitoring the situation in the event that a compatible release is pushed.
If your website strictly relies on any of these modules, it is possible to assume ownership of the module(s) and apply the necessary changes to ensure continued compatibility.
If you are unable to replace the module(s) with an alternative, and cannot assume responsibility for ensuring continued compatibility, please get in touch.
docs/docs/7-Migration/1-introduction.md deleted 100644 → 0
+ 0
− 137
View file @ b0293a44
---
slug: /php-migration
---
# 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/).](/assets/img/7-migration/php_timeline.png)
<p className="image-caption">Currently supported PHP versions and their end-of-life dates (via <a href="https://php.net/">https://php.net/</a>).</p>
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](/development/custom-modules#updating-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](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](/development/custom-modules#updating-modules) in order to update your modules.
You may also refer to the below flowchart:
![Flowchart denoting who is affected by the PHP migration](/assets/img/7-migration/who_is_affected.png)
<p className="image-caption">Flowchart denoting who is affected by the PHP migration.</p>
## 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
3. ensure continued maintenance.
We recommend the following resources to ensure compatibility:
- Migrating from PHP 7.x to 8.0: https://www.php.net/manual/en/migration80.php
- Migrating from PHP 8.0 to 8.1: https://www.php.net/manual/en/migration81.php
- Running compatibility scans for PHP 8: https://haydenjames.io/php-8-compatibility-check-and-performance-tips/
- Anything Drupal should use https://www.drupal.org/project/upgrade_status
If you have any questions, please refer to the [Drupal Community Forum](https://drupal-community.web.cern.ch/).
## 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
3. 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](insert-link).
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](https://cern.service-now.com/service-portal?id=sc_cat_item&name=incident&se=Drupal-Service&short_description=Report%20an%20issue%20with%20site%20preview%20for%20the%20PHP%208.1%20upgrade).
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
3. 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](https://drupal.docs.cern.ch/development/custom-modules#updating-modules) to learn how to update modules.
If you face any problems doing this, please post on the [Drupal Community Forum](https://drupal-community.web.cern.ch/c/php-8-upgrade/22), 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](https://cern.service-now.com/service-portal?id=sc_cat_item&name=request&se=Drupal-Service&short_description=%20Extend%20site%20preview%20and%20delay%20PHP%208.1%20upgrade%20until%2028%20November&comments=Please%20give%20the%20site%20name:%20).
**This action must be done before 14 November.**
:::warning
**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](/assets/img/7-migration/promote_production.png)
2. **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:
2. 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.
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment