The HTML API escapes `<style>` tag contents to ensure the correct HTML structure. Common HTML escaping is unsuitable for `<style>` tags because they contain "raw text." The additional safety allows other restrictions, such as rejecting content with `<>`, to be relaxed or removed because the resulting tag will be well-formed.
Developed in https://github.com/WordPress/wordpress-develop/pull/10656.
Props jonsurrell, westonruter, dmsnell, ramonopoly, soyebsalar01, drw158, sabernhardt.
See #64418.
Built from https://develop.svn.wordpress.org/trunk@61418
git-svn-id: http://core.svn.wordpress.org/trunk@60730 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Remove the note to introduce caching to `get_uploaded_header_images()` as caching has since been introduced to `WP_Query` and therefore `get_posts()`. The comment is out of date.
Props audrasjb, desrosj, flixos90, mukesh27, pbearne, pbiron, sachinrajcp123, sergeybiryukov, swissspidy, westonruter, whyisjake.
See #49446, #63168.
Built from https://develop.svn.wordpress.org/trunk@60979
git-svn-id: http://core.svn.wordpress.org/trunk@60315 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is a follow-up to [59968] which improves error handling for when `wp_is_block_theme()` is called too early. Initially, `_doing_it_wrong()` was called in `WP_Theme::is_block_theme()` was called prior to themes being set up, in order to avoid the bug reported in #63062, where doing so would cause parent themes to not be resolved. After further investigation, the issue is only caused by calling `wp_is_block_theme()` before the root theme directory has been registered (e.g., when called on the `muplugins_loaded` hook).
Moving This error message to `wp_is_block_theme()` when `$GLOBALS['wp_theme_directories']` is empty avoids unnecessary error messages.
Props wildworks, sukhendu2002, SirLouen, dinhtungdu, narenin, joemcgill, peterwilsoncc, afragen.
Fixes#63086. See #63062.
Built from https://develop.svn.wordpress.org/trunk@60037
git-svn-id: http://core.svn.wordpress.org/trunk@59373 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Remove references to the obsolete style property `clip: rect(1px, 1px, 1px, 1px);` and replace or adapt to use `clip-path: inset(50%);`. Update associated `:focus` styles as appropriate. Remove prefixed instances of `-webkit-clip-path`.
Props afercia, hbhalodia, audrasjb, joedolson, sabernhardt.
Fixes#62238.
Built from https://develop.svn.wordpress.org/trunk@59832
git-svn-id: http://core.svn.wordpress.org/trunk@59174 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This function and filter complement the existing `wp_should_load_separate_core_block_assets()` with filter `'should_load_separate_core_block_assets'`, which until now was responsible for two different purposes:
1. Loading separate stylesheets for Core blocks, instead of a combined `wp-block-library` stylesheet (as the name indicates).
2. Loading block scripts and stylesheets on demand only if the blocks are included in the page (not indicated by the name).
The new function and filter handles exclusively the 2nd purpose, making it possible to individually adjust both behaviors. For backward compatibility, the return value of `wp_should_load_separate_core_block_assets()` is used as the filterable default for `wp_should_load_block_assets_on_demand()`. Yet, the two filters can now be individually be controlled: For example, a site owner that wants to keep loading the combined `wp-block-library` stylesheet can now do so without giving up on the ability to load block scripts and stylesheets on demand.
Block themes now opt in by default to both features, similar to how they were already doing before via just the one filter. This way, block themes that opt out of loading separate stylesheets for Core blocks will still benefit from loading block scripts and stylesheets on demand, which in the case of block themes is strongly recommended.
Props fabiankaegy, flixos90, gziolo.
Fixes#61965.
Built from https://develop.svn.wordpress.org/trunk@59823
git-svn-id: http://core.svn.wordpress.org/trunk@59165 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset replaces the hardcoded hash symbol with running `maybe_hash_hex_color()` on the full `background-color` value provided via the custom background feature, so the hash is only added if it is needed. By doing so, if a theme developer sets a background color value that uses a hash (#), WordPress won't add an additional hash anymore when outputting the relevant CSS. Duplicate hash symbols (##) can break CSS background color declarations.
Props hovhanneshovakimyan, joyously, poena,
Fixes#40057.
Built from https://develop.svn.wordpress.org/trunk@59813
git-svn-id: http://core.svn.wordpress.org/trunk@59155 1a063a9b-81f0-0310-95a4-ce76da25c4cd
It is recommended that for every option it is explicitly set whether to autoload it or not. This changeset updates relevant `update_option()` and `add_option()` calls.
Note that the `$autoload` parameter is only needed for `update_option()` if the option is potentially not present yet, i.e. the call will pass through to `add_option()`. Since WordPress core adds the majority of its options to the database during installation, only `update_option()` calls for dynamically added options need to be modified, which is what this changeset does.
As part of revisiting the autoload values for dynamically added WordPress core options, this changeset modifies some options to no longer be autoloaded, since they are only accessed in a few specific places that are not relevant for a regular request. These options are:
* `recently_activated`
* `_wp_suggested_policy_text_has_changed`
* `{upgradeLock}.lock`
* `dashboard_widget_options`
* `ftp_credentials`
* `adminhash`
* `nav_menu_options`
* `wp_force_deactivated_plugins`
* `delete_blog_hash`
* `allowedthemes`
* `{sessionId}_paused_extensions`
* `recovery_keys`
* `https_detection_errors`
* `fresh_site`
An upgrade routine is present as well that sets those options to no longer autoload for existing sites.
Props pbearne, flixos90, mukesh27, swissspidy, SergeyBiryukov, joemcgill, adamsilverstein.
Fixes#61103.
Built from https://develop.svn.wordpress.org/trunk@58975
git-svn-id: http://core.svn.wordpress.org/trunk@58371 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Replaces `trigger_error()` with `wp_trigger_error()`.
The usage of `wp_trigger_error()` avoids generating `E_USER` family errors unless `WP_DEBUG` is on. In doing so, users should not see these messages in normal production.
Notes:
* Removes `E_USER_NOTICE` when passed as an argumnent, as it's the default error level.
* An empty string is passed for the function name when its name is already in the error message or does not add value to the error message.
* Externally maintained libraries are not included.
Follow-up to [55204], [25956], [29630], [38883], [52062], [52049], [54272], [38883], [55245], [51599], [14452], [38883], [24976].
Props prasadkarmalkar, rajinsharwar, thelovekesh, hellofromTonya, swissspidy.
Fixes#59652.
Built from https://develop.svn.wordpress.org/trunk@58409
git-svn-id: http://core.svn.wordpress.org/trunk@57858 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The logo block does not use theme mods, and instead saves a site-wide option `site_logo` to use as the site logo.
Add handling for cases where the logo image does not exist and delete the `site_logo` option when the attachment configured as site logo is deleted.
Props afercia, joedolson, khokansardar, SergeyBiryukov.
Fixes#60922.
Built from https://develop.svn.wordpress.org/trunk@58213
git-svn-id: http://core.svn.wordpress.org/trunk@57676 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes a bug introduced by [57129] and [56635] in which deprecating the previous `TEMPLATEPATH` and `STYLESHEETPATH` constants in favor of `get_template_directory()` and `get_stylesheet_directory()` functions caused the active theme template path to change when using `switch_to_blog()`.
This introduces a new function, `wp_set_template_globals()`, which is called during the bootstrap process to store the template paths to new globals values `$wp_template_path` and `$wp_stylesheet_path`. This restores behavior to how things worked prior to [56635] but retains the ability for template values to be reset for better testability.
Related #18298, #60025.
Props joemcgill, flixos90, mukesh27, swissspidy, manfcarlo, metropolis_john, jeremyfelt.
Fixes#60290.
Built from https://develop.svn.wordpress.org/trunk@57685
git-svn-id: http://core.svn.wordpress.org/trunk@57186 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Use 'theme_files' cache group for block pattern caches. Previously, block pattern cache data was not stored in a cache group and used the default group. This new cache group, is setup as a global cache group, meaning that sites using multisite, will have a single cache for block pattern data per theme. This change also no longer invalidate block pattern caches in multisite instances, meaning block pattern caches can be shared between sites on a network, meaning less repeated data in the object cache.
Props spacedmonkey, flixos90, joemcgill.
Fixes#60120.
Built from https://develop.svn.wordpress.org/trunk@57608
git-svn-id: http://core.svn.wordpress.org/trunk@57109 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This reduces unnecessarily autoloaded data from inactive themes, which can contribute to slow database performance as part of excessive autoloading.
Props mukesh27, rajinsharwar, igmoweb, joemcgill, swissspidy, westonruter, flixos90.
Fixes#59537.
See #59975.
Built from https://develop.svn.wordpress.org/trunk@57153
git-svn-id: http://core.svn.wordpress.org/trunk@56664 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This aims to slightly improve performance by checking the faster `empty()` language construct first and potentially avoiding an unnecessary function call. Additionally, this better matches a similar conditional a few lines below.
Follow-up to [17757], [17770].
Props Cybr.
See #59650.
Built from https://develop.svn.wordpress.org/trunk@57139
git-svn-id: http://core.svn.wordpress.org/trunk@56650 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes bugs introduced in [56635] whereby the template or stylesheet path could be memoized incorrectly if `get_template_directory()` or `get_stylesheet_directory()` were called before the theme has been fully initialized.
Props partyfrikadelle, coreyw, kdowns, rebasaurus, meta4, flixos90, mukesh27, joemcgill.
Fixes#59847.
Built from https://develop.svn.wordpress.org/trunk@57129
git-svn-id: http://core.svn.wordpress.org/trunk@56640 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
The `_register_theme_block_patterns` function imposed a significant resource overhead. This issue primarily stems from themes, such as TT4, that register a substantial number of block patterns. These patterns necessitate numerous file operations, including file lookups, file reading into memory, and related processes. To provide an overview, the _register_theme_block_patterns function performed the following file operations:
- is_dir
- is_readable
- file_exists
- glob
- file_get_contents (utilized via get_file_data)
To address these issues, caching using a transient has been added to a new function call `_wp_get_block_patterns`. If theme development mode is disabled and theme exists, the block patterns are saved in a transient cache. This cache is used all requests after that, saving file lookups and reading files into memory. Cache invalidation is done, when themes are switched, deleted or updated. Meaning that block patterns are not stored in the cache incorrectly.
Props flixos90, joemcgill, peterwilsoncc, costdev, swissspidy, aristath, westonruter, spacedmonkey.
Fixes#59490
Built from https://develop.svn.wordpress.org/trunk@56765
git-svn-id: http://core.svn.wordpress.org/trunk@56277 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Add `wp_remove_surrounding_empty_script_tags()` to more precisely remove script tag wrappers and warn when doing it wrong.
* Add clarifying comments for XML escaping logic in `wp_get_inline_script_tag()`.
* Leverage `WP_HTML_Tag_Processor` in `test_remove_frameless_preview_messenger_channel`.
* Reuse `assertEqualMarkup` in `test_blocking_dependent_with_delayed_dependency`.
* Normalize whitespace in `parse_markup_fragment` for `assertEqualMarkup`.
Follow-up to [56687].
Props dmsnell, westonruter, flixos90.
See #58664.
Built from https://develop.svn.wordpress.org/trunk@56748
git-svn-id: http://core.svn.wordpress.org/trunk@56260 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `wp_get_loading_optimization_attributes()` function was introduced in 6.3, as a single centralized place to control loading optimization attributes for various tags, most importantly images.
This changeset consolidates the `decoding="async"` optimization, which was added in 6.1, to occur solely as part of `wp_get_loading_optimization_attributes()`, removing duplicate code and allowing centralized filtering based on [56651].
As part of the change, the `wp_img_tag_add_decoding_attr()` function has been deprecated. The filter of the same name continues to be maintained for backward compatibility, as before covering only images that are part of a content blob such as post content (`the_content`).
Props pereirinha, mukesh27, joemcgill, flixos90.
Fixes#58892.
See #53232.
Built from https://develop.svn.wordpress.org/trunk@56690
git-svn-id: http://core.svn.wordpress.org/trunk@56202 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Using script tag helper functions allows plugins to employ the `wp_script_attributes` and `wp_inline_script_attributes` filters to inject the `nonce` attribute to apply Content Security Policy (e.g. Strict CSP). Use of helper functions also simplifies logic in `WP_Scripts`.
* Update `wp_get_inline_script_tag()` to wrap inline script in CDATA blocks for XHTML-compatibility when not using HTML5.
* Ensure the `type` attribute is printed first in `wp_get_inline_script_tag()` for back-compat.
* Wrap existing `<script>` tags in output buffering to retain IDE supports.
* In `wp_get_inline_script_tag()`, append the newline to `$javascript` before it is passed into the `wp_inline_script_attributes` filter so that the CSP hash can be computed properly.
* In `the_block_template_skip_link()`, opt to enqueue the inline script rather than print it.
* Add `ext-php` to `composer.json` under `suggest` as previously it was an undeclared dependency for running PHPUnit tests.
* Update tests to rely on `DOMDocument` to compare script markup, normalizing unsemantic differences.
Props westonruter, spacedmonkey, flixos90, 10upsimon, dmsnell, mukesh27, joemcgill, swissspidy, azaozz.
Fixes#58664.
See #39941.
Built from https://develop.svn.wordpress.org/trunk@56687
git-svn-id: http://core.svn.wordpress.org/trunk@56199 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While generally the functions `get_template_directory()` and `get_stylesheet_directory()` were long recommended to use to get the parent or child theme directory, the `TEMPLATEPATH` and `STYLESHEETPATH` constants were still used in a few places in core, most importantly in template related logic.
The remaining usage was problematic as it prevented testability of certain key components of WordPress core.
This changeset replaces all remaining usage with the corresponding functions and effectively marks these constants as deprecated. It also adds test coverage accordingly and even unlocks some existing, previously commented out test coverage to work as expected.
Performance of the new approach has been benchmarked and shows no notable differences. Yet, given that the current theme directories are not expected to change within a regular WordPress page load, the `get_template_directory()` and `get_stylesheet_directory()` functions were amended with in-memory caching of the result, unless one of the defining values is being filtered.
Props thekt12, spacedmonkey, mukesh27, aaroncampbell, scribu, lloydbudd, cais, chipbennett, toscho, omarabid, CrazyJaco, DrewAPicture, obenland, wonderboymusic, nacin, helen, dd32, chriscct7, SergeyBiryukov, swissspidy, joemcgill, flixos90.
Fixes#18298.
Built from https://develop.svn.wordpress.org/trunk@56635
git-svn-id: http://core.svn.wordpress.org/trunk@56147 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset is a follow up to [56037] and ensures that the `get_header_image_tag()` function receives the benefits of `wp_get_loading_optimization_attributes()` as well. Prior to `fetchpriority` support, this was not needed since the header image should never be lazy-loaded, but the image certainly is a `fetchpriority` candidate, so therefore it is crucial to have it supported.
Props felipeelia, spacedmonkey, mukesh27, westonruter, flixos90.
Fixes#58680.
Built from https://develop.svn.wordpress.org/trunk@56142
git-svn-id: http://core.svn.wordpress.org/trunk@55654 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
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
