Manage supported/recommended PHP versions in a central location

[flixos90]

Currently the PHP versions WordPress supports and recommends are hardcoded across several locations. With the Servehappy API already in place, we can easily centralize this, so that in the future we will only have to adjust these versions in one place. These versions can then be fetched from any locations across wordpress.org.

[flixos90]

4009.diff​ is a take at this.

• The Servehappy API now also returns the oldest PHP version that WordPress core still works with (currently 5.2.4).
• The Requirements and Download pages on wordpress.org take these numbers into account via the API.

See #4004 as a related ticket: The Update PHP page also includes these version numbers, it would already be taken care of there.

Also related, but not directly tied to each other is #4006 (for the near future).

[Otto42]

I don't understand this patch. Why would we make a loopback query to api.wordpress.org to get that data? This seems to be a wasteful approach.

[dd32]

Yeah, let's not do that.

We can instead make the raw data which serve-happy uses available elsewhere on dotorg through either a global function or constants, similar to WP_CORE_LATEST_RELEASE or wporg_get_versions() which you may have run across in some templates.

It'll probably mean removing the constants from https://meta.trac.wordpress.org/browser/sites/trunk/api.wordpress.org/public_html/core/serve-happy/1.0/config.php and instead replacing it with something like the following:

function wporg_get_recommended_php_version() {
	return [
		// The latest branch of PHP which WordPress.org recommends.
		'recommended' => '7.2',

		// The lowest branch of PHP which is actively supported.
		'supported'   => '7.0',

		// The lowest branch of PHP which is receiving security updates.
		'secure'      => '5.6',

		// The lowest branch of PHP which is still considered acceptable in WordPress.
		'acceptable'  => '5.3'
	];
}

[flixos90]

@dd32 Agreed. Is there some file with global data in the meta repository, or where could we create something like that? I think it would be great to define similar constants, but in a central location so that they can be accessed from different sites that are part of the repository.

[dd32]

Replying to flixos90:

@dd32 Agreed. Is there some file with global data in the meta repository, or where could we create something like that?

Unfortunately not.. Right now due to the mixed nature of the SVNs we're not really able to mix our main config store of all the version constants/etc with the public meta repository.

A middle ground may be to define it in an a mu-plugin, which would be made available everywhere needed, and easily pulled into the stand-alone API endpoints, that would also work around having to redefine it into the meta-environment
https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/mu-plugins/pub

[flixos90]

4009.2.diff​ introduces a must-use plugin that exposes these PHP version constants globally. Since the Servehappy API itself does not run on WordPress, it includes the file manually (not sure that is correct, but I have no idea about it).

@dd32 Can you review? If this isn't what you meant, please clarify, and I'm happy to provide another update.

[dd32]

In 8065:

API: Serve Happy: Move the Serve-Happy config constants out from the API and into a global mu-plugin to allow it to be used in other WordPress.org pages.

Props flixos90, dd32.
See #4009.

[dd32]

In 8066:

WordPress.org Main Theme: Use the Serve Happy constants for the PHP requirements to reduce the number of locations it needs updating in.

Props flixos90, dd32.
Fixes #4009.

[ocean90]

In 8158:

WordPress.org Main Theme: Use the Serve Happy constant for the recommenced PHP version in the letter.

See #4009.
Fixes #4114.

[SergeyBiryukov]

In 9434:

WordPress.org Main Theme: Requirements: Use the Serve Happy constant for the recommenced PHP version in meta descriptions.

Follow-up to [7990], [8158].

Props Spongsta.
Fixes #4991. See #4114, #4009.