Lowers the priority at which `wp_filter_default_autoload_value_via_option_size()` is registered to run on the `wp_default_autoload_value()` filter. The default filter now runs at priority 5.
This is to allow third party developers to modify whether an option is autoloaded using the default priority, 10, rather than require they register their code to run at a higher priority.
Follow up to [57920].
Props peterwilsoncc, joemcgill.
Fixes#42441.
Built from https://develop.svn.wordpress.org/trunk@58381
git-svn-id: http://core.svn.wordpress.org/trunk@57830 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In a similar vein as [58291], this changeset introduces a new `insert_hooked_blocks_into_rest_response` function and hooks it to the `rest_prepare_wp_navigation` filter.
This is part of an ongoing effort to move Block Hooks related code out of the Navigation block. Specifically, `insert_hooked_blocks_into_rest_response` is based on `block_core_navigation_insert_hooked_blocks_into_rest_response`. Eventually, it will be possible to deprecate the latter.
Follow-up to [58291].
See #60759.
Built from https://develop.svn.wordpress.org/trunk@58292
git-svn-id: http://core.svn.wordpress.org/trunk@57752 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As of [57790], the Templates endpoint uses the `rest_pre_insert_*` filter to inject the `ignoredHookedBlocks` metadata attribute into anchor blocks, prior to persisting a template or template part to the database. The same principle was implemented for the Navigation endpoint (where additionally, first and last child blocks added at the top level are store in the `wp_navigation` post object's post meta). The required logic was added to the Navigation block's code, i.e. inside the Gutenberg code repository, and then synchronized to Core.
In order to harmonize the code between the two endpoints, this changeset introduces a new `update_ignored_hooked_blocks_postmeta` function, which is based on the Navigation block's `block_core_navigation_update_ignore_hooked_blocks_meta`, alongside a few helper functions, and hooks it to the `rest_pre_insert_wp_navigation` filter hook. (The Navigation block has been prepared in [58275] to add an additional conditional to check for the new `update_ignored_hooked_blocks_postmeta` filter so there won't be any collisions.)
Eventually, this will allow to deprecate `block_core_navigation_update_ignore_hooked_blocks_meta` (and some related functions), and remove the relevant code from the Navigation block. It also paves the way for some other future changes, such as inserting a hooked block as a Template Part block's first or last child (#60854).
Props tomjcafferkey, bernhard-reiter.
Fixes#60759.
Built from https://develop.svn.wordpress.org/trunk@58291
git-svn-id: http://core.svn.wordpress.org/trunk@57751 1a063a9b-81f0-0310-95a4-ce76da25c4cd
An excessive amount of autoloaded options is a common cause for slow database responses, sometimes caused by very large individual autoloaded options. As it is not mandatory to provide an autoload value when adding an option to the database, it tends to be ignored, which in combination with a default value of "yes" and lack of documentation can lead to the aforementioned problem.
This changeset enhances the option autoloading behavior in several ways:
* Update the function documentation to encourage the use of boolean `true` or `false` to explicitly provide an autoload value for an option.
* Use new string values `on` and `off` for explicitly provided values stored in the database, to distinguish them from `yes` and `no`, since `yes` does not allow determining whether it was set intentionally by the developer or only as a default.
* Effectively deprecate the values `yes` and `no`. They are still supported for backward compatibility, but now discouraged.
* Use `null` as new default autoload value for `add_option()`. If the developer does not provide an explicit value, this will now trigger WordPress logic to determine an autoload value to use:
* If WordPress determines that the option should not be autoloaded, it is stored in the database as `auto-off`. As part of this changeset, the single heuristic introduced for that is to check whether the option size is larger than a threshold of 150k bytes. This threshold is filterable via a new `wp_max_autoloaded_option_size` filter.
* If WordPress determines that the option should be autoloaded, it is stored in the database as `auto-on`. No logic to make such a decision is introduced as part of this changeset, but a new filter `wp_default_autoload_value` can be used to define such heuristics, e.g. by optimization plugins.
* If WordPress cannot determine whether or not to autoload the option, it is stored in the database as `auto`.
* This effectively means that any option without an explicit autoload value provided by the developer will be stored with an autoload value of `auto`, unless the option's size exceeds the aforementioned threshold. Options with a value of `auto` are still autoloaded as of today, most importantly for backward compatibility. A new function `wp_autoload_values_to_autoload()` returns the list of autolaod values that dictate for an option to be autoloaded, and a new filter `wp_autoload_values_to_autoload` can be used to alter that list.
These behavioral changes encourage developers to be more mindful of autoloading, while providing WordPress core and optimization plugins with additional control over heuristics for autoloading options where no explicit autoload value was provided.
At the same time, the changes are fully backward compatible from a functionality perspective, with the only exception being that very large options will now no longer be autoloaded if the developer did not explicitly request for them to be autoloaded. Neither WordPress core nor plugins are able to override an explicitly provided value, which is intentional to continue giving developers full control over their own options.
Props pbearne, flixos90, joemcgill, azaozz, spacedmonkey, swissspidy, mukesh27, markjaquith.
Fixes#42441.
Built from https://develop.svn.wordpress.org/trunk@57920
git-svn-id: http://core.svn.wordpress.org/trunk@57421 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `$context` argument passed to filters such as `hooked_block_types`, `hooked_block`, and `hooked_block_{$hooked_block_type}` allows them to conditionally insert a hooked block. If the anchor block is contained in a template or template part, `$context` will be set to a `WP_Block_Template` object reflecting that template or part.
The aforementioned filters are applied when hooked block insertion is run upon reading a template (or part) from the DB (and before sending the template/part content with hooked blocks inserted over the REST API to the client), but also upon writing to the DB, as that's when the `ignoredHookedBlocks` metadata attribute is set.
Prior to this changeset, the `$context` passed to Block Hooks related filters in the latter case reflected the template/part that was already stored in the database (if any), which is a bug; instead, it needs to reflect the template/part that will result from the incoming `POST` network request that will trigger a database update.
Those incoming changes are encapsulated in the `$changes` argument passed to the `reset_pre_insert_template` and `reset_pre_insert_template_part` filters, respectively, and thus to the `inject_ignored_hooked_blocks_metadata_attributes` function that is hooked to them. `$changes` is of type `stdClass` and only contains the fields that need to be updated. That means that in order to create a `WP_Block_Template` object, a two-step process is needed:
- Emulate what the updated `wp_template` or `wp_template_part` post object in the database will look like by merging `$changes` on top of the existing `$post` object fetched from the DB, or from the theme's block template (part) file, if any.
- Create a `WP_Block_Template` from the resulting object.
To achieve the latter, a new helper method (`_build_block_template_object_from_post_object`) is extracted from the existing `_build_block_template_result_from_post` function. (The latter cannot be used directly as it includes a few database calls that will fail if no post object for the template has existed yet in the database.)
While somewhat complicated to implement, the overall change allows for better separation of concerns and isolation of entities. This is visible e.g. in the fact that `inject_ignored_hooked_blocks_metadata_attributes` no longer requires a `$request` argument, which is reflected by unit tests no longer needing to create a `$request` object to pass to it, thus decoupling the function from the templates endpoint controller.
Unit tests for `inject_ignored_hooked_blocks_metadata_attributes` have been moved to a new, separate file. Test coverage has been added such that now, all three relevant scenarios are covered:
- The template doesn't exist in the DB, nor is there a block theme template file for it.
- The template doesn't exist in the DB, but there is a block theme template file for it.
- The template already exists in the DB.
Those scenarios also correspond to the logical branching inside `WP_REST_Templates_Controller::prepare_item_for_database`, which is where `inject_ignored_hooked_blocks_metadata_attributes` gets its data from.
Props tomjcafferkey, bernhard-reiter, gziolo, swissspidy.
Fixes#60754.
Built from https://develop.svn.wordpress.org/trunk@57919
git-svn-id: http://core.svn.wordpress.org/trunk@57420 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset adds a new `rest_pre_insert_{$this->post_type}` filter in the `WP_REST_Templates_Controller`, where it is applied to the return value of the `prepare_item_for_database` method. (This is consistent with the `WP_REST_Post_Controller`, where that filter has existed before.)
The new filter is then used to inject hooked blocks into the template (or template part) content received via the endpoint, prior to persisting it to the database.
This supersedes the previous mechanism, which was using the `rest_after_insert_{$this->post_type}` ''action'', from which it performed an additional `wp_update_post` call to update the template (part) content with the hooked blocks injected. The new technique eschews that additional call and the resulting extra revision it created, as well as a problem with regard to duplicated escaping and sanitization, which had caused some special characters to be garbled.
Props tomjcafferkey, gziolo, swissspidy, karolmanijak.
Fixes#60671.
Built from https://develop.svn.wordpress.org/trunk@57790
git-svn-id: http://core.svn.wordpress.org/trunk@57291 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Decouple hooked blocks insertion from setting the `metadata.ignoredHookedBlocks` attribute on anchor blocks, and perform the latter step upon saving a template or template part to the database. This ensures that anchor blocks that have been newly added to a template (or part) on the client side will also get `ignoredHookedBlocks` metadata set correctly, thus preserving editor/front-end parity. Hooked block insertion, on the other hand, will continue to happen upon ''reading'' a template (or part).
Props gziolo, tomjcafferkey.
Fixes#60506.
Built from https://develop.svn.wordpress.org/trunk@57627
git-svn-id: http://core.svn.wordpress.org/trunk@57128 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is the first step towards adding the font library to WordPress.
This commit includes the font library and font face CPTs.
It also adds the necessary APIs and classes to register and manipulate font collections.
This PR backports the font library post types and low level APIs to Core. This is the first step to include the font library entirely into Core. Once this merged, we'll open a PR with the necessary REST API controllers.
Props youknowriad, get_dave, grantmkin, swissspidy, hellofromtonya, mukesh27, mcsf.
See #59166.
Built from https://develop.svn.wordpress.org/trunk@57539
git-svn-id: http://core.svn.wordpress.org/trunk@57040 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The Customizer live preview broke because of [56635], however the root cause for the bug was a lower-level problem that had been present since WordPress 5.8: The block theme specific functions `_add_default_theme_supports()` and `wp_enable_block_templates()` were being hooked into the `setup_theme` action, which fires too early to initialize theme features. Because of that, theme functionality would be initialized before the current theme setup being completed. In the case of the Customizer, that includes overriding which theme is the current theme entirely, thus leading to an inconsistent experience.
This changeset fixes the bug by moving those two callbacks to the `after_setup_theme` action, which is the appropriate action to initialize theme features.
Props karl94, hellofromTonya, joemcgill, flixos90.
Fixes#59732.
See #18298, #53397, #54597.
Built from https://develop.svn.wordpress.org/trunk@57009
git-svn-id: http://core.svn.wordpress.org/trunk@56520 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Introduce `wp_enqueue_block_template_skip_link()` to replace `the_block_template_skip_link()`. Add to `wp_enqueue_scripts` action instead of `wp_footer`.
* Keep inline script for skip link in footer.
* Restore original `the_block_template_skip_link()` from 6.3 and move to `deprecated.php`.
* Preserve back-compat for unhooking skip-link by removing `the_block_template_skip_link` from `wp_footer` action.
Follow-up to [56682] and [56687].
Props sabernhardt, plugindevs, westonruter, spacedmonkey.
Fixes#59505.
See #58775.
See #58664.
Built from https://develop.svn.wordpress.org/trunk@56932
git-svn-id: http://core.svn.wordpress.org/trunk@56443 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This aims to better align the navigation fallback implementation with core architecture and best practices.
The function that updates the `wp_navigation` post response schema is now a public method of the `WP_Navigation_Fallback` class, so an extra file previously used for that specific function is no longer necessary.
Follow-up to [56052].
Props ramonopoly, scruffian, isabel_brison, mukesh27, swissspidy, rajinsharwar, afercia, audrasjb, mikeschroder, JeffPaul, johnjamesjacoby, TimothyBlynJacobs, oglekler, SergeyBiryukov.
Fixes#58910.
Built from https://develop.svn.wordpress.org/trunk@56793
git-svn-id: http://core.svn.wordpress.org/trunk@56305 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Enable the storing of post meta in revisions including autosaves and previews:
Add a new argument `revisions_enabled` to the `register_meta` function which enables storing meta in revisions.
Add a new `wp_post_revision_meta_keys` filter which developers can use to control which meta is revisioned - it passes an array of the meta keys with revisions enabled as well as the post type.
Meta keys with revisions enabled are also stored for autosaves, and are restored when a revision or autosave is restored. In addition, meta values are now stored with the autosave revision used for previews. Changes to meta can now be previewed correctly without overwriting the published meta (see #20299) or passing data as a query variable, as the editor currently does to preview changes to the featured image.
Changes to meta with revisions enabled are considered when determining if a new revision should be created. A new revision is created if the meta value has changed since the last revision.
Revisions are now saved on the `wp_after_insert_post` hook instead of `post_updated`. The `wp_after_insert_post` action is fired after post meta has been saved by the REST API which enables attaching meta to the revision. To ensure backwards compatibility with existing action uses, `wp_save_post_revision_on_insert` function exits early if plugins have removed the previous `do_action( 'post_updated', 'wp_save_post_revision' )` call.
Props: alexkingorg, johnbillion, markjaquith, WraithKenny, kovshenin, azaozz, tv-productions, p51labs, mattheu, mikeschroder, Mamaduka, ellatrix, timothyblynjacobs, jakemgold, bookwyrm, ryanduff, mintindeed, wonderboymusic, sanchothefat, westonruter, spacedmonkey, hellofromTonya, drewapicture, adamsilverstein, swisspiddy.
Fixes#20564, #20299.
Built from https://develop.svn.wordpress.org/trunk@56714
git-svn-id: http://core.svn.wordpress.org/trunk@56226 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prior to this change, images added in shortcodes would be considered separately from all other images within post content, which led to incorrect application of the loading optimization attributes `loading="lazy"` and `fetchpriority="high"`.
This changeset changes the filter priority of `wp_filter_content_tags()` from the default `10` to `12` on the various content filters it is hooked in, in order to run that function after parsing shortcodes. While this may technically be considered a backward compatibility break, substantial research and lack of any relevant usage led to the assessment that the change is acceptable given its benefits.
An additional related fix included is that now the duplicate processing of images is prevented not only for post content blobs (`the_content` filter), but also for widget content blobs (`widget_text_content` and `widget_block_content` filters).
Props joemcgill, mukesh27, costdev, spacedmonkey, flixos90.
Fixes#58853.
Built from https://develop.svn.wordpress.org/trunk@56693
git-svn-id: http://core.svn.wordpress.org/trunk@56205 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In this commit, enhancements have been made by replacing manually constructed style tags with calls to `wp_add_inline_style`. Previously, numerous style tags were generated and output directly in the header, resulting in redundant code and bypassing the core's style enqueueing system. This approach made it challenging for third-party developers to manage and control the output of these style tags.
To ensure backward compatibility, the following functions have been deprecated and replaced:
- print_embed_styles
- print_emoji_styles
- wp_admin_bar_header
- _admin_bar_bump_cb
Backward compatibility shims have also been added, ensuring that if these functions were previously unhooked from there actions, they will continue to not output a style tag.
However, for the following functions, conversion to use inline styles was not feasible due to the potential disruption it might cause by changing the style tag IDs, potentially breaking JavaScript functionality for a number of plugins in the repository:
- custom-background
- wp-custom
These changes improve code maintainability and enhance the flexibility and control available to developers when managing style outputs within WordPress core.
Props spacedmonkey, hlunter, westonruter, flixos90.
Fixes#58775.
Built from https://develop.svn.wordpress.org/trunk@56682
git-svn-id: http://core.svn.wordpress.org/trunk@56194 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Fix an issue where a cron job ran every 12 hours to check for https support - even when https support was already enabled. The check is now run only when the user visits the Site Health page. Reducing the unneeded requests lowers the impact and load of hosting WordPress sites.
The `wp_update_https_detection_errors` function is deprecated and the `https_detection_errors` option that was previously set by the cron job is no longer maintained. The `pre_wp_update_https_detection_errors` filter is deprecated and replaced by the `pre_wp_get_https_detection_errors` filter which serves the same function.
Props audrasjb, johnbillion, Michi91.
Fixes#58494.
Built from https://develop.svn.wordpress.org/trunk@56664
git-svn-id: http://core.svn.wordpress.org/trunk@56176 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Ensures that preview callbacks attached to the `stylesheet` and `template` filters do not run before `pluggable.php` has been included. These callbacks need functionality from `pluggable.php`.
Props: scruffian, johnbillion, SergeyBiryukov, okat, okat.
Fixes: #59000.
Built from https://develop.svn.wordpress.org/trunk@56529
git-svn-id: http://core.svn.wordpress.org/trunk@56041 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introducing Font Face, a server-side `@font-face` styles generator and printer.
tl;dr:
* Introduces Font Face.
* Deprecates `_wp_theme_json_webfonts_handler()`.
**Introduce Font Face**
From an array of fonts (i.e. each font-family and its font variations to be processed), it:
1. Validates each `font-face` declaration, i.e. the CSS property and value pairing. If validation fails, processing stops with no font-face styles printed.
3. Generates the `@font-face` CSS for each font-family.
4. Prints the CSS within a `<style id="wp-fonts-local">` element.
The entry point into Font Face is through a new global function called `wp_print_font_faces()`, which is automatically called:
* when the `'wp_head'` hook runs (for the front-end).
* when the `'admin_print_styles'` hook runs (for the back-end).
* when `_wp_get_iframed_editor_assets()` runs to inject the `@font-face` styles into the iframed editor.
Once called, it gets the fonts from Theme_JSON merged data layer, which includes theme defined fonts and user activated fonts (once the Font Library #59166 is introduced into Core).
For classic sites, themes and plugins can directly call `wp_print_font_faces()` and pass their fonts array to it for processing.
**Deprecates `_wp_theme_json_webfonts_handler()`.**
As Font Face is a direct replacement, the stopgap code in `_wp_theme_json_webfonts_handler()` (introduced in 6.0.0 via [53282]) is deprecated and unused in Core.
**Props note:**
There's a long multiple year history baked into Font Face, which dates back to the early versions of a web font API (see #46370 and [https://github.com/WordPress/gutenberg/issues/41479 roadmap]. The props list includes those who contributed from those early versions up to this commit.
**References:**
* #46370 original (Web)Fonts API proposal for registering and enqueuing web fonts.
* [https://github.com/WordPress/gutenberg/issues/41479 Gutenberg tracking issue] which includes the evolution from Webfonts API to Fonts API to Font Face.
* [53282] / #55567 Added the stopgap code `_wp_theme_json_webfonts_handler()` in 6.0.
* [https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face @font-face on mdn web docs]
* #59166 Font Library: Font manager for WordPress
Follow-up to [53282].
Props aristath, jonoaldersonwp, hellofromTonya, andraganescu, annezazu, antonvlasenko, arena, askdesign, azaozz, bph, bradley2083, colorful-tones, costdev, davidbaumwald, desrosj, dingo_d, djcowan, domainsupport, dryanpress, elmastudio, flixos90, francina, garrett-eclipse, gigitux, grantmkin, grapplerulrich, gziolo, ironprogrammer, jb510, jeffpaul, jeremyyip, jffng, joostdevalk, jorgefilipecosta, juanmaguitar, mamaduka, matveb, mburridge, mitogh, ndiego, ntsekouras, oandregal, ocean90, oglekler, paaljoachim, pagelab, peterwilsoncc, poena, priethor, scruffian, SergeyBiryukov, shiloey, simison, skorasaurus, soean, westonruter, wildworks, zaguiini.
Fixes#59165.
Built from https://develop.svn.wordpress.org/trunk@56500
git-svn-id: http://core.svn.wordpress.org/trunk@56012 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The changeset [55695] introduced a regression in the order of styles for the editor, causing the styles registered for the block (both editor and front) to be loaded after any other styles enqueued using the `enqueue_block_editor_assets` hook.
Since the original behavior was introduced in WordPress 5.0 changing it breaks the expectations of the ecosystem.
Props ellatrix.
Fixes#58208.
Built from https://develop.svn.wordpress.org/trunk@55852
git-svn-id: http://core.svn.wordpress.org/trunk@55364 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since WordPress 5.9, a "context" value of "wp_get_attachment_image" has been used in the `wp_get_attachment_image()` function to provide context to underlying functions where that is relevant, e.g. `wp_get_loading_attr_default()`. Since that value used to be not customizable, it required a workaround in `get_the_post_thumbnail()` to avoid calling those functions in `wp_get_attachment_image()`, which resulted in unnecessary complexity and was prone to errors.
This changeset introduces a `wp_get_attachment_image_context` filter and leverages it with private filter callback functions that are leveraged by default when `get_the_post_thumbnail()` is called. This avoids the need for the previous workaround and furthermore provides flexibility for other callers of `wp_get_attachment_image()` to provide their own contexts.
Props flixos90, costdev, thekt12, westonruter, spacedmonkey.
Fixes#58212.
Built from https://develop.svn.wordpress.org/trunk@55821
git-svn-id: http://core.svn.wordpress.org/trunk@55333 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This PR removes the `wp_enqueue_registered_block_scripts_and_styles` callback from the `enqueue_block_editor_assets` action.
There are two actions to enqueue block assets: `enqueue_block_editor_assets` and `enqueue_block_assets`. The former enqueues the assets to the editor and the later enqueues them to the front-end and the editor. Given `wp_enqueue_registered_block_scripts_and_styles` is already bound to the `enqueue_block_assets` (front-end and editor), it is unnecessary to bind it to `enqueue_block_editor_assets` (editor) as well.
This was originally introduced at [44157] and hasn't been modified since.
Props ellatrix, costdev.
Fixes#58208.
Built from https://develop.svn.wordpress.org/trunk@55695
git-svn-id: http://core.svn.wordpress.org/trunk@55207 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Cache the results of database queries within `WP_User_Query` class. Only cache queries that are requesting 3 or less fields so that caches are not storing full user objects. Cache results are stored in a new global cache group named `users-queries`. Add a new parameter to `WP_User_Query` called `cache_results` to allow developers to opt out of a receiving cached results. `cache_results` parameter defaults to true. Also add a new helper function called `wp_cache_set_users_last_changed`, similar to `wp_cache_set_posts_last_changed` that incroments last changed value in cache group `users`. Ensure that `wp_cache_set_users_last_changed` is called whenever user / user meta is modified for proper cache invalidation.
Props johnjamesjacoby, spacedmonkey, westi, dd32, strategio, srikanthmeenakshi, OllieJones, khoipro, rjasdfiii, flixos90, mukesh27, peterwilsoncc.
Fixes#40613.
Built from https://develop.svn.wordpress.org/trunk@55657
git-svn-id: http://core.svn.wordpress.org/trunk@55169 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The XML manifest was originally added in WordPress 2.3.1 to turn on tagging support in Windows Live Writer.
Given that the last major release of the software came out in 2012, and it was completely discontinued in January 2017, including this file in core no longer provides any benefit.
Follow-up to [6192], [49904].
Props joostdevalk, ayeshrajans, flixos90, jhabdas, frank-klein, wtranch, SergeyBiryukov.
Fixes#41404.
Built from https://develop.svn.wordpress.org/trunk@55620
git-svn-id: http://core.svn.wordpress.org/trunk@55132 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When switching to a block theme, classic sidebars were orphaned and their widgets remapping to the `'wp_inactive_widgets'` sidebar . This changeset preserves the sidebars and their widgets, providing a migration path to a block theme without losing the widgets.
Classic sidebars are now:
* Stored in a new theme mod called `'wp_classic_sidebars'`;
* Restored to the `$wp_registered_sidebars` global variable when the `'widgets_init'` action fires (via a new internal function called `_wp_block_theme_register_classic_sidebars()`);
* And marked as `'inactive'` when interacting with sidebars REST API endpoint.
References:
* [https://github.com/WordPress/gutenberg/pull/45509 Gutenberg PR 45509] which adds an option for importing widgets from sidebars into template parts.
Follow-up to [50995], [6334].
Props mamaduka, audrasjb, hellofromTonya, ironprogrammer, jameskoster, joen, matveb, mukesh27, noisysocks, poena, youknowriad.
Fixes#57531.
Built from https://develop.svn.wordpress.org/trunk@55200
git-svn-id: http://core.svn.wordpress.org/trunk@54733 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces functions `wp_get_global_styles_custom_css()` and `wp_enqueue_global_styles_custom_css()`, which allow accessing and enqueuing custom CSS added via global styles.
Custom CSS via global styles is handled separately from custom CSS via the Customizer. If a site uses both features, the custom CSS from both sources will be loaded. The global styles custom CSS is then loaded after the Customizer custom CSS, so if there are any conflicts between the rules, the global styles take precedence.
Similarly to e.g. [55185], the result is cached in a non-persistent cache, except when `WP_DEBUG` is on to avoid interrupting the theme developer's workflow.
Props glendaviesnz, oandregal, ntsekouras, mamaduka, davidbaumwald, hellofromtonya, flixos90.
Fixes#57536.
Built from https://develop.svn.wordpress.org/trunk@55192
git-svn-id: http://core.svn.wordpress.org/trunk@54725 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds `wp_theme_has_theme_json()` for public consumption, to replace the private internal Core-only `WP_Theme_JSON_Resolver::theme_has_support()` method. This new global function checks if a theme or its parent has a `theme.json` file.
For performance, results are cached as an integer `1` or `0` in the `'theme_json'` group with `'wp_theme_has_theme_json'` key. This is a non-persistent cache. Why? To make the derived data from `theme.json` is always fresh from the potential modifications done via hooks that can use dynamic data (modify the stylesheet depending on some option, settings depending on user permissions, etc.).
Also adds a new public function `wp_clean_theme_json_cache()` to clear the cache on `'switch_theme'` and `start_previewing_theme'`.
References:
* [https://github.com/WordPress/gutenberg/pull/45168 Gutenberg PR 45168] Add `wp_theme_has_theme_json` as a public API to know whether a theme has a `theme.json`.
* [https://github.com/WordPress/gutenberg/pull/45380 Gutenberg PR 45380] Deprecate `WP_Theme_JSON_Resolver:theme_has_support()`.
* [https://github.com/WordPress/gutenberg/pull/46150 Gutenberg PR 46150] Make `theme.json` object caches non-persistent.
* [https://github.com/WordPress/gutenberg/pull/45979 Gutenberg PR 45979] Don't check if constants set by `wp_initial_constants()` are defined.
* [https://github.com/WordPress/gutenberg/pull/45950 Gutenberg PR 45950] Cleaner logic in `wp_theme_has_theme_json`.
Follow-up to [54493], [53282], [52744], [52049], [50959].
Props oandregal, afragen, alexstine, aristath, azaozz, costdev, flixos90, hellofromTonya, mamaduka, mcsf, ocean90, spacedmonkey.
Fixes#56975.
Built from https://develop.svn.wordpress.org/trunk@55086
git-svn-id: http://core.svn.wordpress.org/trunk@54619 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This modifies how the `menu-item-has-children` class is removed from bottom level menu items. Instead of removing the class within `wp_nav_menu()` a filter is applied to the `nav_menu_css_class` hook to remove the class as required.
Introduces `wp_nav_menu_remove_menu_item_has_children_class()` for removing the class.
Reverts source code changes in [54478,54801], the tests are retained.
Props davidbinda, SergeyBiryukov, mhkuu, JeffPaul, jmdodd, priethor, desrosj, hellofromTonya, azaozz, peterwilsoncc.
Fixes#56926.
See #28620.
Built from https://develop.svn.wordpress.org/trunk@54999
git-svn-id: http://core.svn.wordpress.org/trunk@54532 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [54358], styling for Button blocks that had been removed from classic themes was reintroduced. However, it was added with a global scope, whereas editor styles are usually added with a `.editor-styles-wrapper` selector, which makes them more specific.
This change modifies the way that classic theme styles are added so that they also get wrapped in an `.editor-styles-wrapper` selector to match specificity.
Furthermore, adjust specificity for some Button block related styling in the editor for the Twenty Twelve and Twenty Twenty themes.
Merges [https://github.com/WordPress/gutenberg/pull/44731 Gutenberg PR 44731] into trunk.
Follow-up to [54358].
Props scruffian, cbravobernal, sabernhardt, audrasjb.
See #56467.
Built from https://develop.svn.wordpress.org/trunk@54687
git-svn-id: http://core.svn.wordpress.org/trunk@54239 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[54248] reversed the wrapping of `do_shortcode` and `apply_shortcodes` and updated all direct internal calls of `do_shortcode` to `apply_shortcodes` after [47004]. Default filter callbacks that used `do_shortcode` were also updated to use `apply_shortcodes`. However, this introduced a backward-compatibility break because any attempt to unhook a filter using the previous `do_shortcode` callback would be futile.
This change reverts only the filter callback changes in [54248] to resolve the backward-compatibility break.
Follow-up to [47004] and [54248].
Props ocean90, SergeyBiryukov.
See #55883.
Built from https://develop.svn.wordpress.org/trunk@54278
git-svn-id: http://core.svn.wordpress.org/trunk@53837 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset reverses the wrapping of `apply_shortcodes()` and `do_shortcode()` such that `apply_shortcodes()` is now the recommended function. In addition:
- Calls to `do_shortcode()` have been changed to `apply_shortcodes()`.
- Some default filter callbacks have been changed from `'do_shortcode'` to `'apply_shortcodes'`.
- Applicable documentation has been updated to refer to `apply_shortcodes()` instead.
Follow-up to [47004].
Props SergeyBiryukov, rafiahmedd, namithjawahar, peterwilsoncc, costdev.
Fixes#55883.
Built from https://develop.svn.wordpress.org/trunk@54248
git-svn-id: http://core.svn.wordpress.org/trunk@53807 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds a new feature to persist editor UI preferences between page loads and browsers.
* Adds a new preferences persistence API.
* Saves editor preferences in user meta instead of in browser's local storage.
Why?
Due to the transient nature of browser storage, this persistence is not as sticky as it is expected to be, including: switching browsers (unique storage between browsers), or using private browsing tabs (storage cleared between sessions), or the same user across a network of sites (storage unique by domain).
This is a backport from Gutenberg.[https://github.com/WordPress/gutenberg/pull/39795 See WordPress/gutenberg PR 39795].
Props talldanwp, youknowriad, noisysocks, mamaduka, costdev, ironprogrammer, hellofromTonya.
See #56467.
Built from https://develop.svn.wordpress.org/trunk@54182
git-svn-id: http://core.svn.wordpress.org/trunk@53741 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The existing filter `image_editor_output_format` receives an additional parameter `$size_name` which is populated whenever it controls the output format for a specific registered image size to create. Otherwise, it remains empty. In order to achieve this, a low level change has been added in bringing a new `$size_name` class property to the `WP_Image_Editor` base class, which is introduced in a backward compatible way that will not cause conflicts with custom implementations.
This parameter is then used in new logic inside the `wp_default_image_output_mapping()` callback function for the filter, controlling whether `image/jpeg` should map to `image/webp` output or not. By default, this is enabled for all WordPress core image sizes by default, and this list can be modified using a new `wp_image_sizes_with_additional_mime_type_support` filter, e.g. to remove core sizes or add custom sizes.
The customization per image size may be further enhanced by providing a more declarative API via a new parameter on the `add_image_size()` function.
Props eugenemanuilov, flixos90, adamsilverstein, joegrainger.
Fixes#56526.
See #55443, #56288.
Built from https://develop.svn.wordpress.org/trunk@54097
git-svn-id: http://core.svn.wordpress.org/trunk@53656 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While the `image_editor_output_format` filter is primarily used in WP Admin, it can also be executed in frontend scope, as the related `WP_Image_Editor` class and `wp_unique_filename()` function are being loaded in that scope.
Follow up to [54086].
See #55443, #56526.
Built from https://develop.svn.wordpress.org/trunk@54094
git-svn-id: http://core.svn.wordpress.org/trunk@53653 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add a `wp_preload_resources` filter that developers can use to add resource preloading.
Preloading helps the browser discover and prioritize important resources earlier during the page load. This ensures that they are available earlier and are less likely to block the page's render.
Props nico23, swissspidy, igrigorik, westonruter, azaozz, furi3r, aristath, spacedmonkey, peterwilsoncc, mihai2u, gziolo.
Fixes#42438.
Built from https://develop.svn.wordpress.org/trunk@53846
git-svn-id: http://core.svn.wordpress.org/trunk@53405 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This aims to improve performance by calling `sanitize_url()` directly, instead of the `esc_url_raw()` wrapper. As of WordPress 6.1, `sanitize_url()` is the recommended function for sanitizing a URL for database or redirect usage.
Follow-up to [11383], [13096], [51597], [53452].
Props benjgrolleau, peterwilsoncc, SergeyBiryukov.
Fixes#55852.
Built from https://develop.svn.wordpress.org/trunk@53455
git-svn-id: http://core.svn.wordpress.org/trunk@53044 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds `_wp_theme_json_webfonts_handler()` for handling `fontFace` declarations in a theme's `theme.json` file to generate the `@font-face` styles for both the editor and front-end.
Design notes:
* It is not a public API, but rather an internal, Core-only handler.
* It is a stopgap implementation that will be replaced when the public Webfonts API is introduced in Core.
* The code design is intentional, albeit funky, with the purpose of avoiding backwards-compatibility issues when the public Webfonts API is introduced in Core.
* It hides the inter-workings.
* Does not exposing API ins and outs for external consumption.
* Only works for `theme.json`.
* Does not provide registration or enqueuing access for plugins.
For more context on the decision to include this stopgap and the Webfonts API, see:
* Core's PR 40493 https://github.com/WordPress/gutenberg/pull/40493
* Gutenberg's tracking issue 40472 https://github.com/WordPress/gutenberg/issues/40472
Props aristath, hellofromTonya, peterwilsoncc, costdev, jffng, zieladam, gziolo, bph, jonoaldersonwp, desrosj.
See #55567, #46370.
Built from https://develop.svn.wordpress.org/trunk@53282
git-svn-id: http://core.svn.wordpress.org/trunk@52871 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change moves some administration related hooks from `default-filters.php` to `admin-filters.php`. It also updates the `default-filters.php` docblock to indicate that contextualized hooks should be located in the most appropriate place.
Props dlh, hellofromTonya, antonvlasenko, audrasjb, azaozz.
Fixes#54795.
Built from https://develop.svn.wordpress.org/trunk@53266
git-svn-id: http://core.svn.wordpress.org/trunk@52855 1a063a9b-81f0-0310-95a4-ce76da25c4cd
