The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
TL;DR Over 37% of WordPress sites are running a version of database software that has reached end of life and is no longer receiving maintenance or security updates. To encourage broader adoption of secure and supported database versions, WordPress should clarify that only LTS releases of MySQLMySQLMySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. and MariaDB are officially supported by excluding those with short lifespans or no guarantee of backward compatibility.
As a community, we frequently champion efforts to keep software and tools updated to their latest versions. This typically surfaces for users in the form of PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher upgrades, and for contributors with tools like Node.js and npm. Database software is equally important to site health but has historically received far less attention.
The release models followed by supported database types have changed quite a bit since the early days of WordPress. With that comes a need to update the project’s official policy for clarity. A clearer policy lends to a wider understanding of the expectations and requirements for maintaining WordPress sites.
But before getting into the changes being proposed, let’s define the various types of releases and examine current usage data before outlining a few things for discussion.
There are currently two types of database software officially supported for running WordPress: MySQL and MariaDB. While it’s true that SQLite powers Playground, standard installs of WordPress do not currently support SQLite without installing the feature plugin, which is being actively developed and tested.
Release Types
Both software projects have made several changes to the terminology used to reference releases, making it confusing and inconsistent. For the sake of clarity, here are the different terms associated with releases of MySQL and MariaDB.
Note: All asterisks (*) below indicate versions that have reached end of life (EOL) and are no longer supported upstream. Also, EOL does not always equal “unsupported by WordPress” (more on that later).
Long Term Support (LTS)
LTS versions are published by both projects. These are the most common versions found in the wild. They are actively supported for 5 years from the initial release. After initial release, data formats are not changed, no new functionality is introduced, and no features are removed.
While MariaDB aims to release a new LTS version annually, MySQL publishes a new LTS version every 2 years (starting with 8.4). The list of releases labelled as LTS to date is as follows:
Version
Project
Initial Release
EOL Date
8.4
MySQL
April 30, 2024
April 2032
8.0
MySQL
April 19, 2018
April 2026
11.8
MariaDB
June 5, 2025
June 2030
11.4
MariaDB
November 22, 2024
May 29, 2029
10.11
MariaDB
February 16, 2023
February 16, 2028
10.6
MariaDB
July 6, 2021
July 6, 2026
10.5*
MariaDB
June 24, 2020
June 24, 2025
10.4*
MariaDB
June 18, 2019
June 18, 2024
The following releases were treated as LTS versions, but were not explicitly labelled as such:
Version
Project
Initial Release
EOL Date
5.7*
MySQL
October 21, 2015
October 21, 2023
5.6*
MySQL
February 5, 2013
February 5, 2021
5.5*
MySQL
December 3, 2010
December 3, 2018
5.1*
MySQL
November 14, 2008
December 31, 2013
Innovation Releases
Though both projects use this classification, only the MySQL project actively uses it as described in this section (see the next section for how MariaDB currently uses the designation). Innovation releases aim to provide early access to new features and improvements without having to wait the full 2 years for the next MySQL LTS version to be published.
The following types of changes are included in new innovation releases:
New features planned for the next LTS
Security fixes
Bug fixes
New deprecations
Removal of features
Behavior changes.
These releases are Generally Available and are acceptable to use in production environments. They are published once per quarter (every 3-4 months). When the next innovation release is published, all support for the previous one is dropped, including security fixes. Because the lifespan of each innovation release is extremely short, consistent regular attention is required to remain supported and secure.
The following is a list of MySQL innovation releases.
Version
Initial Release
EOL Date
9.3
April 15, 2024
July 2025
9.2*
January 21, 2025
April 15, 2025
9.1*
October 14, 2024
January 21, 2025
9.0*
July 1, 2024
October 15, 2024
8.3*
January 16, 2024
July 1, 2024
8.2*
October 25, 2023
January 16, 2024
8.1*
July 18, 2023
October 25, 2023
MariaDB used this label for about 2 years. During that time, they also published a new innovation release every quarter. However, their innovation releases were supported for 1 year after initial GA release. These releases also differed from MySQL in that caution was advised when using these. As of the publish date of this post, all MariaDB innovation releases have reached EOL.
Version
Initial Release
EOL Date
11.2*
November 21, 2023
November 21, 2024
11.1*
August 21, 2023
August 21, 2024
11.0*
June 7, 2023
June 6, 2024
10.10*
November 17, 2022
November 14, 2023
10.9*
August 22, 2022
August 22, 2023
10.8*
May 21, 2022
May 20, 2023
10.7*
February 14, 2022
February 9, 2023
Rolling GA (MariaDB only)
Though they’re similar in some ways, MariaDB now has replaced innovation releases with rolling GA releases. Rolling GA releases are published every quarter (3-4 months) and receive no patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. versions (the GA release is final). All support for the previous rolling release is dropped once a new one is published.
The term innovation release is still used but now refers to the preview (X.Y.0) and RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). (X.Y.1) pre-release versions for each rolling release. Rolling GA releases are intended for production use, but the innovation releases are not.
Rolling Release Versions
Initial Release
EOL Date
12.1 (currently in preview innovation release)
TBD
12.0 (currently RC innovation release)
TBD
11.7*
February 13, 2025
May 12, 2025
11.6*
November 22, 2024
February 13, 2025
11.5*
August 15, 2024
November 21, 2024
11.3*
February 19, 2024
May 16, 2024
Major Releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.
MySQL refers to major versions in the same way as WordPress (X.(Y+1)).
For MariaDB, this term has meant different things during different timeframes.
10.3 and earlier
X.(Y+1)
Every new release
10.4-11.2
X.(Y+1)
Each version was considered major because of binary incompatibility and the addition of new features. LTS or short-term become more common descriptors as they indicate length of support (similar to WordPress).
Current day *(>= 11.3)
(X+1).0
Only when the first number changes (similar to PHP).
While the LTS designation did not exist yet, versions 10.3 and earlier were treated in a similar way.
Supported for 3-5 years (sometimes longer)
Bug fixes and security updates were provided
New features were sometimes included in minor (X.Y.(Z+1)) releases, but compatibility was always maintained.
All MariaDB major releases <= 10.3 have reached EOL. They’re listed below for completeness:
MariaDB Major Versions <= 10.3
Initial Release
EOL Date
10.3*
May 25, 2018
May 25, 2023
10.2*
May 23, 2017
May 23, 2022
10.1*
October 17, 2015
October 17, 2020
10.0*
March 31, 2014
March 31, 2019
5.5*
April 11, 2012
April 11, 2020
5.3*
February 29, 2012
March 1, 2017
5.2*
November 10, 2010
November 10, 2015
5.1*
February 1, 2010
February 1, 2015
While some online resources show the LTS label next to these versions, they were never officially labelled as such.
Short-term (MariaDB Only)
This term was eventually replaced by innovation release. This applied to MariaDB 10.4 in addition to the MariaDB versions listed above under Innovation Releases. As of the publish date for this post, all short-term releases have reached EOL.
Current Database Usage Data
Here is the usage data according to the WordPress.org Stats page as of June 18, 2025 summarized in a few different ways:
By Software
Version
Usage
MariaDB – all versions
52.8%
MySQL – all versions
47.2%
By Version Type
Release Type
Usage
MariaDB LTS (includes old major releases without LTS official designation)
51.17%
MySQL LTS (includes old major releases without LTS designation)
46.74%
MariaDB Innovation/Short-term/Rolling Releases
1.52%
MySQL Innovation Releases
0.07%
Other
0.5%
By Support Status
Support Status
Usage
EOL versions (MariaDB)
11.43%
EOL versions (MySQL)
26.01%
Supported (MariaDB)
41.56%
Supported (MySQL)
21.05%
Observations
There are a few interesting things that stand out from the usage data.
As of March 2025, MariaDB now powers more WordPress sites than MySQL. This is particularly interesting because as of January 2024, the split was ~63%/37% in favor of MySQL. Increases in licensing costs and changes to widely used distributions during 2023 and 2024 are likely the considerable drivers of this surge.
Over 37% of WordPress sites are running a version of database software that has reached end of life and is no longer receiving maintenance or security updates.
The highest adoption of any innovation/short-term/rolling release was MariaDB 11.3, which reached 0.15%.
No other innovation/short-term/rolling releases have surpassed more than 0.10% adoption at any given point in time.
Current State of Database Support in WordPress
Despite MySQL and MariaDB having different release models that drop support in different ways in non-sequential order, WordPress has a very binary support policy. As of the publish date of this post, the support policy is as follows:
Recommended: MySQL >= 8.0 OR MariaDB >= 10.6
Required: MySQL OR MariaDB >= 5.5.5
A few notes:
MariaDB 10.5 reached EOL on June 24th. The recommended version was updated to >= 10.6 on June 18, 2025 (see #60319 and #meta-8013).
The minimum required version was last bumped in late 2023 (see [57173]).
The policy as currently stated is lacking any guidance around which types of releases are supported. As demonstrated above, this is complicated and convoluted. The policy should be expanded a bit to cover release types and not just versions.
Proposal: Clarify Supported Release Types
While described as production-grade, innovation releases have several shortcomings when considering the majority of WordPress sites.
Features and changes included in innovation/rolling releases are considered stable, but they can be modified or even removed entirely in future releases. No functionality can be considered supported until included in an LTS release.
Their ephemeral nature makes it very difficult to ensure compatibility with WordPress when released. Depending on how release timelines overlap, there could be 2 (or more) innovation/rolling versions published in between major WordPress releases.
Their extremely short lifespans could potentially leave large numbers of sites running insecure versions.
Updating database software is often tied to factors out of the site owner’s control (waiting for server distributions to be updated and made available through your hosting, platform compatibility limitations, compliance/licensing requirements, etc.).
For both projects, updating these release types is complicated. Updates must be applied sequentially. For example, upgrading from 9.1 to 9.3 is not supported (9.1 must first be updated to 9.2 before updating to 9.3). This is not required when upgrading to the next LTS.
Over the last two years, these release types have not shown significant usage, even when combining the numbers across database types.
Because the changes in these releases are not guaranteed to be backwards compatible, committing to full compatibility with these releases is not a good use of contributor time and could result in making code harder to maintain.
Changes to the Database Recommendations
This proposal is suggesting that the recommendations for running WordPress be updated as follows:
No change: The oldest LTS versions actively supported upstream should continue being used as the recommended minimums.
Add to the Requirements page, CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress./Hosting/Support/Other? Handbooks: Innovation and rolling GA releases are explicitly not recommended for production sites.
Add to the Hosting Handbook: Hosting companies are explicitly advised not to use Innovation and Rolling GA releases as the default for new sites.
The WordPress PHPUnit testing workflow currently runs the test suite using the most recent MySQL innovation and MariaDB rolling GA releases. This practice helps to make contributors aware of potential incompatibilities and breaking changes so they can be addressed prior to the next LTS version. This practice will continue.
Because of this, it’s reasonable to expect WordPress to have very few (if any) issues when running these releases. However, this is not guaranteed as contributors must weigh the benefits of making changes for the sake of compatibility with the non-zero chance that the feature is changed or removed before the next LTS release.
Because innovation and rolling GA releases are never supported, only LTS versions are eligible as new minimums when considering changes to the minimum required versions of MariaDB/MySQL to run WordPress in the future.
In summary, someone is free to run innovation and rolling GA releases, but they do so at their own risk.
Other Considerations
As a part of this, ways to further educate and empower the user should also be explored.
Should servehappy be expanded to display a dashboard notice to the user when their site is running an outdated or unsupported version of MariaDB/MySQL (see #63634)?
Can there be additional context for the database checks in Site Health to detect innovation/rolling GA releases explaining why they should consider using an LTS version instead?
Are there ways to enhance WP-CLIWP-CLIWP-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/ to properly advise about these risky release types?
Are any metaMetaMeta 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. changes required to better inform the site that these release types are not explicitly supported?
Do the auto-update related classes require any changes?
Working Together
Reliable and supported database software is foundational to the performance, security, and longevity of WordPress a site. Historically, efforts to promote upgrades among hosts and site owners have been limited and inconsistently prioritized. Clarifying the types of database releases that WordPress supports and is compatible with marks an important first step. It enables contributors, hosts, and site owners to move toward more secure and sustainable versions of MariaDB and MySQL.
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_urlfilterFilterFilters 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.
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.
This proposal seeks to integrate two new Site Health checks for Persistent Object Cache and Full Page Cache into WordPress coreCoreCore 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.
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 TracTracAn 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 pluginPluginA 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:
Hosts or site owners may want to bypass thresholds and force suggestions, or filterFilterFilters 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:
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.
With WordPress 5.8, the feature requestfeature requestA 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 coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., with accompanying tab navigation in the Site Health headerHeaderThe 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.
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_tabsfilterFilterFilters 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 pluginPluginA 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.
WordPress 5.7 will feature a number of enhancements which simplify the migrationMigrationMoving 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 HTTPHTTPHTTP 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 HTTPSHTTPSHTTPS 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 URLURLA 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 SSLSSLSecure 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 HTMLHTMLHyperText 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 pluginPluginA 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-CLIWP-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:
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 UIUIUser 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_httpsmetaMetaMeta 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 environmentHTTPS 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 severityseverityThe 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 widgetWidgetA 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_urlfilterFilterFilters 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 TracTracAn 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.
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.
PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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.
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.
During this past weeks dev chat, the item of moving the minimum PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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 widgetWidgetA 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.
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.
Improving the Recovery Mode is our third focus. Current tickets focus on alternate ways to access recovery mode, and improving its performance in general.
🎫 TicketticketCreated for both bug reports and feature development on the bug tracker.triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. to align our selves
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.
We propose to introduce a dashboardREST APIREST APIThe 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 coreCoreCore 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 APIAPIAn 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 pluginPluginA 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 tagtagA 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 (URLURLA 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 UIUIUser 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 CustomizerCustomizerTool 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.
The recommendation to update your PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher for users running version 5.6 or lower is scheduled to go live on August 20th, 2019.
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.
You must be logged in to post a comment.