This aims to make the update process more reliable and ensures that if a plugin or theme update fails, the previous version can be safely restored.
* When updating a plugin or theme, the old version is moved to a temporary backup directory:
* `wp-content/upgrade/temp-backup/plugins/[plugin-slug]` for plugins
* `wp-content/upgrade/temp-backup/themes/[theme-slug]` for themes.
* If the update fails, then the temporary backup kept in the `upgrade/temp-backup` directory is restored to its original location.
* If the update succeeds, the temporary backup is deleted.
To further help troubleshoot plugin and theme updates, two new checks were added to the Site Health screen:
* A check to make sure that the `temp-backup` directory is writable.
* A check that there is enough disk space available to safely perform updates.
To avoid confusion: The `temp-backup` directory will NOT be used to "roll back" a plugin to a previous version after a completed update. This directory will simply contain a transient backup of the previous version of a plugin or theme being updated, and as soon as the update process finishes, the directory will be empty.
Props aristath, afragen, pbiron, dd32, poena, TimothyBlynJacobs, audrasjb, mikeschroder, a2hosting, hellofromTonya, KZeni, galbaras, richards1052, Boniu91, mai21, francina, SergeyBiryukov.
See #51857.
Built from https://develop.svn.wordpress.org/trunk@51815
git-svn-id: http://core.svn.wordpress.org/trunk@51422 1a063a9b-81f0-0310-95a4-ce76da25c4cd
By the time the tests run, both `wp_is_site_protected_by_basic_auth()` and `rest_url()` functions are available, so there is no need to check for their existence.
Follow-up to [44986], [51057].
Props Clorith, costdev, SergeyBiryukov.
Fixes#52642.
Built from https://develop.svn.wordpress.org/trunk@51066
git-svn-id: http://core.svn.wordpress.org/trunk@50675 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The test to confirm if Authorization headers can be used and recognized by WordPress needs to include a username and password combination that WordPress can compare against during the testing phase. The inclusion of credentials here would unfortunately also invalidate any existing basic auth session for the site, for example if the user had added this as an extra layer of security on their back-end.
This test is now skipped if the `wp_is_site_protected_by_basic_auth()` function detects that basic auth is being used, since the act of using basic auth to access the site confirms that this feature is working as expected in the first place.
Props WebDragon, TimothyBlynJacobs, costdev.
Fixes#52642.
Built from https://develop.svn.wordpress.org/trunk@51057
git-svn-id: http://core.svn.wordpress.org/trunk@50666 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change fixes a false positive that would appear during scheduled events, by only running the REST test when a user visits the Site Health page, meaning an active session is available.
The test checking if the REST API is available, includes a parameter for `context=edit` to make sure the block editor can function properly. This means a user session with editor capabilities is required for the test to pass, which is not the case during a scheduled event.
Props szaqal21, TimothyBlynJacobs, hermpheus.
Fixes#52112.
Built from https://develop.svn.wordpress.org/trunk@50939
git-svn-id: http://core.svn.wordpress.org/trunk@50548 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Allow developers to extend the Site Health screen with their own custom navigation tabs and pages.
This implements a new filter, `site_health_navigation_tabs`, which takes an associated array of tab identifiers/slugs, and tab labels, allowing developers to add their own subpage to the Site Health interface as new tabs.
To output a custom page, or add to an existing page, the `site_health_tab_content` action is triggered whenever the `tab` query argument is present and not empty. This action includes the current tab as its argument, which a developer would match against to only output content when relevant.
Props ramiy for initial patch.
Fixes#47225.
Built from https://develop.svn.wordpress.org/trunk@50764
git-svn-id: http://core.svn.wordpress.org/trunk@50373 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Reduce severity of failing HTTPS tests from critical to warning. Stop reporting failures if the site is being accessed over HTTPS but `wp_is_https_supported()` indicates a lack of support.
Props annalamprou, AnotherDave, ayeshrajans, bobbingwide, Clorith, dragongate, eatsleepcode, gab81, geoffrey1963, Ipstenu, k3nsai, mmuyskens, nicegamer7, peterwilsoncc, pwallner, SergeyBiryukov, TimothyBlynJacobs, Toru.
Fixes#52783.
Built from https://develop.svn.wordpress.org/trunk@50659
git-svn-id: http://core.svn.wordpress.org/trunk@50271 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Replace loopback health check URL with a `POST` request to `wp-cron.php` in the WordPress install directory. This more closely represents how WordPress uses loopback requests.
A `POST` request is used to cause `wp-cron.php` to exit prior to running any cron jobs. This allows the test to indicate success quicker and accounts for sites that set the `DISABLE_WP_CRON` constant to avoid running cron jobs on loopback requests.
Props clorith, peterwilsoncc, TimothyBlynJacobs.
Fixes#52547.
Built from https://develop.svn.wordpress.org/trunk@50399
git-svn-id: http://core.svn.wordpress.org/trunk@50010 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This adds a more descriptive text in scenarios where `post_max_size` and `upload_max_filesize` differ, and `post_max_size` is set to a value of `0`.
In some scenarios, PHP may read `0` as a literal zero size, and not as unlimited, which it also means in other scenarios.
See https://www.php.net/manual/en/ini.core.php#ini.post-max-size for details, as PHP 5.3.4 introduced this behavior for literal zero interpretation when the content type of a request is `application/x-www-form-urlencoded` or is not registered with PHP.
Props Clorith, pixolin, helen, ratneshk.
Fixes#51466.
Built from https://develop.svn.wordpress.org/trunk@50263
git-svn-id: http://core.svn.wordpress.org/trunk@49908 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Switching a WordPress site from HTTP to HTTPS has historically been a tedious task. While on the surface the Site Address and WordPress Address have to be updated, existing content still remains using HTTP URLs where hard-coded in the database. Furthermore, updating _two_ URLs to migrate to HTTPS is still a fairly unintuitive step which is not clearly explained.
This changeset simplifies migration from HTTP to HTTPS and, where possible, makes it a one-click interaction.
* Automatically replace insecure versions of the Site Address (`home_url()`) with its HTTPS counterpart on the fly if the site has been migrated from HTTP to HTTPS. This is accomplished by introducing a `https_migration_required` option and enabling it when the `home_url()` is accordingly changed.
* A new `wp_replace_insecure_home_url()` function is hooked into various pieces of content to replace URLs accordingly.
* The migration only kicks in when the Site Address (`home_url()`) and WordPress Address (`site_url()`) match, which is the widely common case. Configurations where these differ are often maintained by more advanced users, where this migration routine would be less essential - something to potentially iterate on in the future though.
* The migration does not actually update content in the database. More savvy users that prefer to do that can prevent the migration logic from running by either deleting the `https_migration_required` option or using the new `wp_should_replace_insecure_home_url` filter.
* For fresh sites that do not have any content yet at the point of changing the URLs to HTTPS, the migration will also be skipped since it would not be relevant.
* Expose a primary action in the Site Health recommendation, if HTTPS is already supported by the environment, built on top of the HTTPS detection mechanism from [49904]. When clicked, the default behavior is to update `home_url()` and `site_url()` in one go to their HTTPS counterpart.
* A new `wp_update_urls_to_https()` function takes care of the update routine.
* A new `update_https` meta capability is introduced to control access.
* If the site's URLs are controlled by constants, this update is not automatically possible, so in these scenarios the user is informed about that in the HTTPS status check in Site Health.
* Allow hosting providers to modify the URLs linked to in the HTTPS status check in Site Health, similar to how that is possible for the URLs around updating the PHP version.
* A `WP_UPDATE_HTTPS_URL` environment variable or `wp_update_https_url` filter can be used to provide a custom URL with guidance about updating the site to use HTTPS.
* A `WP_DIRECT_UPDATE_HTTPS_URL` environment variable or `wp_direct_update_https_url` filter can be used to provide a custom URL for the primary CTA to update the site to use HTTPS.
Props flixos90, timothyblynjacobs.
Fixes#51437.
Built from https://develop.svn.wordpress.org/trunk@50131
git-svn-id: http://core.svn.wordpress.org/trunk@49810 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Following up on [49904], this changeset focuses mainly on improving the guidance about the current state of HTTPS in Site Health.
* Correct the existing copy to indicate that both the Site Address and the WordPress Address need to be changed to fully switch to HTTPS.
* Link to the respective input fields via anchor links rather than to the overall General Settings screen.
* Show different copy if the site is using HTTPS for the WordPress Address (for example to have only the administration panel in HTTPS), but not for the Site Address.
* Inform the user about potential problems even when the site is already using HTTPS, for example if the SSL certificate was no longer valid.
* Always rely on fresh information for determining HTTPS support issues in Site Health, and therefore change the `https_status` test to become asynchronous.
* Rename the new private `wp_is_owned_html_output()` function to a more appropriate `wp_is_local_html_output()`.
Props adamsilverstein, flixos90, johnjamesjacoby, timothyblynjacobs.
See #47577.
Built from https://develop.svn.wordpress.org/trunk@50072
git-svn-id: http://core.svn.wordpress.org/trunk@49773 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [49154] the async Site Health tests were changed to use the REST API instead of admin-ajax. An unintended side effect of this change was that the loopback tests which tried to ping the site's `admin_url()` were no longer authenticated because admin-cookies aren't provided to the REST API.
This commit adjusts the loopback test to use the front-end `site_url` which checks that cron will function properly. A follow-up ticket will focus on tests that will cover the file editor checks.
Props Clorith.
Fixes#52097.
See #48105.
Built from https://develop.svn.wordpress.org/trunk@49917
git-svn-id: http://core.svn.wordpress.org/trunk@49616 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset modifies the Site Health panel for HTTPS to provide more accurate recommendations based on whether the environment is already set up for HTTPS.
* Introduces `wp_is_using_https()` to check whether the site is configured to use HTTPS (via its Site Address and WordPress Address).
* Introduces `wp_is_https_supported()` to check whether the environment supports HTTPS. This relies on a cron job which periodically checks support using a loopback request.
Props Clorith, flixos90, miinasikk, westonruter.
Fixes#47577.
Built from https://develop.svn.wordpress.org/trunk@49904
git-svn-id: http://core.svn.wordpress.org/trunk@49603 1a063a9b-81f0-0310-95a4-ce76da25c4cd
App Passwords rely on the Authorization header to transport the Basic Auth credentials. For Apache web servers, WordPress automatically includes a RewriteRule to populate the value for servers running in CGI or FastCGI that wouldn't ordinarily populate the value.
This tests if the header is being filled with the expected values. For Apache users, we direct the user to visit the Permalinks settings to flush their permalinks. For all other users, we direct them to a help document on developer.wordpress.org.
Props Clorith, marybaum, TimothyBlynJacobs.
Fixes#51638.
Built from https://develop.svn.wordpress.org/trunk@49334
git-svn-id: http://core.svn.wordpress.org/trunk@49095 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This allows Site Health tests to check if the current environment type is set to `development` or `local`.
Use the new method:
* In HTTPS tests, instead of a hardcoded check for `localhost`.
* In `WP_DEBUG` and `WP_DEBUG_DISPLAY` tests, to set the status to `recommended` instead of `critical`.
Props dkotter, Clorith, DavidAnderson, joyously, knutsp, afragen, SergeyBiryukov.
Fixes#47058.
Built from https://develop.svn.wordpress.org/trunk@49237
git-svn-id: http://core.svn.wordpress.org/trunk@48999 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change adds additional logic to catch HTTP failures that do not return a `WP_Error` object (for example, a wp-json REST API error error).
This also fixes instances where REST API callbacks performed from cron do not work due to a lack of authentication by introducing a direct callback route that asynchronous tests can register.
Props dd32, clorith, timothyblynjacobs.
Fixes#51547.
Built from https://develop.svn.wordpress.org/trunk@49232
git-svn-id: http://core.svn.wordpress.org/trunk@48994 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When `noopener noreferrer` was originally added in #37941 and related tickets, the `noreferrer` bit was specifically included due to Firefox not supporting `noopener` at the time.
Since `noopener` has been supported by all major browsers for a while, it should now be safe to remove the `noreferrer` attribute from core.
Props Mista-Flo, audrasjb, joostdevalk, jonoaldersonwp, peterwilsoncc, elgameel.
Fixes#49558.
Built from https://develop.svn.wordpress.org/trunk@49215
git-svn-id: http://core.svn.wordpress.org/trunk@48977 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Using the canonical function name for PHP functions is strongly recommended, as aliases may be deprecated or removed without (much) warning.
This replaces all uses of the following:
* `join()` with `implode()`
* `sizeof()` with `count()`
* `is_writeable()` with `is_writable()`
* `doubleval()` with a `(float)` cast
In part, this is a follow-up to #47746.
Props jrf.
See #50767.
Built from https://develop.svn.wordpress.org/trunk@49193
git-svn-id: http://core.svn.wordpress.org/trunk@48955 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This provides more flexibility when writing tests and benefits from running in a front-end context which is necessary for some tests like checking that updates are supported. Additionally, this provides a more robust interface for developers who want to integrate with Site Health tests.
Because the `wp/v2` endpoint is reserved for modeling core entities, site health is registered in its own `wp-site-health/v1` namespace.
The existing ajax actions have been maintained for backward compatibility.
Props Clorith, chrisvanpatten, afragen, pokhriyal, TimothyBlynJacobs.
Fixes#48105.
Built from https://develop.svn.wordpress.org/trunk@49154
git-svn-id: http://core.svn.wordpress.org/trunk@48916 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, the warning was displayed even if the value was higher than `upload_max_filesize`, which made the report inaccurate, as these values don't necessarily have to match.
Props oakesjosh, jeroenrotty, desrosj, Clorith.
Fixes#50945.
Built from https://develop.svn.wordpress.org/trunk@48800
git-svn-id: http://core.svn.wordpress.org/trunk@48562 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Several new checks:
* `max_file_uploads`
* `file_uploads`
* `post_max_size`
* `upload_max_filesize`
* `upload_max`
* `max_file_uploads`
In addition, new function `parse_ini_size()` that converts shorthand byte strings to bytes. Useful for size comparisons.
Fixes#50038.
Props dd32, donmhico, JavierCasares, SergeyBiryukov, ayeshrajans, Clorith, ipstenu, sabernhardt, whyisjake.
Built from https://develop.svn.wordpress.org/trunk@48535
git-svn-id: http://core.svn.wordpress.org/trunk@48297 1a063a9b-81f0-0310-95a4-ce76da25c4cd
