Typically, when registering a new block type, its metadata is read from the provided `block.json` file. The more block types are registered on a site, the more costly becomes this process, as it involves filesystem reads and parsing JSON.
WordPress Core's built-in blocks have in the past worked around that by having a auto-generated PHP manifest file that includes the already parsed JSON data for all blocks. This changeset effectively allows plugins to do the same, by introducing a new API function `wp_register_block_metadata_collection()`. The WordPress Core block manifest is now handled using this API as well, rather than custom logic baked into `register_block_type_from_metadata()`.
The `wp_register_block_metadata_collection()` function requires two parameters:
* `$path`: The base path in which block files for the collection reside.
* `$manifest`: The path to the manifest file for the collection.
Every `block.json` file that is supposed to be part of the collection must reside within the provided `$path`, within its own block-specific directory matching the block name (without the block namespace). For example, for a collection `$path` of `/wp-content/plugins/test-plugin` and a block `test-plugin/testimonial`, the block file could be `/wp-content/plugins/test-plugins/blocks/testimonial/block.json`.
It is recommended that plugins use the new API function for enhanced performance, especially if they register several block types. However, the use of the function is entirely optional. Not using it will not result in any difference in user-facing behavior.
Props mreishus, flixos90, gziolo, spacedmonkey, azaozz, mukesh27.
Fixes#62002.
Built from https://develop.svn.wordpress.org/trunk@59132
git-svn-id: http://core.svn.wordpress.org/trunk@58528 1a063a9b-81f0-0310-95a4-ce76da25c4cd
PHP 8.4 deprecates the use of `trigger_errror()` with `E_USER_ERROR` as the error level, as there are a number of gotchas to this way of creating a `Fatal Error` (`finally` blocks not executing, destructors not executing). The recommended replacements are either to use exceptions or to do a hard `exit`.
WP has its own `wp_trigger_error()` function, which under the hood calls `trigger_error()`. If passed `E_USER_ERROR` as the `$error_level`, this will hit the PHP 8.4 deprecation.
Now, there were basically three options:
* Silence the deprecation until PHP 9.0 and delay properly solving this until then. This would lead to an awkward solution, as prior to PHP 8.0, error silencing would apply to all errors, while, as of PHP 8.0, it will no longer apply to fatal errors. It also would only buy us some time and wouldn't actually solve anything.
* Use `exit($status)` when `wp_trigger_error()` is called with `E_USER_ERROR`. This would make the code untestable and would disable handling of these errors via custom error handlers, which makes this an undesirable solution.
* Throw an exception when `wp_trigger_error()` is called with `E_USER_ERROR`. This makes for the most elegant solution with the least BC-breaking impact, though it does open it up to the error potential being "caught" via a `try-catch`. That's not actually a bad thing and is likely to only happen for those errors which can be worked around, in which case, it's a bonus that that's now possible.
The third option is implemented which:
* Introduces a new `WP_Exception` class.
* Starts using `WP_Exception` in the `wp_trigger_error()` function when the `$error_level` is set to `E_USER_ERROR`.
This change is covered by pre-existing tests, which have been updated to expect the exception instead of a PHP error.
Why not use `WP_Error`?
Well, for one, this would lead to completely different behaviour (BC).
As `WP_Error` doesn't extend `Exception`, the program would not be stopped, but would continue running, which would be a much bigger breaking change and carries security risks. `WP_Error` also doesn't natively trigger displaying/logging of the error message, so in that case, it would still need an `exit` with the error message, bringing us back to point 2 above.
Introducing `WP_Exception` provides (essentially) the same behaviour in that it retains the fatal error and error message displaying/logging behaviors. It also introduces a base Exception class, from which future exception classes can extend.
References:
* https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_passing_e_user_error_to_trigger_error
* https://www.php.net/manual/en/migration80.incompatible.php
Follow-up to [56530].
Props jrf, hellofromTonya.
See #62061.
Built from https://develop.svn.wordpress.org/trunk@59107
git-svn-id: http://core.svn.wordpress.org/trunk@58503 1a063a9b-81f0-0310-95a4-ce76da25c4cd
HTML is a kind of short-hand for a DOM structure. This means that there are
many cases in HTML where an element's opening tag or closing tag is missing (or
both). This is because many of the parsing rules imply creating elements in the
DOM which may not exist in the text of the HTML.
The HTML Processor, being the higher-level counterpart to the Tag Processor, is
already aware of these nodes, but since it's inception has not paused on them
when scanning through a document. Instead, these are visible when pausing on a
child of such an element, but otherwise not seen.
In this patch the HTML Processor starts exposing those implicitly-created nodes,
including opening tags, and closing tags, that aren't foudn in the text content
of the HTML input document.
Previously, the sequence of matched tokens when scanning with
`WP_HTML_Processor::next_token()` would depend on how the HTML document was written,
but with this patch, all semantically equal HTML documents will parse and scan in
the same exact manner, presenting an idealized or "perfect" view of the document
the same way as would occur when traversing a DOM in a browser.
Developed in https://github.com/WordPress/wordpress-develop/pull/6348
Discussed in https://core.trac.wordpress.org/ticket/61348
Props audrasjb, dmsnell, gziolo, jonsurrell.
Fixes#61348.
Built from https://develop.svn.wordpress.org/trunk@58304
git-svn-id: http://core.svn.wordpress.org/trunk@57761 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Provides a custom decoder for strings coming from HTML attributes and
markup. This custom decoder is necessary because of deficiencies in
PHP's `html_entity_decode()` function:
- It isn't aware of 720 of the possible named character references in
HTML, leaving many out that should be translated.
- It isn't aware of the ambiguous ampersand rule, which allows
conversion of character references in certain contexts when they
are missing their closing `;`.
- It doesn't draw a distinction for the ambiguous ampersand rule
when decoding attribute values instead of markup values.
- Use of `html_entity_decode()` requires manually passing non-default
paramter values to ensure it decodes properly.
This decoder also provides some conveniences, such as making a
single-pass and interruptable decode operation possible. This will
provide a number of opportunities to optimize detection and decoding
of things like value prefixes, and whether a value contains a given
substring.
Developed in https://github.com/WordPress/wordpress-develop/pull/6387
Discussed in https://core.trac.wordpress.org/ticket/61072
Props dmsnell, gziolo, jonsurrell, jorbin, westonruter, zieladam.
Fixes#61072.
Built from https://develop.svn.wordpress.org/trunk@58281
git-svn-id: http://core.svn.wordpress.org/trunk@57741 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Updated the global styles endpoints in the REST API to extend from existing posts and revisions controllers. This reduces duplicated code and inconsistencies. The revisions controller is now a subclass of the `WP_REST_Revisions_Controller`. Related redundant methods were removed and schema generation and collection parameters were adjusted to suit the global styles context. Updated permission checks, constructor, and collection parameters accordingly. This change allows for easy override of these classes using the `register_post_type_args` filter.
This reintroduces [57624] (reverted in [57628]) with improved backward compatibility and further enhancements.
Props ramonopoly, spacedmonkey, mukesh27, swissspidy.
Fixes#60131.
Built from https://develop.svn.wordpress.org/trunk@58225
git-svn-id: http://core.svn.wordpress.org/trunk@57688 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This caused issues in maintenance mode, and it's not warranted to have
its own module. This will live alongside `_canonical_charset()`, it's
partner function.
Fixes: #61182.
Props: dmsnell, sergeybiryukov, swisspiddy.
Follow-up to: [58148].
Built from https://develop.svn.wordpress.org/trunk@58169
git-svn-id: http://core.svn.wordpress.org/trunk@57632 1a063a9b-81f0-0310-95a4-ce76da25c4cd
There are several exist places in Core that attempt to detect if a blog charset
is UTF-8. Each place attempts to perform the same check, except the logic is
spread throughout and there's no single method provided to make this
determination in a consistent way. The `_canonical_charset()` method exists,
but is marked private for use.
In this patch the new `unicode` module provides `is_utf8_charset()` as a method
taking an optional charset slug and indicating if it represents UTF-8,
examining all of the allowable variants of that slug. Associated code is
updated to use this new function, including `_canonical_charset()`. If no slug
is provided, it will look up the current `get_option( 'blog_charset' )`.
Finally, the test functions governing `_canonical_charset()` have been
rewritten as a single test with a data provider instead of as separate test
functions.
Developed in https://github.com/WordPress/wordpress-develop/pull/6535
Discussed in https://core.trac.wordpress.org/ticket/61182Fixes#61182.
Props dmsnell, jonsurrell.
Built from https://develop.svn.wordpress.org/trunk@58147
git-svn-id: http://core.svn.wordpress.org/trunk@57612 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Removes the `WP_Translation_Controller::set_locale()` call from `wp-settings.php`, which happened before the current user was loaded.
That caused translations to be missing when the site locale and user locale were different, as the translation was associated with the wrong locale.
Turns out this call was not needed at all, as the locale will be set/updated when calling `load_textdomain()` anyway.
Props oglekler.
See #59656.
Built from https://develop.svn.wordpress.org/trunk@57704
git-svn-id: http://core.svn.wordpress.org/trunk@57205 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
Ensures that `wp_is_block_theme()` is not called too early before the themes are fully setup.
This addresses an issue where a parent theme was mistakenly marked as being missing.
Props scruffian, youknowriad, swissspidy, poena, dennysdionigi, bgardner, westonruter.
Fixes#60411.
Built from https://develop.svn.wordpress.org/trunk@57661
git-svn-id: http://core.svn.wordpress.org/trunk@57162 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Automatic deactivation of dependents with unmet dependencies requires a write operation to the database. This was performed during Core's bootstrap, which risked the database and cache becoming out-of-sync on sites with heavy traffic.
No longer loading plugins that have unmet requirements has not had a final approach decided core-wide, and is still in discussion in #60491 to be handled in a future release.
The `plugin_data` option, used to persistently store plugin data for detecting unmet dependencies during Core's bootstrap, is no longer needed.
Follow-up to [57545], [57592], [57606], [57617].
Props dd32, azaozz, swissspidy, desrosj, afragen, pbiron, zunaid321, costdev.
Fixes#60457. See #60491, #60510, #60518.
Built from https://develop.svn.wordpress.org/trunk@57658
git-svn-id: http://core.svn.wordpress.org/trunk@57159 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Updated the global styles endpoints in the REST API to extend from existing posts and revisions controllers. This reduces duplicated code and inconsistencies. The revisions controller is now a subclass of the WP_REST_Revisions_Controller. Related redundant methods were removed and schema generation and collection parameters were adjusted to suit the global styles context. Updated permission checks, constructor, and collection parameters accordingly. This change allows for easy override of these classes using the `register_post_type_args` filter.
Props ramonopoly, spacedmonkey, mukesh27.
Fixes#60131.
Built from https://develop.svn.wordpress.org/trunk@57624
git-svn-id: http://core.svn.wordpress.org/trunk@57125 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [57592], some `update_option()` calls were removed from bootstrapping. However, this also removed a check to ensure an array key existed, and populated it if not.
Scaffolding tests by WP-CLI revealed that a plugin in the `active_plugins` option may not have data already stored within the `plugin_data` option, causing a PHP warning for an undefined array key. This data will be added the next time `get_plugins()` is called.
This adds a condition to ensure the requirements checks are only performed on plugins whose data is already stored in the `plugin_data` option.
Follow-up to [57592].
Props swissspidy, hellofromTonya, costdev.
Fixes#60461.
Built from https://develop.svn.wordpress.org/trunk@57622
git-svn-id: http://core.svn.wordpress.org/trunk@57123 1a063a9b-81f0-0310-95a4-ce76da25c4cd
RE: Plugins Dependencies.
The following micro-optimization improvements are included for finding each plugin's file relative to the plugins' directory within `wp-settings.php`:
* Move `trailingslashit()` before `foreach()`.
The path to the plugin directory is a constant. Invoking the `trailingslashit()` within the loop for each plugin is unnecessary and less performant.
This commit moves the plugin directory logic to before the loop. The result: the logic will now run 1x instead of Px where P represents the number of active and valid plugins to be loaded.
* Use `substr()` instead of `str_replace()` to extract the plugin's file relative to the plugins' directory.
`substr()` is more performant than `str_replace()`.
Why?
Per the PHP handbook:
>"This function returns a string or an array with all occurrences of search in subject replaced with the given replace value."
`str_replace()` searches the entire string to find and replace each substring occurrence.
whereas
>"Returns the portion of string specified by the offset and length parameters."
`substr()` starts at the given offset and stops at the given (or end of the) string length.
In other words, `substr()` iterates over less of and only a specific portion of the given input string, whereas `str_replace()` iterates through the entire string searching for matches (plural).
References:
* `str_replace()` https://www.php.net/manual/en/function.str-replace.php
* `substr()` https://www.php.net/manual/en/function.substr.php
* `strlen()` https://www.php.net/manual/en/function.strlen.php
* Show the comparison in action https://3v4l.org/TbQ9U.
Follow-up to [57545], [57592].
Props hellofromTonya, costdev.
Fixes#60510.
Built from https://develop.svn.wordpress.org/trunk@57606
git-svn-id: http://core.svn.wordpress.org/trunk@57107 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[57545] introduced the Plugin Dependencies feature, which contains a new `plugin_data` option.
Previously, the `plugin_data` option was being updated during bootstrap and in `get_plugins()`, causing an error when using the install script as the options database table does not yet exist, and also risked an "out of sync" issue between the database and the cache on websites with heavy traffic.
This removes the calls to `update_option()` during Core's bootstrap, and guards the call in `get_plugins()` to ensure that it doesn't run when WordPress is installing.
Follow-up to [57545].
Props desrosj, swisspidy, huzaifaalmesbah, afragen, dd32, azaozz, costdev.
Fixes#60461. See #60457, #60491.
Built from https://develop.svn.wordpress.org/trunk@57592
git-svn-id: http://core.svn.wordpress.org/trunk@57093 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This commits add three endpoints to retrieve and manipulate fonts in WordPress.
This commit also means that we now have a fully functional Font Library in the site editor.
Props get_dave, youknowriad, mmaattiiaass, grantmkin, swissspidy, mcsf, jorbin, ocean90.
See #59166.
Built from https://develop.svn.wordpress.org/trunk@57548
git-svn-id: http://core.svn.wordpress.org/trunk@57049 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces a new "Requires Plugins" plugin header so that plugin developers can list the slugs of the plugins theirs depends on.
This will inform users of the requirements, and provide links to the WordPress.org Plugins Repository that they can click to install and activate the dependencies first.
Plugins whose requirements are not met cannot be installed or activated, and they will be deactivated automatically if their requirements become unmet.
Plugins that others rely on cannot be deactivated or deleted until their dependent plugins are deactivated or deleted.
In memory of Alex Mills and Alex King.
WordPress Remembers.
Props ahoereth, afragen, alanfuller, alexkingorg, amykamala, anonymized_10690803, apeatling, ashfame, atimmer, audrasjb, aristath, azaozz, batmoo, beaulebens, blobaugh, bobbingwide, boonebgorges, brianhenryie, chanthaboune, chrisdavidmiles, coolmann, costdev, courane01, danielbachhuber, davidperez, dd32, Denis-de-Bernardy, dingo_d, DJPaul, dougal, DrewAPicture, ethitter, filosofo, georgestephanis, giuseppemazzapica-1, goldenapples, griffinjt, hellofromTonya, husobj, ideag, jarednova, jbobich, jbrinley, jltallon, joedolson, johnciacia, johnjamesjacoby, joppuyo, jsmoriss, karmatosed, kebbet, knutsp, kraftbj, kraftner, kurtpayne, lkraav, logikal16, luisherranz, man4toman, markjaquith, matt, mbijon, megphillips91, mikeschinkel, mordauk, morehawes, mrwweb, mte90, mukesh27, mzaweb, nacin, norcross, nvwd, nwjames, obliviousharmony, ocean90, oglekler, paaljoachim, pauldewouters, pbaylies, pbiron, peterwilsoncc, Philipp15b, poena, pogidude, retlehs, rmccue, ryan, sabreuse, sc0ttkclark, scribu, sereedmedia, SergeyBiryukov, ShaneF, shidouhikari, soean, spacedmonkey, stephenh1988, swissspidy, taylorde, tazotodua, threadi, TimothyBlynJacobs, TJNowell, tollmanz, toscho, tropicalista, Viper007Bond, westi, whiteshadow, williamsba1, wpsmith, ZaneMatthew.
Fixes#22316.
Built from https://develop.svn.wordpress.org/trunk@57545
git-svn-id: http://core.svn.wordpress.org/trunk@57046 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
It fixes the coding style issues reported. It goes further and improves the code quality it other places where the logic for block bindings was added.
Follow-up for [57514].
Props: gziolo, mukesh27, youknowriad, santosguillamot.
See #60282.
Built from https://develop.svn.wordpress.org/trunk@57526
git-svn-id: http://core.svn.wordpress.org/trunk@57027 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This introduces the Block Bindings API for WordPress.
The API allows developers to connects block attributes to different sources. In this PR, two such sources are included: "post meta" and "pattern". Attributes connected to sources can have their HTML replaced by values coming from the source in a way defined by the binding.
Props czapla, lgladdy, gziolo, sc0ttkclark, swissspidy, artemiosans, kevin940726, fabiankaegy, santosguillamot, talldanwp, wildworks.
Fixes#60282.
Built from https://develop.svn.wordpress.org/trunk@57514
git-svn-id: http://core.svn.wordpress.org/trunk@57015 1a063a9b-81f0-0310-95a4-ce76da25c4cd
It is part of the sync from the Gutenberg plugin that introduces the registry for block binding sources required for the new Block Bindings API: WordPress/gutenberg#54536.
See #60282.
Follow-up [57373].
Props czapla, artemiosans, santosguillamot, sc0ttkclark, lgladdy, talldanwp, swissspidy, youknowriad, fabiankaegy, mukesh27.
Built from https://develop.svn.wordpress.org/trunk@57375
git-svn-id: http://core.svn.wordpress.org/trunk@56881 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This introduces a more lightweight library for loading `.mo` translation files which offers increased speed and lower memory usage.
It also supports loading multiple locales at the same time, which makes locale switching faster too.
For plugins interacting with the `$l10n` global variable in core, a shim is added to retain backward compatibility with the existing `pomo` library.
In addition to that, this library supports translations contained in PHP files, avoiding a binary file format and leveraging OPCache if available.
If an `.mo` translation file has a corresponding `.l10n.php` file, the latter will be loaded instead.
This behavior can be adjusted using the new `translation_file_format` and `load_translation_file` filters.
PHP translation files will be typically created by downloading language packs, but can also be generated by plugins.
See https://make.wordpress.org/core/2023/11/08/merging-performant-translations-into-core/ for more context.
Props dd32, swissspidy, flixos90, joemcgill, westonruter, akirk, SergeyBiryukov.
Fixes#59656.
Built from https://develop.svn.wordpress.org/trunk@57337
git-svn-id: http://core.svn.wordpress.org/trunk@56843 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Loading a list of language file paths using `glob()` can be expensive if involving thousands of files.
Expands scope of `WP_Textdomain_Registry` to cache list of language file paths in object cache and provides a way to invalidate that cache upon translation updates. Plugins can clear the cache using calls such as `wp_cache_delete( 'cached_mo_files_' . md5( $path ), 'translations' );`
Props mreishus, swissspidy
Fixes#58919
Built from https://develop.svn.wordpress.org/trunk@57287
git-svn-id: http://core.svn.wordpress.org/trunk@56793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset adds a new API for WordPress, designed to work with native ES Modules and Import Maps. It introduces functions such as `wp_register_module`, and `wp_enqueue_module`.
The API aims to provide a familiar experience to the existing `WP_Scripts` class, offering similar functionality. However, **it's not intended to duplicate the exact functionality of `WP_Scripts`**; rather, it is carefully tailored to address the specific needs and capabilities of ES modules.
For this initial version, **the current proposal is intentionally simplistic**, covering only the essential features needed to work with ES modules. Other enhancements and optimizations can be added later as the community identifies additional requirements and use cases.
== Differences Between WP_Script_Modules and WP_Scripts
=== Dependency Specification
With `WP_Script_Modules`, the array of dependencies supports not only strings but also arrays that include the dependency import type (`static` or `dynamic`). This design choice allows for future extensions of dependency properties, such as adding a `version` property to support "scopes" within import maps.
=== Module Identifier
Instead of a handle, `WP_Script_Modules` utilizes the module identifier, aligning with the module identifiers used in JavaScript files and import maps.
=== Deregistration
There is no equivalent of `wp_deregister_script` at this stage.
== API
=== `wp_register_module( $module_identifier, $src, $deps, $version )`
Registers a module.
{{{
// Registers a module with dependencies and versioning.
wp_register_module(
'my-module',
'/path/to/my-module.js',
array( 'static-dependency-1', 'static-dependency-2' ),
'1.2.3'
);
}}}
{{{
// my-module.js
import { ... } from 'static-dependency-1';
import { ... } from 'static-dependency-2';
// ...
}}}
{{{
// Registers a module with a dynamic dependency.
wp_register_module(
'my-module',
'/path/to/my-module.js',
array(
'static-dependency',
array(
'id' => 'dynamic-dependency',
'import' => 'dynamic'
),
)
);
}}}
{{{
// my-module.js
import { ... } from 'static-dependency';
// ...
const dynamicModule = await import('dynamic-dependency');
}}}
=== `wp_enqueue_module( $module_identifier, $src, $deps, $version )`
Enqueues a module. If a source is provided, it will also register the module.
{{{
wp_enqueue_module( 'my-module' );
}}}
=== `wp_dequeue_module( $module_identifier )`
Dequeues a module.
{{{
wp_dequeue_module( 'my-module' );
}}}
== Output
- When modules are enqueued, they are printed within script tags containing `type="module"` attributes.
- Additionally, static dependencies of enqueued modules utilize `link` tags with `rel="modulepreload"` attributes.
- Lastly, an import map is generated and inserted using a `<script type="importmap">` tag.
{{{
<script type="module" src="/path/to/my-module.js" id="my-module"></script>
<link rel="modulepreload" href="/path/to/static-dependency.js" id="static-dependency" />
<script type="importmap">
{
"imports": {
"static-dependency": "/path/to/static-dependency.js",
"dynamic-dependency": "/path/to/dynamic-dependency.js"
}
}
</script>
}}}
== Import Map Polyfill Requirement
Even though all major browsers already support import maps, an import map polyfill is required until the percentage of users using old browser versions without import map support drops significantly.
This work is ongoing and will be added once it's ready. Progress is tracked in #60232.
Props luisherranz, idad5, costdev, neffff, joemcgill, jorbin, swissspidy, jonsurrell, flixos90, gziolo, westonruter.
Fixes#56313.
Built from https://develop.svn.wordpress.org/trunk@57269
git-svn-id: http://core.svn.wordpress.org/trunk@56775 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The Template and Template Part REST API controllers have unique characteristics compared to other post type REST API controllers. They do not rely on integer IDs to reference objects; instead, they use a combination of the theme name and slug of the template, like 'twentytwentyfour//home.' Consequently, when the post types template and template part were introduced in [52062], it led to the registration of REST API endpoints for autosaves and revisions with invalid URL structures.
In this commit, we introduce new functionality to enable custom autosave and revisions endpoints to be registered at the post type level. Similar to the 'rest_controller_class' parameter, developers can now define 'revisions_rest_controller' and 'autosave_rest_controller.' This empowers developers to create custom controllers for these functionalities. Additionally, we introduce a 'late_route_registration' parameter, which proves helpful when dealing with custom URL patterns and regex pattern matching issues.
This commit registers new classes for template and template part autosave and revisions controllers, differentiating them from standard controllers in the following ways:
* The response shape now matches that of the template controller.
* Permission checks align with the template controller.
* A custom URL pattern is introduced to support slug-based identification of templates.
Furthermore, we've updated the utility function '_build_block_template_result_from_post' to support passing revision post objects. This enhancement ensures compatibility with the custom revisions controller.
Props spacedmonkey, revgeorge, andraganescu, hellofromTonya, antonvlasenko, kadamwhite, ironprogrammer, costdev, mukesh27, timothyblynjacobs, adamsilverstein.
Fixes 56922.
Built from https://develop.svn.wordpress.org/trunk@56819
git-svn-id: http://core.svn.wordpress.org/trunk@56331 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
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
This patch introduces the //first// of //many// iterations on the evolution of the HTML API, the HTML Processor, which is built in order to understand HTML structure including nesting, misnesting, and complicated semantic rules.
In the first iteration, the HTML Processor is arbitrarily limited to a minimal subset of functionality so that we can review it, ship it, test it, and collect feedback before moving forward. This means that this patch is more or less an extension to the Tag Processor query language, providing the ability not only to scan for a tag of a given name, but also to find an HTML element in a specific nesting path.
The HTML Processor also aborts any time it encounters:
- a tag that isn't a `P`, `DIV`, `FIGURE`, `FIGCAPTION`, `IMG`, `STRONG`, `B`, `EM`, `I`, `A`, `BIG`, `CODE`, `FONT`, `SMALL`, `STRIKE`, `TT`, or `U` tag. this limit exists because many HTML elements require specific rules and we are trying to limit the number of rules introduced at once. this work is targeted at existing work in places like the image block.
- certain misnesting constructs that evoke complicated resolution inside the HTML spec. where possible and where simple to do reliably, certain parse errors are handled. in most cases the HTML Processor aborts.
The structure of the HTML Processor is established in this patch. Further spec-compliance comes through filling out //more of the same// kind and nature of code as is found in this patch. Certain critical HTML algorithms are partially supported, and where support requires more than is present, the HTML Processor acknowledges this and refuses to operate.
In this patch are explorations for how to verify that new HTML support is fully added (instead of allowing for partial updates that leave some code paths non-compliant). Performance is hard to measure since support is so limited at the current time, but it should generally follow the performance of the Tag Processor somewhat close as the overhead is minimized as much as practical.
Props dmsnell, zieladam, costdev.
Fixes#58517.
Built from https://develop.svn.wordpress.org/trunk@56274
git-svn-id: http://core.svn.wordpress.org/trunk@55786 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This allows for using polyfill functions if `src/index.php` is the entry point (this file exists as a reminder to build the assets, and is different from the actual `index.php` file that gets built and boots WordPress).
Includes:
* Moving the check for the required PHP and MySQL versions earlier.
* Making the load order consistent between `src/index.php`, `wp-load.php`, and `wp-settings.php`.
Follow-up to [46183], [56006], [56007].
Props westonruter, Presskopp, joemcgill, SergeyBiryukov.
See #58206.
Built from https://develop.svn.wordpress.org/trunk@56241
git-svn-id: http://core.svn.wordpress.org/trunk@55753 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds a nonce so that activation works for block theme previews. Temporary fix until there is a REST API endpoint for activating themes.
Props scruffian, peterwilsoncc, nithins53, nithi22, jomonthomaslobo1, poena, syamraj24, vivekawsm, mrinal013.
Fixes#58712.
Built from https://develop.svn.wordpress.org/trunk@56199
git-svn-id: http://core.svn.wordpress.org/trunk@55711 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Felix Arntz
hellofromTonya
noisysocks
dmsnell
desrosj
isabel_brison
Pascal Birchler
Sergey Biryukov
Joe McGill
costdev
davidbaumwald
spacedmonkey
gziolo
youknowriad
Bernhard Reiter
audrasjb