This updates the following third-party GitHub Actions to their latest versions:
- `actions/setup-node` from `3.8.1` to `4.0.1`
- `actions/upload-artifact` from `3.1.2` to `4.3.0`
- `shivammathur/setup-php` from `2.28.0` to `2.29.0`
- `actions/cache` from `3.3.2` to `4.0.0`
- `codecov/codecov-action` from `3.1.4` to `3.1.5`
Most notably, these updates silence newly encountered notices as a result of GitHub beginning to transition away from Node.js 16 to Node.js 20 (see https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/).
Props swissspidy.
See #59805.
Built from https://develop.svn.wordpress.org/trunk@57362
git-svn-id: http://core.svn.wordpress.org/trunk@56868 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Ensure logged out users are redirected to the media file when attachment pages are inactive. This removes the read_post capability check from the canonical redirects as anonymous users lack the permission.
This was previously committed in [57310] before being reverted in [57318]. This update includes a fix to cover instances where revealing a URL could be considered a data leak and greatly expands the unit tests to ensure that this is covered along with many other instances.
Follow-up to [56657], [56658], [56711], [57310], [57318].
Props peterwilsoncc, jorbin, afercia, aristath, chesio, joppuyo, jorbin, lakshmananphp, poena, sergeybiryukov, swissspidy, johnbillion.
Fixes#59866.
See #57913.
Built from https://develop.svn.wordpress.org/trunk@57357
git-svn-id: http://core.svn.wordpress.org/trunk@56863 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add a new `hooked_block_{$block_type}` filter that allows modifying a hooked block (in parsed block format) prior to insertion, while providing read access to its anchor block (in the same format).
This allows block authors to e.g. set a hooked block's attributes, or its inner blocks; the filter can peruse information about the anchor block when doing so. As such, this filter provides a solution to both #59572 and #60126.
The new filter is designed to strike a good balance and separation of concerns with regard to the existing [https://developer.wordpress.org/reference/hooks/hooked_block_types/ `hooked_block_types` filter], which allows addition or removal of a block to the list of hooked blocks for a given anchor block -- all of which are identified only by their block ''types''. This new filter, on the other hand, only applies to ''one'' hooked block at a time, and allows modifying the entire (parsed) hooked block; it also gives (read) access to the parsed anchor block.
Props gziolo, tomjcafferkey, andrewserong, isabel_brison, timbroddin, yansern.
Fixes#59572, #60126.
Built from https://develop.svn.wordpress.org/trunk@57354
git-svn-id: http://core.svn.wordpress.org/trunk@56860 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since its introduction in WordPress 6.2 the HTML Tag Processor has
provided a way to scan through all of the HTML tags in a document and
then read and modify their attributes. In order to reliably do this, it
also needed to be aware of other kinds of HTML syntax, but it didn't
expose those syntax tokens to consumers of the API.
In this patch the Tag Processor introduces a new scanning method and a
few helper methods to read information about or from each token. Most
significantly, this introduces the ability to read `#text` nodes in the
document.
What's new in the Tag Processor?
================================
- `next_token()` visits every distinct syntax token in a document.
- `get_token_type()` indicates what kind of token it is.
- `get_token_name()` returns something akin to `DOMNode.nodeName`.
- `get_modifiable_text()` returns the text associated with a token.
- `get_comment_type()` indicates why a token represents an HTML comment.
Example usage.
==============
{{{
<?php
function strip_all_tags( $html ) {
$text_content = '';
$processor = new WP_HTML_Tag_Processor( $html );
while ( $processor->next_token() ) {
if ( '#text' !== $processor->get_token_type() ) {
continue;
}
$text_content .= $processor->get_modifiable_text();
}
return $text_content;
}
}}}
What changes in the Tag Processor?
==================================
Previously, the Tag Processor would scan the opening and closing tag of
every HTML element separately. Now, however, there are special tags
which it only visits once, as if those elements were void tags without
a closer.
These are special tags because their content contains no other HTML or
markup, only non-HTML content.
- SCRIPT elements contain raw text which is isolated from the rest of
the HTML document and fed separately into a JavaScript engine. There
are complicated rules to avoid escaping the script context in the HTML.
The contents are left verbatim, and character references are not decoded.
- TEXTARA and TITLE elements contain plain text which is decoded
before display, e.g. transforming `&` into `&`. Any markup which
resembles tags is treated as verbatim text and not a tag.
- IFRAME, NOEMBED, NOFRAMES, STYLE, and XMP elements are similar to the
textarea and title elements, but no character references are decoded.
For example, `&` inside a STYLE element is passed to the CSS engine
as the literal string `&` and _not_ as `&`.
Because it's important not treat this inner content separately from the
elements containing it, the Tag Processor combines them when scanning
into a single match and makes their content available as modifiable
text (see below).
This means that the Tag Processor will no longer visit a closing tag for
any of these elements unless that tag is unexpected.
{{{
<title>There is only a single token in this line</title>
<title>There are two tokens in this line></title></title>
</title><title>There are still two tokens in this line></title>
}}}
What are tokens?
================
The term "token" here is a parsing term, which means a primitive unit in
HTML. There are only a few kinds of tokens in HTML:
- a tag has a name, attributes, and a closing or self-closing flag.
- a text node, or `#text` node contains plain text which is displayed
in a browser and which is decoded before display.
- a DOCTYPE declaration indicates how to parse the document.
- a comment is hidden from the display on a page but present in the HTML.
There are a few more kinds of tokens that the HTML Tag Processor will
recognize, some of which don't exist as concepts in HTML. These mostly
comprise XML syntax elements that aren't part of HTML (such as CDATA and
processing instructions) and invalid HTML syntax that transforms into
comments.
What is a funky comment?
========================
This patch treats a specific kind of invalid comment in a special way.
A closing tag with an invalid name is considered a "funky comment." In
the browser these become HTML comments just like any other, but their
syntax is convenient for representing a variety of bits of information
in a well-defined way and which cannot be nested or recursive, given
the parsing rules handling this invalid syntax.
- `</1>`
- `</%avatar_url>`
- `</{"wp_bit": {"type": "post-author"}}>`
- `</[post-author]>`
- `</__( 'Save Post' );>`
All of these examples become HTML comments in the browser. The content
inside the funky content is easily parsable, whereby the only rule is
that it starts at the `<` and continues until the nearest `>`. There
can be no funky comment inside another, because that would imply having
a `>` inside of one, which would actually terminate the first one.
What is modifiable text?
========================
Modifiable text is similar to the `innerText` property of a DOM node.
It represents the span of text for a given token which may be modified
without changing the structure of the HTML document or the token.
There is currently no mechanism to change the modifiable text, but this
is planned to arrive in a later patch.
Tags
====
Most tags have no modifiable text because they have child nodes where
text nodes are found. Only the special tags mentioned above have
modifiable text.
{{{
<div class="post">Another day in HTML</div>
└─ tag ──────────┘└─ text node ─────┘└────┴─ tag
}}}
{{{
<title>Is <img> > <image>?</title>
│ └ modifiable text ───┘ │ "Is <img> > <image>?"
└─ tag ─────────────────────────────┘
}}}
Text nodes
==========
Text nodes are entirely modifiable text.
{{{
This HTML document has no tags.
└─ modifiable text ───────────┘
}}}
Comments
========
The modifiable text inside a comment is the portion of the comment that
doesn't form its syntax. This applies for a number of invalid comments.
{{{
<!-- this is inside a comment -->
│ └─ modifiable text ──────┘ │
└─ comment token ───────────────┘
}}}
{{{
<!-->
This invalid comment has no modifiable text.
}}}
{{{
<? this is an invalid comment -->
│ └─ modifiable text ────────┘ │
└─ comment token ───────────────┘
}}}
{{{
<[CDATA[this is an invalid comment]]>
│ └─ modifiable text ───────┘ │
└─ comment token ───────────────────┘
}}}
Other token types also have modifiable text. Consult the code or tests
for further information.
Developed in https://github.com/WordPress/wordpress-develop/pull/5683
Discussed in https://core.trac.wordpress.org/ticket/60170
Follows [57575]
Props bernhard-reiter, dlh, dmsnell, jonsurrell, zieladam
Fixes#60170
Built from https://develop.svn.wordpress.org/trunk@57348
git-svn-id: http://core.svn.wordpress.org/trunk@56854 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Incremental import maps fail if the import map is printed after the module scripts.
This means, we should always render import maps first. This means that for classic themes, we need to move the import map and modules to the footer because we can't know before that which modules are needed.
Props luisherranz, cbravobernal.
Fixes#60240.
Built from https://develop.svn.wordpress.org/trunk@57345
git-svn-id: http://core.svn.wordpress.org/trunk@56851 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
Additionally, this changeset fixes some of the `block.json` and `theme.json` files in PHPUnit tests by adding missing `title` properties to satisfy the schema. Those changes have no impact on the runtime whatsoever and do not change the result of unit tests.
Note that some block and theme JSON files still aren't valid according to the schema. Fixing is underway; the required changes will be merged subsequently.
Props jonsurrell, dmsnell, gziolo.
Fixes#60255.
Built from https://develop.svn.wordpress.org/trunk@57336
git-svn-id: http://core.svn.wordpress.org/trunk@56842 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Renames all mentions to "module" with "script module", including function names, comments, and tests.
Follow up to [57269]
The list of functions renamed are:
- `wp_module()` -> `wp_script_module()`.
- `wp_register_module()` -> `wp_register_script_module()`.
- `wp_enqueue_module()` -> `wp_enqueue_script_module()`.
- `wp_dequeue_module()` -> `wp_dequeue_script_module()`.
- `WP_Script_Modules::print_enqueued_modules()` -> `WP_Script_Modules::print_enqueued_script_modules()`.
- `WP_Script_Modules::print_module_preloads()` -> `WP_Script_Modules::print_script_module_preloads()`.
It also adds PHP 7 typing to all the functions and improves the types of the `$deps` argument of `wp_register_script_module()` and `wp_enqueue_script_module()` using `@type`.
Props luisherranz, idad5, costdev, nefff, joemcgill, jorbin, swisspidy, jonsurrel, flixos90, gziolo, westonruter, bernhard-reiter, kamranzafar4343
See #56313
Built from https://develop.svn.wordpress.org/trunk@57327
git-svn-id: http://core.svn.wordpress.org/trunk@56833 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds support for the following HTML elements to the HTML Processor:
- PARAM, SOURCE, TRACK
Previously these elements were not supported and the HTML Processor would bail when encountering them. Now, with this patch applied, it will proceed to parse an HTML document when encountering those tags.
Props jonsurrell, dmsnell
Fixes#60283
Built from https://develop.svn.wordpress.org/trunk@57326
git-svn-id: http://core.svn.wordpress.org/trunk@56832 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This ensures that the message about deleting a plugin or having no plugins installed is displayed in full width.
Follow-up to [26134], [33016].
Props shailu25, mukesh27, passoniate, JavierCasares, sabernhardt.
Fixes#50069.
Built from https://develop.svn.wordpress.org/trunk@57321
git-svn-id: http://core.svn.wordpress.org/trunk@56827 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This patch adds newly supported elements to tests that should have been updated
in recent PRs, but which were merged without that. Those PRs removed failing
tests showing that the elements were unsupported, but did not add the elements
to the list of supported ones.
It also removes some elements from the special-exclusion list of unsupported IN
BODY elements. These did not present in failing tests because earlier
conditions in the switch structure caught the tags before hitting the default
block.
Finally it adds some missing elements to the list of void elements. These
elements are not listed as void in the HTML specification because they are
deprecated. However, they are treated as void for the sake of HTML
serialization and the parsing rules indicate that they behave as void elements,
so it's safe to list them within the HTML API as void.
Developed in WordPress/wordpress-develop#5913
Fixes#60307
Built from https://develop.svn.wordpress.org/trunk@57319
git-svn-id: http://core.svn.wordpress.org/trunk@56825 1a063a9b-81f0-0310-95a4-ce76da25c4cd
