Introduced [52836] when passing `child_of` or `pad_counts` parameters to `get_terms` or `WP_Term_Query` class, the array of terms received by the query, was not correctly cached. This
change simplifies the logic in `WP_Term_Query` and ensures terms are correctly cached. This change also, improves performance, by only caching an array of term ids where possible.
Props denishua, spacedmonkey, oztaser, peterwilsoncc, SergeyBiryukov, georgestephanis, jnz31, knutsp, mukesh27, costdev.
Fixes#55837.
git-svn-id: https://develop.svn.wordpress.org/trunk@53496 602fd350-edb4-49c9-b593-d223f7449a82
[51916] fixed a bug where `array( `false` )` was added to the cron array when `_get_cron_array()` returned `false`.
This commit:
* Removes any `false` values from the cron array when upgrading to 5.9+.
* Bumps the database version.
Follow-up to [44917], [51916].
Props peterwilsoncc, jrf.
See #53950.
git-svn-id: https://develop.svn.wordpress.org/trunk@51917 602fd350-edb4-49c9-b593-d223f7449a82
In addition to holding the version number, the WordPress version string is used to bust caches and to enable development mode for scripts when running from the `/src` directory.
Follow-up to [803], [2585], [6554], [47230].
Props muhammadfaizanhaidar, azaozz.
Fixes#53413.
git-svn-id: https://develop.svn.wordpress.org/trunk@51809 602fd350-edb4-49c9-b593-d223f7449a82
Application Passwords uses Basic Authentication to transfer authentication details. If the site is already using Basic Auth, for instance to implement a private staging environment, then the REST API will treat this as an authentication attempt and would end up generating an error for any REST API request.
Now, Application Password authentication will only be attempted if Application Passwords is in use by a site. This is flagged by setting an option whenever an Application Password is created. An upgrade routine is added to set this option if any App Passwords already exist.
Lastly, creating an Application Password will be prevented if the site appears to already be using Basic Authentication.
Props chexwarrior, georgestephanis, adamsilverstein, helen, Clorith, marybaum, TimothyBlynJacobs.
Fixes#51939.
git-svn-id: https://develop.svn.wordpress.org/trunk@49752 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@49744 602fd350-edb4-49c9-b593-d223f7449a82
