Eventually drop support for older WordPress versions

[swissspidy]

This originated from #2408 / #2408 (comment).

The AMP plugin currently requires WP 4.9+ and PHP 5.4+ for a few reasons:

• The plugin should be able to run on as many sites as possible.
• 4.9 is the last version without Gutenberg support, so it was assumed that transition period is a bit longer
• There were no drastic benefits in updating the WordPress version requirements
• There were no drastic benefits in updating the PHP version requirements

That means we currently need to support the following scenarios:

• WP 4.9
• WP 4.9 with Gutenberg plugin 4.9
• WP 5.0+ (Gutenberg built-in)
• WP 5.0+ with Gutenberg plugin

Gutenberg will eventually drop support for PHP 5.2 and require WordPress 5.2+ (which requires PHP 5.6):

• Remove support for PHP 5.2 and 5.3 WordPress/gutenberg#15796
• Increase WordPress minimum to 5.2.0 WordPress/gutenberg#15809

That makes everything a bit more complex.

In related news, Yoast SEO is going back to their policy of only supporting WordPress latest and latest - 1: https://yoast.com/supporting-older-versions-of-wordpress/

One possibility to reduce our workload would be to bump requirements for PHP and WordPress as well. Perhaps with the AMP plugin 2.0 we could move to PHP 5.6 and WordPress latest and latest - 1 as well.

[cathibosco]

One possibility to reduce our workload would be to bump requirements for PHP and WordPress as well. Perhaps with the AMP plugin 2.0 we could move to PHP 5.6 and WordPress latest and latest - 1 as well.

Seems reasonable from the perspective agencies and individual users. If fact it’s an opportunity to educate users once again the importance of maintenance. Legacy is important but AMPStories was never offered too too far back.

[westonruter]

Should we go ahead and bump to 5.6 as the minimum required version of PHP now?

Thoughts on when/whether we should do the bump to 7.0? /cc @schlessera

[swissspidy]

I think a bump to 5.6 in anticipation of version 2.0 makes sense. Would be great to outline a short plan / todo list for that. Some items off the top of my head:

• Use newer version(s) of PHPUnit
• Use phpdbg for code coverage reports
• Update build environment on Travis (Use Xenial build environment on Travis #3044)
• Unblock issues like Update dependency sirbrillig/phpcs-variable-analysis to v2.8.0 #3252 and potentially others
• Remove legacy code in anticipation of Extract post-processor logic into CMS-agnostic PHP library #2315

7.0 could then happen around the time when core bumps its requirement too?

[westonruter]

Perhaps the PHP 7.0 bump would be best to coincide with the plugin's 2.0, since refactoring the AMP plugin codebase should ideally take advantage of new language features. Isn't WordPress core tentatively planning to bump to PHP 7.0 later this year?

For the PHP 5.6 bump I think we could just do that in the next release after v1.3, to coincide with WordPress 5.3 (which requires PHP 5.6). I wish there was data on the PHP versions being used on the active installs on the latest version.

[swissspidy]

The 5.6 requirement is already in WordPress 5.2 though. We could probably ask the core/meta team about per-version stats.

[westonruter]

Note: With v1.6 we plan to soft-deprecate support for WordPress 4.9. What this looks like is the admin screen and wizard onboarding flows will not be available for sites running 4.9. Such sites will should instead be shown an upgrade notice. They won't be able to change settings until they upgrade. /cc @johnwatkins0

[johnwatkins0]

@westonruter and anyone else interested. Bringing this back as I start work on #3821. For the recent onboarding wizard/settings screen updates, we were able to bundle our own versions of the core JS libraries because we were on plugin screens that we controlled fully, so WP version wasn't a major concern. We can't do this with #3821 because it is an editor integration and we need to use the JS loaded from core.

For editor integrations, given how quickly the editor is still evolving, I think it makes sense to have a relatively short window of support for older versions. Being tied to, say, WP 5.1 means there would be a ton of useful core Gutenberg components and features that we simply can't use. We'd also be locked into writing React code using dated, pre-hooks patterns.

I suggest we implement a policy of supporting older WP versions for one year after their release. For something like the sidebar, it might be straightforward to keep current plugin behavior in place for older versions while making the newer JS available behind a version comparison.

We happen to be coming up on the one-year anniversary of WP 5.3, which is convenient because that's the first version of WP to include React 16.9 (the one with hooks) in core. I think we could do most of what we want to do with a minimum support requirement of 5.3.

Alternative approaches: I see 5.2 is still in use on 7.5% of WP sites. We'd lose some features by supporting 5.2, but we could still make it work. The same applies back to 5.0 if we want to go back that far. Conversely, we could make the window shorter than a year and commit to supporting the current and previous point release. 5.4 was released in March.

Let me know what you think.

[westonruter]

We currently already disable the editor integration when on an old version of WP and we show an upgrade notice instead. See #5441. Feel free to bump the minimum version from 5.2 to 5.3 or whatever you need.

[westonruter]

I think we've settles on a good path now. We no longer support WP<5.6 or Gutenberg<9.2.0 on the edit post screen, in which case we show an upgrade notice. Otherwise, on screens where we have complete control (settings screen and onboarding wizard), we polyfill all scripts so that the screens will work even in WP 4.9. See #6225.