Increase the PHP minimum supported version to 7.0

[hellofromtonya]

Today, WordPress announced it is dropping PHP 5.6 support, raising the minimum supported version to PHP 7.0 for WordPress 6.3.0.

https://make.wordpress.org/core/2023/07/05/dropping-support-for-php-5/

Changeset 56141 dropped the PHP 5.6 CI jobs.

After the changeset was committed, Gutenberg's CI started failing on each of the PHP 5.6 jobs (e.g. PR #52343) with the following error message:

Your server is running PHP version 5.6.39 but WordPress 6.3-beta3-56142 requires at least 7.0.0.

What is your proposed solution?

To keep parity with WordPress Core, this ticket proposes for Gutenberg to:

• Raise the minimum support PHP version.
• Drop the PHP 5.6 CI jobs.

Tasks

1. Drop PHP 5.6 CI jobs running on WordPress trunk.
2. Get consensus on when to raise the minimum required PHP version.
3. Change the plugin header Requires PHP: to 7.0.

[hellofromtonya]

The PHP 5.6 CI jobs against WordPress Core's trunk are now removed from the repo via commit d9022ff. ✅

The PHP 5.6 CI that runs against a previous WordPress version remains ✅

[hellofromtonya]

Step 2: Get consensus on when (timing)

The next step is to discuss and get consensus on the timing of the plugin dropping PHP 5.6.

Likely this bump needs to wait.

Why wait?

1. The plugin supports the 2 latest WordPress versions, as @azaozz notes

Yea, (afaik) Gutenberg supports the two latest WP releases, i.e. currently 6.1 and 6.2 while 6.3 is in the works. Bumping the minimum PHP version for the plugin would probably need to happen later.

2. WordPress 6.3 ships August 8th.

Once WP 6.3 ships, then the plugin will support 6.2.2 and 6.3.

Thus using the 2 latest WordPress versions, the timing for "when" for dropping PHP 5.6 support would be when WordPress 6.4 ships.

[Soean]

Supporting WordPress 6.2.2 does not mean we have to support PHP 5.6 in Gutenberg until WordPress 6.4 is released. Gutenberg is a plugin for developing and testing new features for WordPress. We can increase the PHP minimum independently of the WordPress minimum.

I don't see any major reason to continue supporting PHP 5.6 in Gutenberg at this time. Therefore, I would be in favor of an increase as soon as possible. This way we can already write better code and prepare features and improvements for WordPress 6.4.

[hellofromtonya]

We can increase the PHP minimum independently of the WordPress minimum.

I don't see any major reason to continue supporting PHP 5.6 in Gutenberg at this time.

What about this scenario?

A user is on WP 6.2.2 and PHP 5.6, but wants to upgrade to the new Gutenberg plugin version to get fixes.

Hey @Soean how do you foresee supporting these users if Gutenberg changes its minimum PHP version to 7.0? How does Gutenberg continue to support WP 6.2.2 after this change?

Is there a scenario where supporting past WP version could mean a new version of Gutenberg includes fixes for these users?

If yes, then any new code running PHP 7.0 syntax would cause a fatal error for them. Ways to prevent that include:

• New code is guarded with a PHP version check.
• Upgrade to the new Gutenberg version is prevented with a PHP version check (thus blocking users from the above scenario from upgrading).

[hellofromtonya]

I'm also wondering ...

Does supporting the last 2 WordPress released versions mean new Gutenberg code should also be capable to run on each of the versions?

[azaozz]

Generally all plugins are free to choose the minimum required PHP version. @hellofromtonya is right that if the required PHP version in Gutenberg is bumped to 7.0 now it may leave some WP 6.2 users "behind". On the other hand these users will have to get their sites on a PHP 7.0+ anyway if they want to update to WP 6.3 (and also thinking that this is comparably a very small number of users).

So perhaps it'd be better to bump the minimum required PHP version in Gutenberg now, slightly ahead of the curve.

[azaozz]

Is there a scenario where supporting past WP version could mean a new version of Gutenberg includes fixes for these users?

Assuming this is about security fixes, etc. they would be backported to the older plugin version(s), or not? Seems faster to just patch one or two spots and push a new version quickly instead of trying to release a new version that may be in the middle of development.

Does supporting the last 2 WordPress released versions mean new Gutenberg code should also be capable to run on each of the versions?

That's a good question. Imho it would be simpler/better if Gutenberg had parity with the latest WP release. I.e. bump version requirements as soon as they are bumped in core. That could serve as an early warning that the particular site is running on an old PHP version and will need upgrading. Also would make it simpler to sync code back and forth, etc.

[costdev]

I agree that a bump as soon as possible is preferable to keep things in sync with the rest of the project. Ideally at the same time as WordPress 6.3's release.

[anton-vlasenko]

If yes, then any new code running PHP 7.0 syntax would cause a fatal error for them. Ways to prevent that include:

• New code is guarded with a PHP version check.

I believe it's too much of a hassle to guard the new code as it will have to be moved to separate files; otherwise, PHP 5.6 will throw syntax errors.

With that in mind, I'm thinking it's probably better to just move to PHP 7 and drop support for PHP 5.6 (if the community decides to go that way).

Change the plugin header Requires PHP: to 7.0.

It's not quite clear why the composer.json file for Gutenberg doesn't specify the minimum required PHP version in the same way as Core does (https://github.com/WordPress/wordpress-develop/blob/trunk/composer.json#L13).

This is something that needs to be addressed to ensure parity between Core and Gutenberg (not necessarily in the scope of this issue).

[hellofromtonya]

if the required PHP version in Gutenberg is bumped to 7.0 now it may leave some WP 6.2 users "behind"

Exactly. This is my thinking too.

The "when to bump" decision centers on this question:

👉 Is there consensus that Gutenberg plugin users on PHP 5.6 that wish to remain on WordPress 6.2.2 will be "left behind", i.e. unable to upgrade to the newest Gutenberg versions until they upgrade their PHP version?

[hellofromtonya]

What's my opinion?

I'm a strong advocate for keeping parity between Core and Gutenberg to further ease merging code between them. And I too would like to increase the PHP version level to match Core.

I suspect the number of users being "left behind" is very small. I also suspect that users testing new features and providing feedback are on newer WordPress versions and PHP 7+.

Thus, I suspect the risk is low, likely very low.

I think the PHP version can and should be bumped when or before WordPress 6.3.0 ships.

Why did I raise the concerns?
In my previous comments above, I intentionally posed questions and shared a narrative to invite thinking and discussions. This situation will happen again. Having these kinds of open discussions and thinking about user and project impacts is healthy, while having them now can set a path forward and precedence for future action, e.g. when Core again bumps a PHP version.

[noisysocks]

👉 Is there consensus that Gutenberg plugin users on PHP 5.6 that wish to remain on WordPress 6.2.2 will be "left behind", i.e. unable to upgrade to the newest Gutenberg versions until they upgrade their PHP version?

This sounds fine to me.

To me Gutenberg is a "cutting edge" plugin used for iterating on features soon to be added to Core and not primarily a way to have older WordPress sites run the latest WordPress features.

[hellofromtonya]

#52982 bumps the plugin's PHP version. It's ready for review.

[hellofromtonya]

Thank you everyone for contributing to the discussions about when to bump. I think there's enough consensus to move forward.

The bump was merged 🎉

[hellofromtonya]

What PHP 7.0 changes can be implemented in Gutenberg?
A Make/Core Proposal is coming (likely next week) for all PHP code in the .org project (Core and Gutenberg). It'll provide those details and welcome feedback.