Updating to PHP 7.4

PHP 7.4 has been out for almost exactly a year (it came out in November 2019). A lot of work has been done in the Drupal community to ensure compatibility. This week I spent some time experimenting with the update. This post is all about the experience.

Impact of the Update

There are a few places the update will have impact:

• locally

  • the VMs I am working with

  • on my host machine

• during continuous integration

• in the cloud

• dependency management

In order to fully update to PHP 7.4, I have to address each of the above issues to ensure that I am, in fact, ready.

Updating my VM

In this example, I am working on a Lando VM. Having said that, the process should be more or less the same for any VM. You basically ned to change the configured version of PHP and then reprovision / rebuild your VM.

Here’s an example!

A note about my example: I was using an Acquia provided image that was built using PHP 7.3. In order to update to PHP 7.4, I removed this image and had to further modify my lando file to replace some of the missing “magic” added by that Acquia image. Hence the reason that this change is more than just a config change in my instance.

Why did we do this update first? A few reasons!

1. You can’t change the dependency management (e.g. composer) without the PHP version being present. It will throw errors. (you can’t run PHP 7.4 when you are running PHP 7.3).

2. It’s MUCH safer to update the VM than it is to update the entire host environment. For me, I have multiple projects and not all of them are on PHP 7.4 yet.

Updating Dependencies

The next step is to update the dependencies. Composer makes this super easy. All you have to do is ensure you have a require for php and update it to be 7.4 like this:

"require": {
  "php": ">=7.4",
}

Then just run composer update php. In my case, I did this in lando (lando composer update php) since my host machine is still running PHP 7..

Stop and Test

This is a great moment to pause on any further updates and actually test your site. A few things to check:

• does the site still install? (you likely have to do re-install after reprovisioning / rebuilding your VM)

• does the site still load / run?

• do your tests (automated / manual) still pass?

• are there any errors, warnings, or other red flags in your logs?

• are there any visual indications of trouble?

Assuming all is well, then we can move on! If not, you’ll want to dig into those problems.

Note I didn’t run into any issues, although I DID have to restart Docker Desktop during a lando rebuild to get past a particular error there. Here’s an example of what that looked like:

Starting drupalgovcon_database_1  ... 

ERROR: for drupalgovcon_database_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=300)

ERROR: for drupalgovcon_appserver_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=300)

ERROR: for database  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=300)

ERROR: for appserver  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=300)

I just used the UI command to restart docker desktop and then re-ran lando rebuild and I was fine.

Updating Continuous Integration

Basically all CI tools have config dashboards and/or files. The syntax is going to be different for all of them, so read the manual. But! The jist is that you need to make sure during a PHP update that all references in your CI tool(s) to a specific PHP version get updated to the right version. For Acquia Pipelines, this change happens in the acquia-pipelines.yml file and looks like:

services:
  - mysql
  - php:
      version: 7.4

Updating Cloud Environments

Assuming all your local testing goes smoothly, and assuming you can update your CI tooling without issue, then it’s time to start updating your cloud environments.

At Acquia, you can do this self-serve on Cloud environments and it looks something like this:

Note that this ^ configuration must be done per environment. So if you have development / staging / production, you will have to do it three times (one for each). I strongly recommend that you do not do this all at once. So, if you have a build that passes and is about to deploy to your development environment, update development ONLY. Test in the cloud on development.

Then, when you are ready to deploy to staging, update staging and deploy. Test again.

Then, and only then, when you are ready to do your production deployment, carefully back up all the things, update php version, and deploy.

Updating Host Machine

As I recently posted in my Setting up a Macbook Pro for development article, homebrew is so critical because of these types of situations. A few simple commands can be run to update my host machine when I’m ready.

$ php -v
PHP 7.3.14 (cli) (built: Jan 24 2020 03:04:31) ( NTS )

$ brew install php@7.4

$ php -v
PHP 7.4.12 (cli) (built: Oct 29 2020 18:37:21) ( NTS )

In Conclusion

Thankfully minor PHP versions are usually “pretty safe.” Jumping from PHP 5.6 to 7 was a much bigger deal (and I anticipate that jumping from whatever 7.x version is current to 8.x will be a bigger deal). But this shouldn’t be “too” bad.

The big things to make sure…

1. Is your hosting provider ready for PHP 7.4. Do they support it?

2. Is there anything in your codebase that isn’t “ready for PHP 7.4.” That could be custom code or contrib code. Hopefully your testing will isolate these issues!

Good luck! Happy updating.

Related Content