This commit adds the `public` visibility keyword to each method which did not have an explicit visibility keyword.
Why `public`?
With no visibility previously declared, these methods are implicitly `public` and available for use. Changing them to anything else would be a backwards-compatibility break.
Props costdev, jrf.
See #54177.
Built from https://develop.svn.wordpress.org/trunk@51919
git-svn-id: http://core.svn.wordpress.org/trunk@51512 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids a few type problems further in the code: boolean divided by a number, or passing `false` to `size_format()` which is documented to accept integers or strings only.
Follow-up to [51815].
Props TobiasBg.
See #51857.
Built from https://develop.svn.wordpress.org/trunk@51898
git-svn-id: http://core.svn.wordpress.org/trunk@51491 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
“The WordPress open source community cares about diversity. We strive to maintain a welcoming environment where everyone can feel included.”
With this commit, all occurrences of “whitelist” and “blacklist” (with the single exception of the `$new_whitelist_options` global variable) are removed. A new ticket has been opened to explore renaming the `$new_whitelist_options` variable (#50434).
Changing to more specific names or rewording sentences containing these terms not only makes the code more inclusive, but also helps provide clarity. These terms are often ambiguous. What is being blocked or allowed is not always immediately clear. This can make it more difficult for non-native English speakers to read through the codebase.
Words matter. If one contributor feels more welcome because these terms are removed, this was worth the effort.
Props strangerstudios, jorbin, desrosj, joemcgill, timothyblynjacobs, ocean90, ayeshrajans, davidbaumwald, earnjam.
See #48900, #50434.
Fixes#50413.
Built from https://develop.svn.wordpress.org/trunk@48121
git-svn-id: http://core.svn.wordpress.org/trunk@47890 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This ensures that if the limit has been modified for admin screens by `wp_raise_memory_limit()`, the original value is displayed along with the current value.
Props Clorith, espiat, zodiac1978, SergeyBiryukov.
Fixes#49329.
Built from https://develop.svn.wordpress.org/trunk@47762
git-svn-id: http://core.svn.wordpress.org/trunk@47538 1a063a9b-81f0-0310-95a4-ce76da25c4cd
PHP sessions created by a `session_start()` function call may interfere with REST API and loopback requests.
An active session should be closed by `session_write_close()` before making any HTTP requests.
Props matthieumota, netweblogic, Clorith, afragen, vjik, SergeyBiryukov.
Fixes#47320.
Built from https://develop.svn.wordpress.org/trunk@47585
git-svn-id: http://core.svn.wordpress.org/trunk@47360 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These tests output an unordered list, which doesn't need to be wrapped in a paragraph tag.
Additionally, pass an empty string as an `actions` parameter in `::get_test_php_default_timezone()`, for consistency with other tests.
Props afercia.
See #48948.
Built from https://develop.svn.wordpress.org/trunk@47528
git-svn-id: http://core.svn.wordpress.org/trunk@47303 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change fixes an issue where the error codes associated with failed REST API tests are not being printed to the screen. In addition, the square brackets have been replaced with parentheses for consistency, and the error code (which is much less useful to end-users than the error message itself) has been moved to the end of the line.
This also clarifies the associated translator comments.
Props afercia, desrosj.
Fixes#49426.
Built from https://develop.svn.wordpress.org/trunk@47306
git-svn-id: http://core.svn.wordpress.org/trunk@47106 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids the performance overhead of the function call every time `dirname( __FILE__ )` was used instead of `__DIR__`.
This commit also includes:
* Removing unnecessary parentheses from `include`/`require` statements. These are language constructs, not function calls.
* Replacing `include` statements for several files with `require_once`, for consistency:
* `wp-admin/admin-header.php`
* `wp-admin/admin-footer.php`
* `wp-includes/version.php`
Props ayeshrajans, desrosj, valentinbora, jrf, joostdevalk, netweb.
Fixes#48082.
Built from https://develop.svn.wordpress.org/trunk@47198
git-svn-id: http://core.svn.wordpress.org/trunk@46998 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The widget informs administrators of any potential issues that should be addressed to improve the performance or security of their website, and directs them to the Site Health screen for more details.
Props Clorith, hedgefield, guddu1315.
See #47606.
Built from https://develop.svn.wordpress.org/trunk@47063
git-svn-id: http://core.svn.wordpress.org/trunk@46863 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The test reports a failure if the default timezone was changed with `date_default_timezone_set()` to anything other than `UTC`.
WordPress historically uses `UTC` as the default timezone for calculating date and time offsets, overriding it is not recommended and can cause widespread and obscure issues.
Props Rarst, Clorith, TimothyBlynJacobs.
Fixes#48692.
Built from https://develop.svn.wordpress.org/trunk@46797
git-svn-id: http://core.svn.wordpress.org/trunk@46597 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change introduces a new Composer script, `compat` that will scan the codebase for (detectable) potential PHP compatibility issues using the `PHP_CodeSniffer` and a custom ruleset based off of the `PHPCompayibilityWP` ruleset (`phpcompat.xml.dist`).
The command will be run as a separate job within each Travis build. While many compatibility issues and false positives have already been corrected in this commit and other Trac tickets, there are still some remaining. For that reason, the job is allowed to fail while the remainder of the potential compatibility issues are investigated and addressed. After those are resolved, the job should be set as required to pass to help prevent new compatibility issues from being introduced.
Props desrosj, jrf, all PHPCompatibilityWP and PHPCompatibility contributors.
Fixes#46152.
Built from https://develop.svn.wordpress.org/trunk@46290
git-svn-id: http://core.svn.wordpress.org/trunk@46102 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The SSL certificate may be self-signed which prevents various tests from returning proper results. Since the Cron API and file editors don't verify the certificate the tests shouldn't either.
Props Clorith, ocean90.
Fixes#47957.
Built from https://develop.svn.wordpress.org/trunk@46231
git-svn-id: http://core.svn.wordpress.org/trunk@46043 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces `WP_Site_Health::has_late_cron()` for late wp-cron jobs and extends the time allowance before a job is considered missed.
In a standard configuration using loopback requests, a job is considered late once past due and missed over five minutes past due.
Late and missed time frames are extended if `DISABLE_WP_CRON` is defined as `true` to allow for crontab tasks running less frequently. A job is considered late once it's 15 minutes past due and missed over one hour past due.
A file for site health unit tests has been introduced with tests for cron in critical, late and missed states.
Props rockfire, afragen, peterwilsoncc.
Fixes#47223.
Built from https://develop.svn.wordpress.org/trunk@45801
git-svn-id: http://core.svn.wordpress.org/trunk@45612 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change removes redundant CSS properties for different health check statuses in favor of utilizing the `.dashicons` class already in Core to define them more consistently. This also fixes the vertical alignment issues.
Props chetan200891, Clorith, desrosj.
Fixes#46940.
Built from https://develop.svn.wordpress.org/trunk@45309
git-svn-id: http://core.svn.wordpress.org/trunk@45120 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When viewing Site Health for a multisite install, there are a few recommendations that are not appropriate and could have negative implications for other sites on the install if the administrator follows the advice provided.
For example, Site Health recommends that inactive plugins and themes for a site should be removed. On a single site install, this is a great recommendation. However, on a multisite install, inactive plugins and themes for one site should not be removed because they could be active for other sites on the network.
This change also disables the `test_wp_version_check_attached()` test for multisite. This test checks for the presence of the `wp_version_check()` function on the `wp_version_check` hook, which is not present for every site on multisite.
Reviewed by jeremyfelt and desrosj.
Props iandunn, Clorith, azaozz, jeremyfelt.
Fixes#47084.
Built from https://develop.svn.wordpress.org/trunk@45275
git-svn-id: http://core.svn.wordpress.org/trunk@45084 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change adds missing actions for several tests. This ensures that the user is provided with a next step, whenever possible.
Also, change the URL displayed in the WordPress.org communication test description to `api.wordpress.org` for accuracy.
Props: garrett-eclipse, Clorith, vaishalipanchal.
Fixes#46734.
Built from https://develop.svn.wordpress.org/trunk@45170
git-svn-id: http://core.svn.wordpress.org/trunk@44979 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Sergey Biryukov
hellofromTonya
John Blackbourn
Clorith
Peter Wilson
Felix Arntz
whyisjake
TimothyBlynJacobs
desrosj
Dominik Schilling
Andrew Ozz