This changes WordPress Core's Gutenberg integration from npm packages to checking out and building Gutenberg directly. Instead of syncing individual npm packages, Core now checks out the Gutenberg repository, builds it, and copies the build artifacts.
This enables Core to use Gutenberg's advanced features like route-based navigation, full-page rendering, and the Font Library, while also streamlining future updates.
New commands:
* `npm run gutenberg:checkout` - Clones Gutenberg at a specified ref
* `npm run gutenberg:build` - Runs Gutenberg's build process
* `npm run gutenberg:copy` - Copies and transforms build output to Core
* `npm run gutenberg:integrate` - Runs all three steps
Main changes:
* Removes webpack configs replaced by Gutenberg's build (blocks.js, packages.js, script-modules.js, development.js, vendors.js)
* Adds Font Library page (`/wp-admin/font-library.php`)
* Adds copy scripts to transform Gutenberg plugin paths to Core paths
* Moves vendor copy step from webpack to Gruntfile
New year, new process. Happy New Year!
Props youknowriad, ellatrix, sirreal, westonruter, desrosj, tellthemachines.
Fixes#64393.
Built from https://develop.svn.wordpress.org/trunk@61438
git-svn-id: http://core.svn.wordpress.org/trunk@60750 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Without this patch we would introduce the Abilities API without any core abilities being registered.
This patch includes the following initial abilities:
- core/get-bloginfo - Retrieve individual site information fields (name, description, url, wpurl, admin_email, charset, language, version).
- core/get-current-user-info - Get current authenticated user data (id, display_name, user_nicename, user_login, roles, locale).
- core/get-environment-type - Get WordPress environment type (production, staging, development, local).
Developed in #10411.
Follow-up [64098].
Props gziolo, jorgefilipecosta, mukesh27, isotropic, jorbin, justlevine, jason_the_adams.
Fixes#64146.
Built from https://develop.svn.wordpress.org/trunk@61063
git-svn-id: http://core.svn.wordpress.org/trunk@60399 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces a new REST API endpoint at `wp-abilities/v1/categories` to expose
ability categories through the WordPress REST API.
The new `WP_REST_Abilities_V1_Categories_Controller` provides:
- GET `/wp-abilities/v1/categories` - Lists all ability categories with pagination
- GET `/wp-abilities/v1/categories/{slug}` - Retrieves a single category by slug
Both endpoints require the `read` capability and return category data including
slug, label, description, and metadata. The collection endpoint supports pagination
with `page` and `per_page` parameters (default: 50, max: 100).
Developed in https://github.com/WordPress/wordpress-develop/pull/10380.
Follow-up [61032].
Props gziolo, jason_the_adams, timothyblynjacobs.
Fixes#64098.
Built from https://develop.svn.wordpress.org/trunk@61045
git-svn-id: http://core.svn.wordpress.org/trunk@60381 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Adds the `active_templates` setting, which is an object holding the template slug as a key and template post ID as the value.
* To maintain backwards compatibility, any `wp_template` (post type) not created through the new API will be activated.
* `get_block_template` and `get_block_templates` have been adjusted to check `active_templates`. These functions should never return inactive templates, just like before, to maintain backwards compatibility.
* The pre-existing `/templates` endpoint and sub-endpoints remain and work exactly as before.
* A new endpoint `/wp_template` has been added, but this is just a regular posts controller (`WP_REST_Posts_Controller`). We do register an additional `theme` field and expose the `is_wp_suggestion` meta.
* Another new endpoint `/wp_registered_template` has been added, which is read-only and lists the registered templates from themes and plugin (un-edited, without activations applied).
These changes are to be iterated on.
See https://github.com/WordPress/wordpress-develop/pull/8063.
Props ellatrix, shailu25, ntsekouras.
Fixes#62755.
Built from https://develop.svn.wordpress.org/trunk@61029
git-svn-id: http://core.svn.wordpress.org/trunk@60365 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add a new `core/term-data` source to make information about a taxonomy term available for use in Block Bindings.
Additionally, expose a post object's permalink through the `core/post-data` source.
Props bernhard-reiter, get_dave, jeryj, cbravobernal.
Fixes#64107.
Built from https://develop.svn.wordpress.org/trunk@60946
git-svn-id: http://core.svn.wordpress.org/trunk@60282 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is the fourth in a series of patches to modernize and standardize UTF-8 handling.
`wp_check_invalid_utf8()` has long been dependent on the runtime configuration of the system running it. This has led to hard-to-diagnose issues with text containing invalid UTF-8. The function has also had an apparent defect since its inception: when requesting to strip invalid bytes it returns an empty string.
This patch updates the function to remove all dependency on the system running it. It defers to the `mbstring` extension if that’s available, falling back to the new UTF-8 scanning pipeline.
To support this work, `wp_scrub_utf8()` is created with a proper fallback so that the remaining logic inside of `wp_check_invalid_utf8()` can be minimized. The defect in this function has been fixed, but instead of stripping the invalid bytes it will replace them with the Unicode replacement character for stronger security guarantees.
Developed in https://github.com/WordPress/wordpress-develop/pull/9498
Discussed in https://core.trac.wordpress.org/ticket/63837
Follow-up to: [60768].
Props askapache, chriscct7, Cyrille37, desrosj, dmsnell, helen, jonsurrell, kitchin, miqrogroove, pbearne, shailu25.
Fixes#63837, #29717.
See #63863.
Built from https://develop.svn.wordpress.org/trunk@60793
git-svn-id: http://core.svn.wordpress.org/trunk@60129 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is the second in a series of patches to modernize and standardize UTF-8 handling.
When the fallback UTF-8 validation code was added it was placed inside formatting.php; however, that validation logic can be reused for a number of related UTF-8 functions. To faciliate this it should move into a new location and be loaded early. This patch is the first half of doing that, whereby the original fallback function is moved unchanged to the `compat-utf8.php` module. The follow-up patch will abstract the UTF-8 scanning logic for reuse. Splitting this into a move and a separate change involves an extra step, but faciliates tracking the heritage of the code through the changes.
Developed in https://github.com/WordPress/wordpress-develop/pull/9825
Discussed in https://core.trac.wordpress.org/ticket/63863
Follow-up to: [60630].
See #63863.
Built from https://develop.svn.wordpress.org/trunk@60743
git-svn-id: http://core.svn.wordpress.org/trunk@60079 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add a new Block Bindings source, `core/post-data`, which exposes `date` and `modified` fields for now -- reflecting the publish date and the last modified date of the post, respectively. The source could be subsequently extended to include other fields associated with a post object, such as title, featured image, etc.
Props bernhard-reiter.
Closes#63741.
Built from https://develop.svn.wordpress.org/trunk@60539
git-svn-id: http://core.svn.wordpress.org/trunk@59875 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds server-side registration for `ariaLabel` block support and its required fields. Fully enabling feature support for dynamic blocks and consumers using `ServerSideRender` component.
Props wildworks, fabiankaegy, joemcgill, poena.
Fixes#62919.
Built from https://develop.svn.wordpress.org/trunk@59925
git-svn-id: http://core.svn.wordpress.org/trunk@59267 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset adds support for the Speculation Rules API and configures it by default to `prefetch` certain links with an eagerness of `conservative`, leading to improved performance by starting to load URLs before the user lands on them.
The new `WP_Speculation_Rules` class is a container class representing the set of used speculation rules. By default, WordPress Core will only add a single speculation rule, which results in most links being prefetched conservatively.
The behavior of that main speculation rule can be altered by using the new `wp_speculation_rules_configuration` filter, which receives an associative array with `mode` and `eagerness` keys, or `null`. Both `mode` and `eagerness` have a default value of `auto`, which for now will result in the aforementioned behavior. The value `null` is used by default in certain scenarios such as when the current user is logged in. Developers can explicitly provide supported mode values (`prefetch` or `prerender`) and other supported eagerness values (`conservative`, `moderate`, or `eager`) to override and enforce the respective behaviors, or return `null` to disable speculative loading feature (either unconditionally or for certain situations). The Speculative Loading feature plugin for example, which this feature is based on, will make use of this filter to continue to use mode `prerender` and eagerness `moderate` by default. Developers can call the `wp_get_speculation_rules_configuration()` function to check how speculative loading is configured on the WordPress site.
Another important filter introduced is `wp_speculation_rules_href_exclude_paths`, which allows to expand the list of URL patterns that are excluded from being prefetched or prerendered per WordPress Core's main speculation rule configuration. Several URL patterns such `/wp-admin/*` (any URL within WP Admin) or `/*\\?(.+)` (any URL that includes query parameters) are already excluded by default. Plugins that use content that would be preferable not to prefetch or prerender can use the filter to provide corresponding URL patterns.
More advanced customization is possible by adding further speculation rules that will be loaded in addition to WordPress Core's main speculation rule. This can be achieved via the new `wp_load_speculation_rules` action, which receives the `WP_Speculation_Rules` class instance and can amend it as needed.
Props flixos90, westonruter, joemcgill, desrosj, mukesh27, tunetheweb, thelovekesh, adamsilverstein, swissspidy, domenicdenicola, jeremyroman.
Fixes#62503.
Built from https://develop.svn.wordpress.org/trunk@59837
git-svn-id: http://core.svn.wordpress.org/trunk@59179 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This extension provides the `hash()` function and support for the SHA-256 algorithm, both of which are required for upcoming security related changes. This extension is almost universally enabled, however it is technically possible to disable it on PHP 7.2 and 7.3, hence the introduction of this requirement and the corresponding requirement checks prior to installing or upgrading WordPress.
Props peterwilsoncc, ayeshrajans, dd32, SergeyBiryukov, johnbillion.
Fixes#60638, #62815, #56017
See #21022
Built from https://develop.svn.wordpress.org/trunk@59803
git-svn-id: http://core.svn.wordpress.org/trunk@59145 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Partially reverts [59479] and [59461], which previously tried to move some functions from `wp-admin/includes/plugin.php` to `wp-includes/functions.php` so they are available early, so that `get_plugin_data()` can be used.
However, other functions from that file are often used by plugins without necessarily checking whether they are available, easily causing fatal errors. Requiring this file directly is a safer approach to avoid such errors.
Props peterwilsoncc, dd32, swissspidy, johnbillion.
Fixes#62244.
Built from https://develop.svn.wordpress.org/trunk@59488
git-svn-id: http://core.svn.wordpress.org/trunk@58874 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The file could declare its own `$theme` variable, which would override the one used in the `foreach` loop.
To prevent this, call `wp_get_theme()` before loading the file and store the instance in a different variable.
Props neo2k23, swissspidy.
See #62244.
Built from https://develop.svn.wordpress.org/trunk@59466
git-svn-id: http://core.svn.wordpress.org/trunk@58852 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In #34114, just-in-time (JIT) translation loading was implemented for projects hosted on WordPress.org. This is now expanded to all other plugins/themes.
Projects with a custom `Text Domain` and `Domain Path` header no longer need to call `load_plugin_textdomain()` or `load_theme_textdomain()`.
This reduces the risk of calling them too late, after some translation calls already happened, and generally makes it easier to properly internationalize a plugin or theme.
This moves the `get_plugin_data()` from `wp-admin/includes/plugin.php` to `wp-includes/functions.php` so it's available during the plugin loading process.
Props swissspidy.
Fixes#62244.
Built from https://develop.svn.wordpress.org/trunk@59461
git-svn-id: http://core.svn.wordpress.org/trunk@58847 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
