Note for Themes about Core PHP Compatibility Changes in WordPress 5.2

With the release of WordPress 5.2 the minimum recommended PHP version changes from minimum of PHP 5.2 to a minimum of PHP 5.6.

Themes hosted in the WordPress.org directory can choose to fully support any version of PHP they want – but you also must ensure it does not cause any fatal errors when it is run on any of the PHP versions that WordPress itself supports.

Themes should include their own method of handling PHP version compatibility and providing a graceful fallback when it’s run on unsupported versions. The most common way to do this is by preventing activation of your theme on versions of PHP which you do not support and notifying the user about why.

You can do that using the after_switch_theme hook, the phpversion() function or PHP_VERSION constant and version_compare(). Here is some example code that prevents theme activation on a server that’s PHP version is below 5.6.

<?php

/**
 * Set a constant that holds the theme's minimum supported PHP version.
 */
define( 'THEMESLUG_MIN_PHP_VERSION', '5.6' );

/**
 * Immediately after theme switch is fired we we want to check php version and
 * revert to previously active theme if version is below our minimum.
 */
add_action( 'after_switch_theme', 'themeslug_test_for_min_php' );

/**
 * Switches back to the previous theme if the minimum PHP version is not met.
 */
function themeslug_test_for_min_php() {

	// Compare versions.
	if ( version_compare( PHP_VERSION, THEMESLUG_MIN_PHP_VERSION, '<' ) ) {
		// Site doesn't meet themes min php requirements, add notice...
		add_action( 'admin_notices', 'themeslug_min_php_not_met_notice' );
		// ... and switch back to previous theme.
		switch_theme( get_option( 'theme_switched' ) );
		return false;

	};
}

/**
 * An error notice that can be displayed if the Minimum PHP version is not met.
 */
function themeslug_min_php_not_met_notice() {
	?>
	<div class="notice notice-error is_dismissable">
		<p>
			<?php esc_html_e( 'You need to update your PHP version to run this theme.', 'themeslug' ); ?> <br />
			<?php
			printf(
				/* translators: 1 is the current PHP version string, 2 is the minmum supported php version string of the theme */
				esc_html__( 'Actual version is: %1$s, required version is: %2$s.', 'themeslug' ),
				PHP_VERSION,
				THEMESLUG_MIN_PHP_VERSION
			); // phpcs: XSS ok.
			?>
		</p>
	</div>
	<?php
}

X-post: Weekly Digest | Week 13

X-comment from +make.wordpress.org/updates: Comment on Weekly Digest | Week 13

Addition of new ‘wp_body_open’ hook.

Starting from WordPress 5.2 a new function is added – wp_body_open() – that is used to trigger a wp_body_open action. The intention of this action is to allow people to add things – like a <script> tag – directly inside the body of a page.

Themes should start adding this hook to their themes as soon as 5.2 releases. The function should be placed inside of the <body> tag immediately after it is opened like so:

<body <?php body_class(); ?>>
<?php wp_body_open(); ?>

See also the notes at the end of this post and what Justin says in his comment for alternative acceptable ways to add the new hook to your theme.

Use of this hook is a plugin-territory item so themes are unlikely to be doing anything other than adding the tag to the template in the correct spot.

Bear in mind that using this hook should be reserved for output of unseen elements like <script> tags or additional metadata. It should not be used to add arbitrary HTML content to a page that could (and probably would) break layouts or lead to unexpected situations.

Backwards Compatibility

UPDATE: see this comment for an alternative: https://make.wordpress.org/themes/2019/03/29/addition-of-new-wp_body_open-hook/#comment-43714

Additionally for backwards compatibility it is recommended you use a shim to add support on old WP versions and prevent your theme throwing a fatal error for undefined function use. The shim that is suggested looks like this:

<?php
if ( ! function_exists( 'wp_body_open' ) ) {
        function wp_body_open() {
                do_action( 'wp_body_open' );
        }
}

It has also been pointed out that you could call the do_action directly where the wp_body_open() function is placed in my first example (and where it is in the core themes). This removes any need for backwards compatibility code. My personal suggestion is to use the function + shim method because that is how core looks to be handling it – however calling do_action directly would also be fine.

X-post: Call for Testing: wp-theme-auditor

X-comment from +make.wordpress.org/accessibility: Comment on Call for Testing: wp-theme-auditor

X-post: Strengths and Challenges: Organization

X-comment from +make.wordpress.org/updates: Comment on Strengths and Challenges: Organization