The `wp_privacy_anonymize_ip()` function expects a string for the `$ip_addr` parameter, but did not do any input validation.
One of the pre-existing test cases, passed `null` to the function, leading to a `substr_count(): Passing null to parameter #1 ($haystack) of type string is deprecated` notice on PHP 8.1.
Fixed now by doing a cursory check on the variable at the start of the function and bowing out early for a number of cases (`null`, `false`, `0`, `''`) which would all result in the same `0.0.0.0` output anyway.
Follow-up [42971].
Props jrf, hellofromTonya.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51793
git-svn-id: http://core.svn.wordpress.org/trunk@51400 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes a `preg_match_all(): Passing null to parameter #2 ($subject) of type string is deprecated` notice on PHP 8.1.
The behavior for `null` and `string` input is covered by the existing `Tests_Functions::test_validate_file()` test.
Effect: Errors down by 238, assertions up by 1920, failures down by 1.
Props jrf, hellofromTonya, SergeyBiryukov.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51625
git-svn-id: http://core.svn.wordpress.org/trunk@51231 1a063a9b-81f0-0310-95a4-ce76da25c4cd
r51211 accidentally introduced a fatal error for Multisite instances with `ms_files_rewriting` enabled. Reverting removes the error, and the original purpose of the commit can be solved in another way.
Props otto42, barry, ryelle, azaozz.
Fixes#53492. See #53475.
Built from https://develop.svn.wordpress.org/trunk@51223
git-svn-id: http://core.svn.wordpress.org/trunk@50832 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Update the function DocBlock per the documentation standards.
* Move the unit tests to a more appropriate place.
* Rename and reorder the tests for consistency with `_wp_array_get()` tests.
Follow-up to [50958], [50962], [50964].
See #53175, #52625.
Built from https://develop.svn.wordpress.org/trunk@50965
git-svn-id: http://core.svn.wordpress.org/trunk@50574 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As a result of the recent changes, both functions were calling each other if the `exif` PHP extension is not available.
The issue is now resolved by calling the `getimagesize()` PHP function directly, instead of the `wp_getimagesize()` wrapper.
Follow-up to [50146], [50810], [50814], [50815], [50818-50821].
See #35725.
Built from https://develop.svn.wordpress.org/trunk@50822
git-svn-id: http://core.svn.wordpress.org/trunk@50431 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Document that WebP constants are only defined in PHP 7.1+.
* Correct the `$filename` parameter type in `wp_get_webp_info()`.
* Use a consistent message when skipping tests due to the lack of WebP support.
* Remove unnecessary `else` branches after `markTestSkipped()`.
* Replace `assertEquals()` with more appropriate assertions.
Follow-up to [50810].
See #35725.
Built from https://develop.svn.wordpress.org/trunk@50814
git-svn-id: http://core.svn.wordpress.org/trunk@50423 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add support for uploading, editing and saving WebP images when supported by the server.
Add 'image/webp' to supported mime types. Correctly identify WebP images and sizes even when PHP doesn't support WebP. Resize uploaded WebP files (when supported) and use for front end markup.
Props markoheijne, blobfolio, Clorith, joemcgill, atjn, desrosj, spacedmonkey, marylauc, mikeschroder, hellofromtonya, flixos90.
Fixes#35725.
Built from https://develop.svn.wordpress.org/trunk@50810
git-svn-id: http://core.svn.wordpress.org/trunk@50419 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Move `wp_get_script_tag()`, `wp_print_script_tag()`, `wp_print_inline_script_tag()` and `wp_get_inline_script_tag()` functions from `functions.php` to `script-loader.php`.
Relocate related tests to `dependencies` sub-directory.
Follow up to [50167].
Props adamsilverstein, hellofromTonya, SergeyBiryukov.
Fixes#39941.
Built from https://develop.svn.wordpress.org/trunk@50409
git-svn-id: http://core.svn.wordpress.org/trunk@50020 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add new functions `wp_get_script_tag`, `wp_print_script_tag`, `wp_print_inline_script_tag` and `wp_get_inline_script_tag` that support script attributes. Enables passing attributes such as `async` or `nonce`, creating a path forward for enabling a Content-Security-Policy in core, plugins and themes.
Props tomdxw, johnbillion, jadeddragoon, jrchamp, mallorydxw, epicfaace, alinod, enricocarraro, ocean90.
Fixes#39941.
Built from https://develop.svn.wordpress.org/trunk@50167
git-svn-id: http://core.svn.wordpress.org/trunk@49846 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, all logic utilizing `getimagesize()` was supressing errors making it difficult to debug usage of the function.
A new `wp_getimagesize()` function has been added to allow the errors to no longer be suppressed when `WP_DEBUG` is enabled.
Props Howdy_McGee, SergeyBiryukov, mukesh27, davidbaumwald, noisysocks, hellofromTonya.
Fixes#49889.
Built from https://develop.svn.wordpress.org/trunk@50146
git-svn-id: http://core.svn.wordpress.org/trunk@49825 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
Add a feature so Admins can send users a 'password reset' email. This doesn't change the password or force a password change. It only emails the user the password reset link.
The feature appears in several places:
* A "Send Reset Link" button on user profile screen.
* A "Send password reset" option in the user list bulk action dropdown.
* A "Send password reset" quick action when hovering over a username in the user list.
Props Ipstenu, DrewAPicture, eventualo, wonderboymusic, knutsp, ericlewis, afercia, JoshuaWold, johnbillion, paaljoachim, hedgefield.
Fixes#34281.
Built from https://develop.svn.wordpress.org/trunk@50129
git-svn-id: http://core.svn.wordpress.org/trunk@49808 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces a filter-based Robots API, providing central control over the `robots` meta tag.
* Introduces `wp_robots()` function which should be called anywhere a `robots` meta tag should be included.
* Introduces `wp_robots` filter which allows adding or modifying directives for the `robots` meta tag. The `wp_robots()` function is entirely filter-based, i.e. if no filter is added to `wp_robots`, no directives will be present, and therefore the entire `robots` meta tag will be omitted.
* Introduces the following `wp_robots` filter functions which replace similar existing functions that were manually rendering a `robots` meta tag:
* `wp_robots_noindex()` replaces `noindex()`, which has been deprecated.
* `wp_robots_no_robots()` replaces `wp_no_robots()`, which has been deprecated.
* `wp_robots_sensitive_page()` replaces `wp_sensitive_page_meta()`, which has been deprecated. Its rendering of the `referrer` meta tag has been moved to another new function `wp_strict_cross_origin_referrer()`.
Migration to the new functions is straightforward. For example, a call to `add_action( 'wp_head', 'wp_no_robots' )` should be replaced with `add_filter( 'wp_robots', 'wp_robots_no_robots' )`.
Plugins and themes that render their own `robots` meta tags are encouraged to switch to rely on the `wp_robots` filter in order to use the central management layer now provided by WordPress core.
Props adamsilverstein, flixos90, timothyblynjacobs, westonruter.
See #51511.
Built from https://develop.svn.wordpress.org/trunk@49992
git-svn-id: http://core.svn.wordpress.org/trunk@49693 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This brings the accessibility improvements previously made for other areas of the admin in WordPress 5.3 to the installation screens too.
Follow-up to [46241-46244], [46247], [46248], [46293], [46425].
Props Maigret, audrasjb.
Fixes#51854.
Built from https://develop.svn.wordpress.org/trunk@49907
git-svn-id: http://core.svn.wordpress.org/trunk@49606 1a063a9b-81f0-0310-95a4-ce76da25c4cd
r49212 greatly improved the performance of `get_dirsize()`, but also changed the structure of the data stored in the `dirsize_cache` transient. It stored relative paths instead of absolute ones, and also removed the unnecessary `size` array.
That difference in data structures led to a fatal error in the following environment:
* PHP 8
* Multisite
* A custom `WP_CONTENT_DIR` which is not a child of WP's `ABSPATH` folder (e.g., [https://roots.io/bedrock/ Bedrock])
* The `upload_space_check_disabled` option set to `0`
After upgrading to WP 5.6, the `dirsize_cache` transient still had data in the old format. When `wp-admin.php/index.php` was visited, `get_space_used()` received an `array` instead of an `int`, and tried to divide it by another `int`. PHP 7 would silently cast the arguments to match data types, but [https://wiki.php.net/rfc/arithmetic_operator_type_checks PHP 8 throws a fatal error]:
`Uncaught TypeError: Unsupported operand types: array / int`
`recurse_dirsize()` was using `ABSPATH` to convert the absolute paths to relative ones, but some upload locations are not located under `ABSPATH`. In those cases, `$directory` and `$cache_path` were identical, and that triggered the early return of the old `array`, instead of the expected `int`.
In order to avoid that, this commit restores the absolute paths, but without the `size` array. It also adds a type check when returning cached values. Using absolute paths without `size` has the result of overwriting the old data, so that it matches the new format. The type check and upgrade routine are additional safety measures.
Props peterwilsoncc, janthiel, helen, hellofromtonya, francina, pbiron.
Fixes#51913. See #19879.
Built from https://develop.svn.wordpress.org/trunk@49744
git-svn-id: http://core.svn.wordpress.org/trunk@49467 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Clarifies that if you are on maintenance/security auto-updates that you are only on those and therefore there are more options available.
* Adds a message if a version control system has been detected, as automatic updates are disabled in that case.
* Ensures only one heading between `update available`, `you are on a dev version`, and `you are on latest` appears at any given time, falling back to `you are on latest` if something strange happens with the returned update data.
* Removes some older strings related to auto-updates, which greatly simplifies the above.
* Strips the `core-major-auto-updates-saved` query arg from the URL, as it is related to a dismissible notice.
Props audrasjb, pbiron, helen.
Fixes#51742.
Built from https://develop.svn.wordpress.org/trunk@49638
git-svn-id: http://core.svn.wordpress.org/trunk@49376 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If reinstalling WordPress, there is a condition where tables would exist in the database. Ensures that when that is the case, the install process can carry along without issue.
Fixes#51676.
Props xknown, garubi, mukesh27, desrosj, johnbillion, metalandcoffee, davidbaumwald, whyisjake.
Built from https://develop.svn.wordpress.org/trunk@49452
git-svn-id: http://core.svn.wordpress.org/trunk@49211 1a063a9b-81f0-0310-95a4-ce76da25c4cd
hellofromTonya
Sergey Biryukov
desrosj
Andrew Ozz
gziolo
John Blackbourn
iandunn
jorgefilipecosta
youknowriad
Adam Silverstein
Peter Wilson
antpb
Felix Arntz
whyisjake
Helen Hou-Sandí