Tag Archives: site-health

furi3r 2:24 pm on October 6, 2022
Tags: , , , , , , site-health   

New cache Site Health checks in WordPress 6.1

As part of the WordPress 6.1 release, the Performance Team has added two Site Health checks (Persistent Object Cache and Page Cache). These checks were previously tested in the Performance Lab plugin. You can read more about them in the original proposal.

Both checks will run only in a production environment.

Persistent Object Cache

This new check determines whether the site uses a persistent object cache or not and recommends it if it makes sense for the site. It also links to a support resource created for the check.

A few filters have been included aiming for hosting providers to provide more specific steps regarding their environment.

Hosts may use the site_status_persistent_object_cache_url filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to replace the original WordPress guide with their own guide.

/**
 * Filter the Persistent object cache URL.
 */
add_filter( 'site_status_persistent_object_cache_url', function() {
	return 'https://awesomewphosting.com/optimization/persistent-object-cache';
} );

Hosts may use the site_status_persistent_object_cache_notes filter to customize the notes to recommend their preferred object cache solution.

/**
 * Update the persistent object cache notes.
 */
add_filter( 'site_status_persistent_object_cache_notes', function( $notes ) {
	$notes = __( 'The updated notes can go here as text.', 'text-domain' );

	return $notes;
} );

The site_status_persistent_object_cache_thresholds filter allows modifying the thresholds above WordPress considers using a persistent object cache beneficial.

/**
 * Override the whole $thresholds array, or any specific indexes as required.
 */
add_filter( 'site_status_persistent_object_cache_thresholds', function( $thresholds ) {
	$thresholds = array(
		'alloptions_count' => 600,
		'alloptions_bytes' => 200000,
		'comments_count'   => 2000,
		'options_count'    => 2000,
		'posts_count'      => 2000,
		'terms_count'      => 2000,
		'users_count'      => 2000,
	);

	return $thresholds;
} );

Alternatively, site_status_should_suggest_persistent_object_cache is a short-circuit filter that allows using entirely custom logic to determine whether a persistent object cache would make sense for the site.

/**
 * Opt in for suggesting the persistent object cache
 */
add_filter( 'site_status_should_suggest_persistent_object_cache', '__return_true' );

For additional context on this new check, see #56040.

Full Page Cache

This new check determines whether the site is using a full page cache solution and if the response time is acceptable.

It also adds a couple of filters aiming for hosting companies to customize the response threshold and add their own cache headers to be detected.

The site_status_good_response_time_threshold filter allows modifying the current threshold of 600ms. Everything below this will be considered acceptable.

/**
 * Filter the response time threshold
 */
add_filter( 'site_status_good_response_time_threshold', function() {
	return 200;
} );

Additional custom cache headers ( and optionally their verification callbacks) can be added through the site_status_page_cache_supported_cache_headers filter.

/**
 * Filter the page cache supported cache headers
 * $cache_headers contains List of client caching headers and their (optional) verification callbacks.
 */
add_filter( 'site_status_page_cache_supported_cache_headers', function( $cache_headers  ) {
	// Add new header to the existing list.
	$cache_headers['cf-cache-status'] = static function ( $header_value ) {
		return false !== strpos( strtolower( $header_value ), 'hit' );
	};
	return $cache_headers;
});

For additional context on this new check, see #56041.

Thanks to @flixos90, @milana_cap, @spacedmonkey for peer review, and @pushpakpop for the code examples.

#6-1, #core-site-health, #dev-notes, #dev-notes-6-1, #performance, #performance-lab, #site-health

furi3r 1:49 pm on July 13, 2022
Tags: , , , , site-health   

Proposal: Persistent Object Cache and Full Page Cache Site Health Checks

This proposal seeks to integrate two new Site Health checks for Persistent Object Cache and Full Page Cache into WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., targeting the WordPress 6.1 release.

Context

Providing valuable recommendations for site owners is crucial to improving WordPress performance. These two modules are the first in a series of Site Health modules that the performance team is working on. Acknowledging performance problems is the first step to solving them.

The modules were originally proposed and developed by members of the performance team and are available as modules inside the Performance Lab plugin.

Project update

Development of the features has been ongoing in the Performance Lab plugin repository on GitHub, where they have been implemented as: 

