Per the documentation standards, the `@global` tag is meant to list PHP globals used within functions or methods.
The code in question uses the variable in global namespace, but does not explicitly declare it.
Props jayupadhyay01, dswebsme.
Fixes#46602.
git-svn-id: https://develop.svn.wordpress.org/trunk@45233 602fd350-edb4-49c9-b593-d223f7449a82
These keys are used in `{$type}_template_hierarchy` and `{$type}_template` filters.
Previously, `front_page` and `privacy_policy` were passed, but `get_query_template()` stripped the underscores before passing the values to the filters.
Props rinatkhaziev, tmatsuur, johnbillion.
Fixes#21213, #46958.
git-svn-id: https://develop.svn.wordpress.org/trunk@45231 602fd350-edb4-49c9-b593-d223f7449a82
Also, restores the keyboard interaction behavior prior to [41988] by requesting one single Enter key press to add a tag.
Props ryanshoover, miyauchi.
Fixes#45371.
git-svn-id: https://develop.svn.wordpress.org/trunk@45227 602fd350-edb4-49c9-b593-d223f7449a82
Currently, there are a number of scenarios where `is_block_editor()` (and `WP_Screen::is_block_editor`) would incorrectly indicate block editor support at different points of the loading process. Most notably, checking `is_block_editor` when hooking into the `current_screen` action will always result in `false`, even when the block editor is being loaded. This is because `is_block_editor` is not set to `true` until `edit-form-blocks.php` is included.
This change adds logic to `WP_Screen` to ensure the accuracy of `is_block_editor` on block editor pages earlier in the load process.
While edit screens will now be accurate 100% of the time from `current_screen` on, there are still a few edge cases where `is_block_editor` could contain an incorrect value when creating a new post.
Because a `WP_Post` object is a required parameter for the `replace_editor` filter and `use_block_editor_for_post()` function, `WP_Screen` will fall back to the value returned by `use_block_editor_for_post_type()` for the post being created. To eliminate these edge cases, the `use_block_editor_for_post_type` filter can be used to return the appropriate boolean value to indicate support.
Props Chouby, desrosj, aduth, johnbillion.
Fixes#46195.
git-svn-id: https://develop.svn.wordpress.org/trunk@45224 602fd350-edb4-49c9-b593-d223f7449a82
- Change `recurse_dirsize()` to accept an array of excluded paths.
- Change so we don't calculate the sizes of dirs in wp-content twice.
- Add the size in bytes to the "debug" into.
- Add a custom DOM event after the dir sizes request is done. Can be used by plugins to "daisy chain" more requests.
- Move "WordPress directory location" and "WordPress directory size" to the top in the "Directories and Sizes" section.
- Move "Theme directory location" to the "Active Theme" section.
- Fix labels capitalization.
Props xkon, afercia, Clorith, azaozz.
Fixes#46707.
git-svn-id: https://develop.svn.wordpress.org/trunk@45220 602fd350-edb4-49c9-b593-d223f7449a82
Address an issue since r44947 where calling `wp_enqueue_media` on the front-end would result in a PHP fatal.
Props david.binda.
Fixes#46795.
git-svn-id: https://develop.svn.wordpress.org/trunk@45219 602fd350-edb4-49c9-b593-d223f7449a82
For many bundled theme related stylesheets, a version is either not specified, or specified as a hardcoded date string when enqueued. This is problematic when a stylesheet is updated and the version number is not (which has happened several times recently). This change ensures that all bundled theme related stylesheets use the theme’s version as the stylesheet version. This ensures cache busting for theme stylesheets every time a theme is updated and guarantees that users receive any new or updated styles included in the update when visiting the site for the first time after an update.
Props parsmizban, ianbelanger, dswebsme.
Fixes#39997.
git-svn-id: https://develop.svn.wordpress.org/trunk@45213 602fd350-edb4-49c9-b593-d223f7449a82
In [28693], the Genericons stylesheet was updated to `3.0.3`, but the version was incorrectly indicated as `3.03`.
See #39997.
git-svn-id: https://develop.svn.wordpress.org/trunk@45212 602fd350-edb4-49c9-b593-d223f7449a82
While currently a recovery link is only made available via the admin email address, this will be expanded in the future. In order to accomplish that, the mechanisms to store and validate recovery keys must support multiple keys to be valid at the same time.
This changeset adds that support, adding an additional token parameter which is part of a recovery link in addition to the key. A key itself is always associated with a token, so the two are only valid in combination. These associations are stored in a new `recovery_keys` option, which is regularly cleared in a new Cron hook, to prevent potential cluttering from unused recovery keys.
This changeset does not have any user-facing implications otherwise.
Props pbearne, timothyblynjacobs.
Fixes#46595. See #46130.
git-svn-id: https://develop.svn.wordpress.org/trunk@45211 602fd350-edb4-49c9-b593-d223f7449a82
This ensures that at least for the admin, which is more predictable than the frontend, the user-friendlier error notice from the fatal error handler still shows if a runtime fatal error happens within the page generation process.
Props axaak.
Fixes#46811.
git-svn-id: https://develop.svn.wordpress.org/trunk@45210 602fd350-edb4-49c9-b593-d223f7449a82
Per Atom format's RFC, there must not be any whitespace in a Date construct or in any IRI.
Props josephwa.
Fixes#46922.
git-svn-id: https://develop.svn.wordpress.org/trunk@45208 602fd350-edb4-49c9-b593-d223f7449a82
Instantiating `WP_Recovery_Mode` should no longer have any required timing.
Props TimothyBlynJacobs, lkraav.
Fixes#46882.
git-svn-id: https://develop.svn.wordpress.org/trunk@45205 602fd350-edb4-49c9-b593-d223f7449a82
