`str_contains()` was introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) contains the given substring (needle).
WordPress core includes a polyfill for `str_contains()` on PHP < 8.0 as of WordPress 5.9.
This commit replaces `false !== strpos( ... )` with `str_contains()` in core files, making the code more readable and consistent, as well as better aligned with modern development practices.
Follow-up to [52039], [52040], [52326], [55703], [55710], [55987].
Props Soean, spacedmonkey, costdev, dingo_d, azaozz, mikeschroder, flixos90, peterwilsoncc, SergeyBiryukov.
Fixes#58206.
Built from https://develop.svn.wordpress.org/trunk@55988
git-svn-id: http://core.svn.wordpress.org/trunk@55500 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 backup kept in the temporary 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 `upgrade-temp-backup` directory is writable.
* A check that there is enough disk space available to safely perform updates.
To avoid confusion: The temporary 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.
Follow-up to [55204], [55220].
Props afragen, costdev, pbiron, azaozz, hellofromTonya, aristath, peterwilsoncc, TJNowell, bronsonquick, Clorith, dd32, poena, TimothyBlynJacobs, audrasjb, mikeschroder, a2hosting, KZeni, galbaras, richards1052, Boniu91, mai21, francina, TobiasBg, desrosj, noisysocks, johnbillion, dlh, chaion07, davidbaumwald, jrf, thisisyeasin, ignatggeorgiev, SergeyBiryukov.
Fixes#51857.
Built from https://develop.svn.wordpress.org/trunk@55720
git-svn-id: http://core.svn.wordpress.org/trunk@55232 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`str_starts_with()` was introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) begins with the given substring (needle).
WordPress core includes a polyfill for `str_starts_with()` on PHP < 8.0 as of WordPress 5.9.
This commit replaces `0 === strpos( ... )` with `str_starts_with()` in core files, making the code more readable and consistent, as well as improving performance.
While `strpos()` is slightly faster than the polyfill on PHP < 8.0, `str_starts_with()` is noticeably faster on PHP 8.0+, as it is optimized to avoid unnecessarily searching along the whole haystack if it does not find the needle.
Follow-up to [52039], [52040], [52326].
Props spacedmonkey, costdev, sabernhardt, mukesh27, desrosj, jorbin, TobiasBg, ayeshrajans, lgadzhev, SergeyBiryukov.
Fixes#58012.
Built from https://develop.svn.wordpress.org/trunk@55703
git-svn-id: http://core.svn.wordpress.org/trunk@55215 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This aims to provide better context for translators and make it easier to determine that some strings contain hidden accessibility text and are not displayed in the UI.
Props kebbet, mercime, pavelevap, ocean90, swissspidy, Chouby, jipmoors, afercia, desrosj, costdev, audrasjb, SergeyBiryukov.
Fixes#29748.
Built from https://develop.svn.wordpress.org/trunk@55276
git-svn-id: http://core.svn.wordpress.org/trunk@54809 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since `ABSPATH` is defined and documented to end with a forward slash `/`, this changeset removes the first `/` from strings appended to `ABSPATH` in various files, leading to `//` in the resulting path.
Props TobiasBg, audrasjb, SergeyBiryukov, emanuelx.
Fixes#57074.
See #57071.
Built from https://develop.svn.wordpress.org/trunk@54872
git-svn-id: http://core.svn.wordpress.org/trunk@54424 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The descriptions provided whenever a REST API check failed lacked details that would help in troubleshooting any issues, most notably the actual REST API endpoint that was being tested.
Adding this vital piece of detail, along with a revamp of the error messages shown, where previously there was a risk that the markup of your website was included as an error message, improves the overall user experience, and gives more accurate details that can be looked when looking up how to fix or improve the behavior of the REST API.
Props dingo_d, shetheliving.
Fixes#54617.
Built from https://develop.svn.wordpress.org/trunk@54205
git-svn-id: http://core.svn.wordpress.org/trunk@53764 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously the description left the user stuck with no path forward if flushing their permalinks was not enough.
This change givers a clearer description of what approving an application may involve (allowing these to connect to the users site), but also an additional step towards resolution if flushing permalinks are not enough; pointing them towards their host.
Props Presskopp, webcommsat.
Fixes#54508.
Built from https://develop.svn.wordpress.org/trunk@54196
git-svn-id: http://core.svn.wordpress.org/trunk@53755 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Add a check to `wp_check_php_version()` whether the current PHP version is lower than the next (desired) minimum version.
- Set the next desired minimum PHP version to 7.2.
- Use that check to update the warnings in the `wp_dashboard_php_nag()` widget, and on the Site Health screen.
Props Clorith, SergeyBiryukov, ironprogrammer, azaozz.
See #56199.
Built from https://develop.svn.wordpress.org/trunk@54169
git-svn-id: http://core.svn.wordpress.org/trunk@53728 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0.
There are a number of ways to mitigate this:
* If it is an accidental typo for a declared property: fix the typo.
* For known properties: declare them on the class.
* For unknown properties: add the magic `__get()`, `__set()`, et al. methods to the class or let the class extend `stdClass` which has highly optimized versions of these magic methods built in.
* For unknown ''use'' of dynamic properties, the `#[AllowDynamicProperties]` attribute can be added to the class. The attribute will automatically be inherited by child classes.
Trac ticket #56034 is open to investigate and handle the third and fourth type of situations, however it has become clear this will need more time and will not be ready in time for WP 6.1.
To reduce “noise” in the meantime, both in the error logs of WP users moving onto PHP 8.2, in the test run logs of WP itself, in test runs of plugins and themes, as well as to prevent duplicate tickets from being opened for the same issue, this commit adds the `#[AllowDynamicProperties]` attribute to all “parent” classes in WP.
The logic used for this commit is as follows:
* If a class already has the attribute: no action needed.
* If a class does not `extend`: add the attribute.
* If a class does `extend`:
- If it extends `stdClass`: no action needed (as `stdClass` supports dynamic properties).
- If it extends a PHP native class: add the attribute.
- If it extends a class from one of WP's external dependencies: add the attribute.
* In all other cases: no action — the attribute should not be needed as child classes inherit from the parent.
Whether or not a class contains magic methods has not been taken into account, as a review of the currently existing magic methods has shown that those are generally not sturdy enough and often even set dynamic properties (which they should not). See the [https://www.youtube.com/watch?v=vDZWepDQQVE live stream from August 16, 2022] for more details.
This commit only affects classes in the `src` directory of WordPress core.
* Tests should not get this attribute, but should be fixed to not use dynamic properties instead. Patches for this are already being committed under ticket #56033.
* While a number bundled themes (2014, 2019, 2020, 2021) contain classes, they are not a part of this commit and may be updated separately.
Reference: [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties].
Follow-up to [53922].
Props jrf, hellofromTonya, markjaquith, peterwilsoncc, costdev, knutsp, aristath.
See #56513, #56034.
Built from https://develop.svn.wordpress.org/trunk@54133
git-svn-id: http://core.svn.wordpress.org/trunk@53692 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset implements a clearer and more consistent timeout/duration/expiration format. It updates time durations used in various files, as per WordPress coding standards:
- If the value can be represented as an integer (not a fractional) number of minutes (hours, etc.), use the appropriate constant (e.g.: `MINUTE_IN_SECONDS`) multiplied by that number.
- Otherwise, keep the value as is and add a comment with the units for clarity.
Follow-up to [11823], [13177], [21996], [37747], [53714].
Props hztyfoon, audrasjb, arrasel403, krupalpanchal, GaryJ, SergeyBiryukov, peterwilsoncc, rudlinkon, costdev, robinwpdeveloper.
Fixes#56293.
See #55647.
Built from https://develop.svn.wordpress.org/trunk@54113
git-svn-id: http://core.svn.wordpress.org/trunk@53672 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* MySQL 5.6 has reached EOL (“End of Life”) in February 2021. The recommended minimum is bumped to 5.7 for now.
* MariaDB 10.2 has reached EOL in May 2022. The recommended minimum is bumped to 10.3 for now.
This commit brings the Site Health recommendations in line with `readme.html`.
Includes:
* Adding two unit tests to ensure the SQL server versions recommended by Site Health match `readme.html`.
* Consistently declaring the recommended and required versions as the `WP_Site_Health` class properties.
* Renaming some pre-existing private properties for clarity.
Follow-up to [44986], [52319], [52358], [52420], [52424], [53431], [53433], [53435], [meta11407], [meta11866].
See #55791, #meta5999, #meta6322.
Built from https://develop.svn.wordpress.org/trunk@54069
git-svn-id: http://core.svn.wordpress.org/trunk@53628 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This updates an older fragment in `WP_Site_Health::prepare_sql_data()` to use a dedicated `$wpdb` method introduced later in WordPress 5.5 specifically for retrieving the database server information.
Follow-up to [44986], [47451].
Props hilayt24, mukesh27, Clorith, SergeyBiryukov.
Fixes#56484.
Built from https://develop.svn.wordpress.org/trunk@54065
git-svn-id: http://core.svn.wordpress.org/trunk@53624 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Add a `@coversDefaultClass` annotation to address `@covers ::get_test_page_cache" is invalid` notices.
* Rename data providers to start with the `data_` prefix and match the test method names, for consistency.
* Move data providers next to the test methods they are used in.
* Move `::get_test_page_cache()` closer to `::get_test_persistent_object_cache()`, for a bit more predictable placement.
* Fix a typo in `::get_test_persistent_object_cache()` description.
Follow-up to [53955], [54043], [54044], [54045].
See #56041.
Built from https://develop.svn.wordpress.org/trunk@54047
git-svn-id: http://core.svn.wordpress.org/trunk@53606 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Includes:
* Moving leading and trailing spaces out of a translatable string.
* Using the established format for translator comments.
* Using a consistent typography for the apostrophe.
Follow-up to [53955], [54043].
See #56041.
Built from https://develop.svn.wordpress.org/trunk@54044
git-svn-id: http://core.svn.wordpress.org/trunk@53603 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset adds a new `page_cache` check which determines whether the site uses a full page cache, and in addition assesses the server response time. If no page cache is present and the server response time is slow, the check will suggest use of a page cache.
A few filters are included for customization of the check:
* `site_status_good_response_time_threshold` filters the number of milliseconds below which the server response time is considered good. The default value is based on the `server-response-time` Lighthouse audit and can be altered using this filter.
* `site_status_page_cache_supported_cache_headers` filters the map of supported cache headers and their callback to determine whether it was a cache hit. The default list includes commonly used cache headers, and it is filterable to support e.g. additional cache headers used by specific vendors.
Note that due to the nature of this check it is only run in production environments.
Props furi3r, westonruter, spacedmonkey, swissspidy, Clorith.
Fixes#56041.
Built from https://develop.svn.wordpress.org/trunk@54043
git-svn-id: http://core.svn.wordpress.org/trunk@53602 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset adds a new `persistent_object_cache` check which determines whether the site uses a persistent object cache, and if not, recommends it if it is beneficial for the site. A support resource to learn more about object caching has been created and is linked in the check.
A few filters are included for customization of the check, aimed primarily at hosting providers to provide more specific information in regards to their environment:
* `site_status_persistent_object_cache_url` filters the URL to learn more about object caching, so that e.g. a hosting-specific object caching support resource could be linked.
* `site_status_persistent_object_cache_notes` filters the notes added to the check description, so that more fine tuned information on object caching based on the environment can be provided.
* `site_status_should_suggest_persistent_object_cache` is a short-circuit filter which allows using entirely custom logic to determine whether a persistent object cache would make sense for the site.
* `site_status_persistent_object_cache_thresholds` filters the thresholds in the default logic to determine whether a persistent object cache would make sense for the site, which is based on the amount of data in the database.
Note that due to the nature of this check it is only run in production environments.
Props furi3r, tillkruss, spacedmonkey, audrasjb, Clorith.
Fixes#56040.
Built from https://develop.svn.wordpress.org/trunk@53955
git-svn-id: http://core.svn.wordpress.org/trunk@53514 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes WPCS errors in `WP_Site_Health::get_test_plugin_version()` and `::get_test_theme_version()`:
* `Expected exactly one space between closing parenthesis and opening control structure; " " found.`
* `Expected 1 space(s) after closing parenthesis; found 2`
Follow-up to [53816].
See #56134.
Built from https://develop.svn.wordpress.org/trunk@53817
git-svn-id: http://core.svn.wordpress.org/trunk@53376 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This displays a more appropriate message in case the site does not have any active plugins or installed themes.
Follow-up to [44986], [45099], [45336].
Props Presskopp, costdev, martin.krcho, Clorith, SergeyBiryukov.
Fixes#56134.
Built from https://develop.svn.wordpress.org/trunk@53816
git-svn-id: http://core.svn.wordpress.org/trunk@53375 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While using reserved PHP keywords as parameter name labels is allowed, in the context of function calls using named parameters in PHP 8.0+, this will easily lead to confusion. To avoid that, it is recommended not to use reserved keywords as function parameter names.
This commit:
* Renames the `$class` parameter to `$class_name` in `WP_Site_Health::test_php_extension_availability()`.
* Renames some other parameters for consistency.
Follow-up to [52946], [52996], [52997], [52998], [53003], [53014], [53029], [53039], [53116].
Props jrf, aristath, poena, justinahinon, SergeyBiryukov.
See #55327.
Built from https://develop.svn.wordpress.org/trunk@53117
git-svn-id: http://core.svn.wordpress.org/trunk@52706 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset replaces contracted verb forms like `doesn't`, `can't`, or `isn't` with non-contracted forms like `does not`, `cannot`, or `is not`, for better consistency across the WordPress administration. It also updates some corresponding unit tests strings.
Props Presskopp, socalchristina, aandrewdixon, francina, SergeyBiryukov, JeffPaul, audrasjb, hellofromTonya.
Fixes#38913.
See #39176.
Built from https://develop.svn.wordpress.org/trunk@52978
git-svn-id: http://core.svn.wordpress.org/trunk@52567 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Revert the rollback features introduced for theme and plugin upgrades during the WordPress 5.9 cycle. A bug (suspected to be in third party virtualisation software) causes the upgrades to fail consistently on some set ups. The revert is to allow contributors further time to investigate mitigation options.
Reverts [52337], [52289], [52284], [51951], [52192], [51902], [51899], [51898], [51815].
Props pbiron, dlh, peterwilsoncc, galbaras, SergeyBiryukov, afragen, costdev, bronsonquick, aristath, noisysocks, desrosj, TobiasBg, hellofromTonya, francina, Boniu91.
See #54543, #54166, #51857.
Built from https://develop.svn.wordpress.org/trunk@52351
git-svn-id: http://core.svn.wordpress.org/trunk@51943 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changes some admin-area, user-facing text, to better match the guidelines and recommendations set forth in the make/core handbook, specifically:
> the word “we” should be avoided (...) unless its made very clear which group is speaking
(There are several more usages of "we" that will receive this same scrutiny in future commits/releases.)
Props audrasjb, johnbillion, marybaum, peterwilsoncc, sergeybiryukov, shital-patel.
Fixes #46057.
Built from https://develop.svn.wordpress.org/trunk@51979
git-svn-id: http://core.svn.wordpress.org/trunk@51568 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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