The recently released version 1.2.0 of the Performance Lab plugin contains both modules in a state that is ready to merge into core. 

The team is currently migrating the module code into WordPress core patches in 2 TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets:

  • Persistent Object Cache Health Check from performance pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to core (#56040)
  • Port Audit Full Page Cache from performance plugin to core (#56041)

Any reviews and feedback on the core patches would be greatly appreciated.

Customizing the audits

We’ve added a series of filters to make messaging and suggestions customizable. These filters can be used by hosting providers to provide their own personalized suggestions on how to address the Site Health feedback.

Persistent Object Cache filters

Hosts may want to replace the notes to recommend their preferred object caching solution:

apply_filters( 'site_status_persistent_object_cache_notes', $notes, $available_services );

Hosts may want to replace the original link to WordPress documentation with a link to  their own guide:

apply_filters( 'site_status_persistent_object_cache_url',  __('https://wordpress.org/support/article/optimization/#object-caching' ));

Hosts or site owners may want to bypass thresholds and force suggestions, or filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. them to determine whether to suggest the use of a persistent object cache:

apply_filters( 'site_status_suggest_persistent_object_cache', false );
apply_filters(
    'site_status_persistent_object_cache_thresholds',
    array(
        'alloptions_count' => 500,
        'alloptions_bytes' => 100000,
        'comments_count'   => 1000,
        'options_count'    => 1000,
        'posts_count'      => 1000,
        'terms_count'      => 1000,
        'users_count'      => 1000,
    )
);

Full Page Cache filters

Developers can filter the threshold below which a response time is considered good:

apply_filters( 'page_cache_good_response_time_threshold', 600 );

Testing and feedback

You can test the modules in v1.2.0 or later of the Performance Lab plugin. Both modules should be enabled by default, but you can double-check that they are enabled in Settings > Performance:

Once enabled, you can view the test results on the Site Health Status screen at Tools > Site Health > Status.

We encourage you to test these modules (and others) from the Performance Lab Plugin, report any bugs in our GitHub repository, or contribute with fixes and ideas. You can also share any feedback, concerns, or questions to improve these features further in the comments.

Thanks to @mxbclang and @flixos90 for peer review.

#6-1, #core-site-health, #performance, #performance-lab, #site-health

Marius L. J. 7:53 pm on June 22, 2021
Tags: , , site-health   

Extending the Site Health interface in WordPress 5.8

With WordPress 5.8, the feature requestfeature request A feature request should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged. to allow developers to extend what Site Health tabs are available (#47225) has been implemented.

This will allow developers to add their own interfaces to the Site Health area of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., with accompanying tab navigation in the Site Health headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes., or even extend another interface.

Site Health screen showing 4 navigation items

Registering your tab navigation

If you are adding a brand new interface, you will want to introduce a navigation element, so that users may access your interface. This is done using the new site_health_navigation_tabs filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., which is an associated array of tab keys, and their label.

<?php
function wp_example_site_health_navigation_tabs( $tabs ) {
	// translators: Tab heading for Site Health navigation.
	$tabs['example-site-health-tab'] = esc_html_x( 'My New Tab', 'Site Health', 'text-domain' );

	return $tabs;
}
add_filter( 'site_health_navigation_tabs', 'wp_example_site_health_navigation_tabs' );

The above example will add the identifier example-site-health-tab with the label My New Tab to the header navigation i Site Health pages.

It is also possible to re-order what tabs are displayed first using this filter, or even remove tabs. By default core has two tabs, the Status and Info screens. The Status screen is the default, and therefore has no slug.

To not overburden the navigation area, if there are more than 4 items added, only the first three will be displayed directly, with the remaining items being wrapped inside a sub-navigation. This is based on usage testing in the Health Check pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, where 4 items have shown to be enough to cover most use cases, but not so many as to become confusing.

Displaying, or extending, an interface

When a user visits a Site Health tab, other than the default screen, the site_health_tab_content action triggers. This action includes a single argument being the slug, as defined by the tab navigation in the previous filter, to help you identify which page is being requested.

The action fires after the header itself has been loaded, but does not include any wrappers. This gives you as a developer the full width of the screen (not counting the adminadmin (and super admin) menu) to work with.

<?php
function wp_example_site_health_tab_content( $tab ) {
	// Do nothing if this is not our tab.
	if ( 'example-site-health-tab' !== $tab ) {
		return;
	}

	// Include the interface, kept in a separate file just to differentiate code from views.
	include trailingslashit( plugin_dir_path( __FILE__ ) ) . 'views/site-health-tab.php';
}
add_action( 'site_health_tab_content', 'wp_example_site_health_tab' );

The above example loads in a file with your tab content from your plugin, but only if the tab matches the tab key (or slug if you will) which was defined in the previous example.

It is possible to provide output on any tab this way, or on another tab not your own, for example if they interact with each other.

One such example might be to extend the default Info tab, which has the slug debug, and add a button to copy some information specific to only your plugin or theme.

Props @afragen for review and edits.

#5-8, #dev-notes, #site-health

Felix Arntz 8:00 pm on February 22, 2021
Tags: , , , site-health   

Improved HTTPS detection and migration in WordPress 5.7

WordPress 5.7 will feature a number of enhancements which simplify the migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. of a site from HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. to HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information.. As the foundation for providing the user with more accurate recommendations, WordPress will be able to detect whether the current environment already supports HTTPS. If this is the case, it provides a call-to-action button in the HTTPS status section in Site Health, which switches the site from HTTP to HTTPS with a single click.

Overall guidance in the Site Health section has been improved, now allowing hosting providers to supply a custom URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org with instructions or for a one-click update.

Walkthrough of the new feature with a quick demo, including highlighting of the problems this addresses

Detecting state of HTTPS and environment support

WordPress 5.7 introduces a new function wp_is_using_https(), which returns true if both the “Site Address” (home_url()) and “WordPress Address” (site_url()) are using HTTPS as their scheme. Essentially, changing both of these URLs to HTTPS formally indicates that the site is using HTTPS. While there are other ways to enable HTTPS partially in WordPress (e.g. with the FORCE_SSL_ADMIN constant), the new detection mechanism focuses on using HTTPS throughout the entire site, i.e. its frontend and backend.

In addition to providing a single function for checking whether HTTPS is being used, a new detection function wp_is_https_supported() can be called to check whether the environment supports HTTPS correctly. This is now used in Site Health to provide more accurate feedback: If the environment already supports HTTPS, the user can make the switch instantly, without involving their hosting company. Under the hood, the detection function is based on a new internal option https_detection_errors, which is controlled by a twice-daily Cron hook that works as follows:

  • It issues a request to the HTTPS version of the site with the sslverify argument enabled.
    • If the request succeeds, there is already a working SSLSSL Secure Sockets Layer. Provides a secure means of sending data over the internet. Used for authenticated and private actions. certificate in place.
      • In this case, the function also checks whether the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. body from the response actually belongs to the same WordPress site; this is typically the case, but the extra check is needed to cater for sites and environments that e.g. place custom HTML content under the URL. If the HTML body belongs to the same WordPress site, the environment is ready to be switched to HTTPS. Otherwise, switching to HTTPS then cannot reliably be accomplished by WordPress itself because the content is not entirely controlled by it.
    • If the request fails, it attempts the same request again, except that the sslverify argument is now disabled.
      • If that request succeeds, it means there is an SSL certificate, but it cannot be verified, which for example applies to self-signed certificates.
      • If that request fails as well, it means the site is entirely inaccessible over HTTPS.

The wp_is_https_supported() function simply looks at the https_detection_errors option controlled by the Cron hook, and it returns true if there are no errors stored.

One-click migration to HTTPS

A major pain point in migrating a WordPress site from HTTP to HTTPS has been the need to fix all the hard-coded URLs in existing database content which were still using the HTTP version, to avoid mixed content warnings. These URLs are usually migrated with a database replacement pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/, but that process is tedious and not intuitive to many WordPress administrators.

WordPress 5.7 introduces a new wp_replace_insecure_home_url() function which is hooked into various pieces of content to replace these insecure URLs on the fly. It relies on another new function wp_should_replace_insecure_home_url() which determines whether the URL replacement logic needs to run or not. All of the following conditions have to be fulfilled for the automatic content rewrites:

  • The site has to be using HTTPS, via wp_is_using_https().
  • A new internal flag option called https_migration_required has to be enabled. The option is automatically enabled when the “Site Address” and “WordPress Address” are switched to their HTTPS counterpart on a site with existing content. (In other words, a fresh_site that is immediately switched to HTTPS does not trigger the content rewrites logic.)
  • The “Site Address” and “WordPress Address” have to be using the same domain.

With the content rewriting of insecure URLs in place, the only change required to switch the site from HTTP to HTTPS is updating the “Site Address” and “WordPress Address” to their HTTPS counterparts. While this only entails updating two text input fields, it can still be simplified; this is why WordPress 5.7 includes another new function wp_update_urls_to_https() which updates both URLs accordingly. It also includes an extra check to verify that this resulted in WordPress correctly recognizing the site as using HTTPS; if not, the change automatically gets reverted to prevent any unexpected issues.

While the one-click migration introduced by WordPress 5.7 does not support advanced site configurations where e.g. “Site Address” and “WordPress Address” differ, it drastically simplifies migration in the common scenario; furthermore, the advanced configurations are often used by more technically savvy users that already know how to migrate to HTTPS anyway.

Administrators that would like to actually replace the URLs in the database can still do so. In that scenario, it is recommended to delete the https_migration_required option, to avoid the URL rewriting logic from running unnecessarily. Alternatively, the URL rewriting function can be unhooked entirely as follows:

remove_filter( 'the_content', 'wp_replace_insecure_home_url' );
remove_filter( 'the_excerpt', 'wp_replace_insecure_home_url' );
remove_filter( 'widget_text_content', 'wp_replace_insecure_home_url' );
remove_filter( 'wp_get_custom_css', 'wp_replace_insecure_home_url' );

Improved Site Health guidance

The HTTPS Status section in Site Health has been improved to guide the user more towards using HTTPS. If the environment already supports HTTPS (via wp_is_https_supported()), the UIUI User interface will now include a button to switch both site URLs with a single click (using wp_update_urls_to_https()). Users will need to have a new update_https metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. capability in order to perform the switch; by default this capability is granted to every user that can both manage_options and update_core.

HTTPS Status section when HTTPS is not yet supported by the environment
HTTPS Status section when HTTPS is already supported by the environment

Various minor improvements have been made to more accurately describe the site’s configuration. For example, sites that rely on the WP_HOME or WP_SITEURL constant will see this reflected now, since that means WordPress cannot automatically update these URLs.

The severityseverity The seriousness of the ticket in the eyes of the reporter. Generally, severity is a judgment of how bad a bug is, while priority is its relationship to other bugs. of not using HTTPS in the overall HTTPS Status Site Health test is now set to “critical”, whereas before it was “recommended”. This means that sites which do not use HTTPS will now see the “Should be improved” state in the Site Health dashboard widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user., highlighting this further.

Providing custom support URLs for switching to HTTPS

In order to further help to guide WordPress administrators towards the switch to HTTPS, hosting providers that have their own support content for how to switch to HTTPS can now provide these URLs to WordPress so that users can get to that guidance directly from their administration panel.

  • Hosts which offer their own dedicated HTTPS support content can provide the URL that by setting a WP_UPDATE_HTTPS_URL environment variable or by hooking into a new wp_update_https_url filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. If no such URL is provided, the default URL links to this HTTPS support article.
  • Hosts which offer a utility to automatically switch the site to HTTPS can provide the URL to do so by setting a WP_DIRECT_UPDATE_HTTPS_URL environment variable or by hooking into a new wp_direct_update_https_url filter. If no such URL is provided, the default URL triggers the aforementioned WordPress one-click mechanism.

For reference, see TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets #47577 about HTTPS detection and #51437 about HTTPS migration.

Props to @timothyblynjacobs for proofreading

#5-7, #dev-notes, #https, #site-health

Marius L. J. 6:42 pm on September 1, 2020
Tags: site-health   

Agenda for September 7th Site Health meeting

The Site Health meeting will be held on Monday September 7th, 2020, 16:00 UTC in #core-site-health on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. (a Slack account is required)

Meeting schedule / frequency

As we’re a rather small group, holding weekly meetings has proven to be a bit difficult with time management, let’s consider getting a fixed schedule with bi-weekly (or whatever is more appropriate) meetings instead.

WordPress 5.6

With work on WordPress 5.6 underway, let’s take a look at what we wish to accomplish with this release, and what our focuses should be.

PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher version support schedule

Please have a look at the proposed schedule for supporting older PHP versions, there are many comments which bring up a lot of valid points.

Proposal: Dropping support for old PHP versions via a fixed schedule

Let’s discuss next steps on how the team can help with the proposed schedule, and discuss the pain-points that were brought up and how these could be addressed.

#site-health

Marius L. J. 8:11 pm on May 7, 2020
Tags: , site-health   

Agenda for May 11th Site Health Meeting

The weekly Site Health meeting will be held on Monday, May 11, 2020, 16:00UTC in #core-site-health on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. (a Slack account is required)

During this past weeks dev chat, the item of moving the minimum PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher compatibility up further this year was brought up as a talking point. This will need a collaborative push to move towards. The desire target this time is PHP 7.1 as the minimum supported version, but to do so we will need to come up with a more effective way of encouraging users to do the upgrade.

At the time of writing, WordPress 5.2 or newer require PHP 5.6 to work. On top of that ~25% of all sites running these versions (WordPress 5.2, 5.3 and 5.4) are using PHP 7.0 or lower, that’s too high a number for us to bump the minimum required PHP version to where we want it.

The ServeHappy dashboard widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. alerts users with PHP versions lower than 7.0 at this time. An initial step here would be to increase that threshold to 7.2, the currently most popular version. The team is aware that PHP 7.1 is already EOL (End Of Life), and that 7.2 will be the same come January 2021 (See list of supported PHP versions), but this is a marathon so we are taking it in small leaps to not cause unintended disruptions to the userbase.

That said, the dashboard notice likely won’t be enough for a PHP version push this year, that’s why this upcoming meeting will be focused on brainstorming ideas on other approaches that will help this endeavor, as we will have the upcoming WordPress 5.5 release to implement any changes needed to help move towards the goal.

#agenda, #site-health

Marius L. J. 8:40 am on February 1, 2020
Tags: site-health   

Site Health January Review

This is a summary post for Site Health meetings held in January.

🎯 Focuses for 2020

A few focuses have been outlined for WordPress 5.4, and they are currently on track.

Surfacing the Site Health status with a dashbaord widget has its initial iteration committed, and aims to help inform and educate users and continue one of our purposes of helping keep websites running as smoothly as possible and being good internet citizens.

Another goal is to get compatibility checks for PHP version into themes, which is also in the review phase and is looking on schedule for this years roadmap.

Improving the Recovery Mode is our third focus. Current tickets focus on alternate ways to access recovery mode, and improving its performance in general.

🎫 Ticketticket Created for both bug reports and feature development on the bug tracker. triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. to align our selves

We also held a short-circuit ticket triage on Friday January 31, 2020, 16:00 UTC to make sure all the current planned tickets for the next upcoming WordPress release, 5.4, were on track and moving as expected.

This let us re-prioritize some that were no longer required, as they were superseded by other tasks that were already completed, and also gave better insights into remaining tickets that needed some direction.

🙌 Get involved

If you would like to improve the Site Health component, we’re always up for new ideas.

Here’s how you can get involved:

We look forward to seeing you all at our next meeting!

#site-health

Timothy Jacobs 5:56 pm on January 31, 2020
Tags: , , site-health   

REST API: Introduce dashboard namespace

Summary

We propose to introduce a dashboard REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. namespace prefix, for use on endpoints specifically relating to the WordPress adminadmin (and super admin) dashboard.

Motivation

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. currently contains two namespace prefixes: wp and oembed. These represent two separate APIs offered by WordPress: the general REST API which exposes structured WordPress data objects to external clients, and the OEmbed implementation.

The general design of WordPress distinguishes between the core, and the Dashboard “application” built on top of it. These two have not traditionally been formally separated, however the design and clean slate of the REST API allows us to consider these separately as we evolve the Dashboard.

With the push towards removing admin-ajax handlers in favour of new REST API endpoints, there are naturally APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. endpoints being introduced which are not useful outside of the administrative interface. Endpoints for Dashboard Widgets, pointers, and other features are specific to the Dashboard application, and are not broadly applicable to public-facing WordPress sites or third-party applications.

Introducing a new dashboard namespace prefix allows separating Dashboard-specific endpoints from the public WordPress REST API. This can also allow for future changes, deprecations, and new versions of the Dashboard API without requiring a version bump for the public REST API.

Detailed design

New endpoints for the Dashboard will live under dashboard/, initially with the namespace dashboard/v1 for the first version of endpoints.

Future iterations of the Dashboard that need to break API backwards compatibility can increment the version under the same namespace prefix as needed (e.g. dashboard/v2, dashboard/v3). These new versions do not need to affect the public WordPress REST API.

This requires no code changes, as it simply designates the namespace for future use. The first endpoints to be added under this new namespace are expected to be the endpoints for Site Health (#48105) in WordPress 5.4.

How do we communicate this?

The new endpoints under the dashboard namespace prefix will collectively be called the Dashboard REST API to distinguish them from the public WordPress REST API.

There are no user-facing changes resulting from this proposal. Likewise, there is no effect on pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, theme, or API client developers.

The difference between wp and dashboard needs to be communicated to core developers working on the Dashboard and related features. The announcement of this RFC on the Make/Core blogblog (versus network, site) will serve as an initial announcement, but evergreen documentation should be added to the Core Handbook.

A new page will be added to the REST API Handbook under the “Best Practices” section, outlining design guidelines for new endpoints added to WordPress Core. The proposed text for this page is:

REST API

Core implementations of REST API endpoints should follow some simple rules to ensure WordPress provides a consistent public data interface.

Creating New Endpoints

Where possible, core features should use existing REST API endpoints rather than adding new ones. For example, a tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) search feature should use the existing tag collection endpoint in the REST API rather than building one specifically for the feature.

When a new endpoint is required, care should be put into the design of the external API. In particular, the shape and schema of the resource, the namespace, the route (URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org), and the available actions should match existing precedent in core.

REST API endpoints intended for public use and which represent “core” features of WordPress should be under the public REST API namespace (wp/v2). Endpoints which are only applicable for the Dashboard (e.g. Dashboard Widgets, pointers, or other UIUI User interface settings) should be under the Dashboard REST API namespace (dashboard/v1). This ensures a clear distinction between APIs for general consumption and APIs built for specific UI features.

The design and implementation of the endpoint can be checked by the REST API team before committing to ensure it is consistent with the rest of the API. This helps us provide a more consistent experience for API consumers.

Drawbacks

Introducing a new core namespace could impact third-party plugins or other code which uses the same namespace string. This represents a minor backwards compatibility break, and investigation needs to be done as to whether we’re breaking any major plugins with this change.

It could also be argued that it fragments core’s API surface to introduce an entirely new namespace. Making the distinction of which namespace to use is tough, and this might lead to features that could have general applicability existing only as part of the Dashboard API, without a public API for use by external clients.

In addition, adding a new namespace opens the question of whether more even namespaces are needed. For example, should there be a CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. namespace? Do other features need their own namespaces as well?

Alternatives

There are a few main alternatives to creating a dashboard namespace prefix.

The first is to use the current wp/v2 namespace for endpoints relating to administrative interfaces like Site Health. The main reason to avoid doing this is that it couples Dashboard-specific features to the public REST API. These features are rarely applicable or usable outside of the Dashboard application, especially in third-party plugin interfaces or external clients. In addition, this would also tie Dashboard API versioning to the public REST API, which could lead to the public REST API version being needlessly bumped for Dashboard-only changes.

Another alternative is to use a sub-namespace prefix of the existing wp prefix, such as wp/dashboard. This avoids any risk of impacting existing plugins as wp is already known to be reserved for core. However, this breaks the current precedent of <prefix>/v<version>, increasing the complexity of API namespacing. Given that it is unlikely that the dashboard prefix is currently being used, the simpler option of dashboard/v1 is preferred. This also discourages a proliferation of sub-namespaces under the wp prefix.

The final alternative is creating a separate namespace for each feature, such as site-health/v1. This could have the advantage of making endpoints more discoverable, and would reduce the overall length of each endpoint’s URIs. A dashboard prefix may also imply that its endpoints are “private” to WordPress and specific to the WordPress display context in cases where future endpoints may be useful in third-party tools. This approach has the disadvantage that plugin developers may worry that any namespace they pick could eventually be reappropriated by WordPress core.

Unresolved Questions

  • Should we use admin/v1 or dashboard/v1? To some dashboard is unclear and meaningless, to others admin is very specific to wp-admin whereas dashboard is more general idea of management.
  • Should we use dashboard/v1 or wp/dashboard/v1? The former could potentially clash with plugins, and is much more generic. We also need to pave the way for further namespaces that may be added to core in the future, where clashes may be more common.

Originally written by @rmccue as a WP-API Proposal.

#5-4, #rest-api, #site-health

Marius L. J. 2:34 am on August 13, 2019
Tags: site-health   

Increasing the recommended PHP version in core

The recommendation to update your PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher for users running version 5.6 or lower is scheduled to go live on August 20th, 2019.

A few weeks back, we outlined the plans to continue the work that was begun around WordPress 5.1 on increasing the PHP version recommended (and subsequently required) by WordPress.

Now that feedback has been gathered from multiple venues, both on various make blogs, and different team chats to spread the word about these blogblog (versus network, site) posts, it’s time to start acting on them.

We had originally wanted to push the changes out sooner, but will admit that with mass holidays happening during the start of August, this fell through.

That said, the plans are now in motion, a meta ticket has been created to keep things on track, and the bump is scheduled for August 20th, 2019.

#site-health

Jenny Wong 11:43 am on July 29, 2019
Tags: site-health   

Proposal for increasing recommended PHP version in WordPress

I would like to propose we trigger displaying the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher update widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. for users of PHP 5.6 in WordPress.

At the time of writing, the WordPress stats show that:

  • PHP 5.6 has a usage share of 29.1%
  • PHP 7.0 has a usage share of 16.2%
  • PHP 7.1 has a usage share of 13.2%
Pie chart showing the usage share of each PHP version used by WordPress sites.

This proposal is based around multiple discussions in Hosting Team meetings, a P2 post and within core-site-health conversations.

A majority of respondents have suggested increasing the minimum requirement to PHP 7.2. The site-health maintainers agree with the sentiment but we would like to get to that point by introducing a series of incremental increases over the remainder of 2019.

When?

Our suggested roadmap to increase the minium PHP version is:

  1. Display the PHP update widget for PHP 5.6. This will trigger the widget for anyone using PHP 5.6 or below and WordPress 5.1+ in their dashboards warning them of the fact we recommend upgrading the version of PHP.
  2. Display the PHP update widget for users of PHP 7.0 and below.
  3. Based around support and stats of points 1 and 2, have a discussion about whether the next step should be displaying the PHP update widget for PHP 7.1 or a direct increase of the required minimum version to PHP 7.2.

We suggest to start showing the update recommendation for users of PHP 5.6 or lower starting August 5th, the timeline for showing the warning to PHP 7.0 users will be announced in a followup post, and relies on factors like support load, and adoption rate from the previous increase.

Why the PHP update widget?

In discussions, multiple people have highlighted that many sites do not update plugins and themes due to paywalls. In some circumstances it can mean their version of the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme is not compatible with more modern versions of PHP. This is especially the case for many popular premium plugin and theme users.

We hope that the PHP update widget will encourage users to update all their plugins and themes, incluing all premium ones. By doing so, their PHP migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. at a hosting level would go much smoother, and help pave the way for raising the minimum requirements of WordPress further in a timely manner.

Another reason for going in with the update widget first is so we are able to drip feed the support requests for the multiple teams which have to handle the support for changes like this. This includes but not limited to community, hosting, plugins, themes and support forumSupport Forum WordPress Support Forums is a place to go for help and conversations around using WordPress. Also the place to go to report issues that are caused by errors with the WordPress code and implementations. teams.

Screenshot of the PHP Update Widget

Feedback welcomed

If you have any questions, suggestions, or comments, the #site-health conponent would be gratful if you comment on this post with your thoughts.

Thank you.