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
Update the `@wordpress/block-serialization-default-parser` to 4.35.1 for WordPress 6.3 Beta 1. These changes split the following classes in to their own files in order to match the WordPress PHP coding standards:
* `WP_Block_Parser_Block`
* `WP_Block_Parser_Frame`
* `WP_Block_Parser`
These classes were previously all included in the `src/wp-includes/class-wp-block-parser.php` file. In order to maintain backward compatibly for developers requiring the file directly, the relocated classes are replaced with `require_once` calls in the original file.
In order to retain the commit history of the new files, they have been created using the `svn copy` command.
Props aristath, rajanpanchal2028, jrf, SergeyBiryukov, costdev, manfcarlo, spacedmonkey, mukesh27, isabel_brison, dd32.
Fixes#57832.
See #58623.
Built from https://develop.svn.wordpress.org/trunk@56048
git-svn-id: http://core.svn.wordpress.org/trunk@55560 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [55818] did a check to see if `WP_Metadata_Lazyloader` class existed and the loaded in the class file if it did not. However, require in wp-settings.php was not removed and resulted in the class being loaded twice. To be safe, only include the class file in meta.php and remove from wp-settings.php file.
Props spacedmonkey, ryelle.
See #58185.
Built from https://develop.svn.wordpress.org/trunk@55826
git-svn-id: http://core.svn.wordpress.org/trunk@55338 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[55230] introduced a regression to the content markup. This changeset is a partial revert to remove the added `wp-includes/block-supports/anchor.php` file.
The change of adding `'id'` to `$attributes_to_merge` in `get_block_wrapper_attributes()` is not reverted as this change did not impact the regression and helps to support continue development in Gutenberg for the anchor support in dynamic blocks feature.
Reference:
* [https://github.com/WordPress/gutenberg/pull/48592 Gutenberg PR 48592].
Follow-up [55230].
Props wildworks, mamaduka, hellofromTonya.
Fixes#57830.
See #56852.
Built from https://develop.svn.wordpress.org/trunk@55443
git-svn-id: http://core.svn.wordpress.org/trunk@54976 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In the Gutenberg plugin, a position block support feature was introduced last year, that allows a Group block to be set to a "sticky" position, meaning that when the page scrolls, the block will stick to the top of the window.
This change merges the "sticky" position feature for blocks introduced in Gutenberg 15.0.
Props andrewserong, flixos90, mukesh27.
Fixes#57618.
Built from https://develop.svn.wordpress.org/trunk@55285
git-svn-id: http://core.svn.wordpress.org/trunk@54818 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This commit adds block-level settings in the core. Block level settings allow a block to define the preset settings of its nested blocks using the same shape as theme.json.
Props oandregal, Mamaduka, jorgefilipecosta, dmsnell, adamziel.
57651 #57651.
Built from https://develop.svn.wordpress.org/trunk@55255
git-svn-id: http://core.svn.wordpress.org/trunk@54788 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This commit pulls in the HTML Tag Processor from the Gutenbeg repository.
The Tag Processor attempts to be an HTML5-spec-compliant parser that provides the ability in PHP to find specific HTML tags and then add, remove, or update attributes on that tag. It provides a safe and reliable way to modify the attribute on HTML tags.
More information: https://github.com/WordPress/wordpress-develop/pull/3920.
Props: antonvlasenko, bernhard-reiter, costdev, dmsnell, felixarntz, gziolo, hellofromtonya, zieladam, flixos90, ntsekouras, peterwilsoncc, swissspidy, andrewserong, onemaggie, get_dave, aristath, scruffian, justlevine, andraganescu, noisysocks, dlh, soean, cbirdsong, revgeorge, azaozz.
Fixes#57575.
Built from https://develop.svn.wordpress.org/trunk@55203
git-svn-id: http://core.svn.wordpress.org/trunk@54736 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The WordPress recovery mode only works in combination with the fatal error handler that works as the entry mode for recovery mode. The fatal error handler can be disabled using the `WP_DISABLE_FATAL_ERROR_HANDLER` constant, but so far the logic in the `WP_Recovery_Mode` class was still being initialized even when that constant was set to `true`, which is unnecessary.
This changeset updates the WordPress bootstrap process to only initialize `WP_Recovery_Mode` when needed.
Props costdev.
Fixes#56848.
Built from https://develop.svn.wordpress.org/trunk@55143
git-svn-id: http://core.svn.wordpress.org/trunk@54676 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This updates some inline comments to better match the guidelines and recommendations set forth in the make/core and make/docs handbooks:
> In general, use second person in your documentation. Second person depicts a friendly tone, with a perfect focus on the reader. In addition to this, directly addressing the reader helps avoid passive voice; thereby preventing unwanted confusion.
> ...
> the word “we” should be avoided (...) unless its made very clear which group is speaking.
Includes:
* Replacing first-person usage of "we" with second person point of view.
* Making small clarification adjustments where the voice is much too casual or lacks clear context, especially for non-native English speakers.
References:
* [https://make.wordpress.org/docs/style-guide/language-grammar/grammatical-person/ Style Guide: Grammatical person]
* [https://make.wordpress.org/docs/handbook/documentation-team-handbook/handbooks-style-and-formatting-guide/ Handbooks & HelpHub Style and Formatting Guide]
* [https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#style-and-substance Post & Comment Guidelines: Style and Substance]
Follow-up to [2176], [3430], [4676], [6009], [7991], [12688], [12762], [26008], [28978], [44488], [44962], [51979], [53131], [53132], [53156], [53131], [54200].
Props ironprogrammer, costdev, jorbin, SergeyBiryukov.
See #57052.
Built from https://develop.svn.wordpress.org/trunk@54866
git-svn-id: http://core.svn.wordpress.org/trunk@54418 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Pascal Birchler
Joe McGill
costdev
davidbaumwald
spacedmonkey
hellofromTonya
gziolo
youknowriad
Sergey Biryukov
Bernhard Reiter
isabel_brison
audrasjb
Peter Wilson
jorgefilipecosta
Andrew Ozz
Felix Arntz