When `next_token()` was introduced, it introduced a regression in the HTML
Processor whereby void tags remain on the stack of open elements when they
shouldn't. This led to invalid values returned from `get_breadcrumbs()`.
The reason was that calling `next_token()` works through a different code path
than the HTML Processor runs everything else. To solve this, its sub-classed
`next_token()` called `step( self::REPROCESS_CURRENT_TOKEN )` so that the proper
HTML accounting takes place.
Unfortunately that same reprocessing code path skipped the step whereby void
and self-closing elements are popped from the stack of open elements.
In this patch, that step is run with a third mode for `step()`, which is the
new `self::PROCESS_CURRENT_TOKEN`. This mode acts as if `self::PROCESS_NEXT_NODE`
were called, except it doesn't advance the parser.
Developed in https://github.com/WordPress/wordpress-develop/pull/5975
Discussed in https://core.trac.wordpress.org/ticket/60382
Follow-up to [57348]
Props dmsnell, jonsurrell
Fixes#60382
git-svn-id: https://develop.svn.wordpress.org/trunk@57507 602fd350-edb4-49c9-b593-d223f7449a82
When `next_token()` was introduced to the HTML Tag Processor, it started
classifying comments that look like they were intended to be CDATA sections.
In one of the changes made during development, however, a typo slipped
through code review that treated comments as CDATA even if they only
ended in `]>` and not the required `]]>`.
The consequences of this defect were minor because in all cases these are
treated as HTML comments from invalid syntax, but this patch adds the
missing check to ensure the proper reporting of CDATA-lookalikes.
Follow-up to [57348]
Props jonsurrell
Fixes#60406
git-svn-id: https://develop.svn.wordpress.org/trunk@57506 602fd350-edb4-49c9-b593-d223f7449a82
Reverts the change for fallback string lookup due to a performance regression in the bad case scenario.
See #59656.
git-svn-id: https://develop.svn.wordpress.org/trunk@57505 602fd350-edb4-49c9-b593-d223f7449a82
Ensures localization continues to work as expected with the new library in case
translations need to be loaded early in the process.
See #59656.
git-svn-id: https://develop.svn.wordpress.org/trunk@57504 602fd350-edb4-49c9-b593-d223f7449a82
This brings the function more in line with its related `wp_scripts()` and `wp_styles()` functions and makes it easier to reset the class instance in tests.
Props westonruter, luisherranz.
See #56313.
git-svn-id: https://develop.svn.wordpress.org/trunk@57503 602fd350-edb4-49c9-b593-d223f7449a82
This renames the Comments template part to 'Comments Template Part', to reduce confusion with the 'Comments' block when viewing both in the inserter.
Props mikachan, mukesh27, poena.
Fixes#56999.
git-svn-id: https://develop.svn.wordpress.org/trunk@57502 602fd350-edb4-49c9-b593-d223f7449a82
It brings with a set of iterations and follow-ups to the initial package update.
It also fixes a regression that happened for interactive blocks.
Props gziolo, luisherranz, cbravobernal.
See #60315.
git-svn-id: https://develop.svn.wordpress.org/trunk@57499 602fd350-edb4-49c9-b593-d223f7449a82
WP_Theme_JSON sanitization is now able to sanitize data contained on indexed arrays.
So certain data from theme.json, for example, settings.typography.fontFamilies which is a JSON array will be sanitized.
Props mmaattiiaass, mukesh27.
Fixes#60360.
git-svn-id: https://develop.svn.wordpress.org/trunk@57496 602fd350-edb4-49c9-b593-d223f7449a82
Adds a route for single global styles revisions: /wp/v2/global-styles/${ parentId }/revisions/${ revisionsId }
This fixes the `getRevision` actions in the core-data package.
Props ramonopoly, get_dave.
Fixes#59810.
git-svn-id: https://develop.svn.wordpress.org/trunk@57494 602fd350-edb4-49c9-b593-d223f7449a82
Adds front end rendering logic for the `dimensions.aspectRatio` block support as well as the required logic in `WP_Theme_JSON` and the style engine.
Props andrewserong.
Fixes#60365.
git-svn-id: https://develop.svn.wordpress.org/trunk@57491 602fd350-edb4-49c9-b593-d223f7449a82
When `next_token()` was introduced, it brought a subtle bug. When encountering a `<` in the HTML stream which did not lead to a tag or comment or other token, it was treating the full text span to that point as one text node, and the following span another text node.
The entire span should be one text node.
In this patch the Tag Processor properly detects this scenario and combines the spans into one text node.
Follow-up to [57348]
Props jonsurrell
Fixes#60385
git-svn-id: https://develop.svn.wordpress.org/trunk@57489 602fd350-edb4-49c9-b593-d223f7449a82
Ensures that looking up a singular that is also used as a pluralized string works as expected.
This improves compatibility for cases where for example both `__( 'Product' )` and `_n( 'Product', 'Products’, num )` are used in a project, where both will use the same translation for the singular version.
Although such usage is not really recommended nor documented, it must continue to work in the new i18n library in order to maintain backward compatibility and maintain expected behavior.
See #59656.
git-svn-id: https://develop.svn.wordpress.org/trunk@57386 602fd350-edb4-49c9-b593-d223f7449a82
Previous Gutenberg versions are not compatible with recent trunk because of the
WP_Navigation_Block_Renderer classname. It's present in both.
Gutenberg has been updated to avoid the use of this class but we need to auto-disable
old plugins to avoid fatals.
Props hellofromtonya.
See #60315.
git-svn-id: https://develop.svn.wordpress.org/trunk@57384 602fd350-edb4-49c9-b593-d223f7449a82
strpos was triggering a php warning.
This also updates the code to use the now supported str_contains.
Props get_dave, dmsnell, ocean90, mukesh27.
Fixes#60327.
git-svn-id: https://develop.svn.wordpress.org/trunk@57383 602fd350-edb4-49c9-b593-d223f7449a82
This patch, somewhat small brings a lot to WordPress.
This includes features like:
- DataViews.
- Customization tools like box shadow, background size and repeat.
- UI improvements in the site editor.
- Preferences sharing between the post and site editors.
- Unified panels and editors between post and site editors.
- Improved template mode in the post editor.
- Iterations to multiple interactive blocks.
- Preparing the blocks and UI for pattern overrides.
- and a lot more.
Props luisherranz, gziolo, isabel_brison, costdev, jonsurrell, peterwilsoncc, get_dave, antonvlasenko, desrosj.
See #60315.
git-svn-id: https://develop.svn.wordpress.org/trunk@57377 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@57375 602fd350-edb4-49c9-b593-d223f7449a82
This commit removes unnecessary access and internal annotations from two functions that are private and as such don't require the annotation. It also adds the since annotation with the 6.5 release given that the annotation may be useful.
Props swissspidy.
See #60358.
git-svn-id: https://develop.svn.wordpress.org/trunk@57374 602fd350-edb4-49c9-b593-d223f7449a82
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: https://github.com/WordPress/gutenberg/issues/54536.
See #60282.
Props czapla, artemiosans, santosguillamot, sc0ttkclark, lgladdy, talldanwp, swissspidy, youknowriad, fabiankaegy.
git-svn-id: https://develop.svn.wordpress.org/trunk@57373 602fd350-edb4-49c9-b593-d223f7449a82
For the new "All templates" UI to work properly we need the REST API to provide to additional fields original_source, and author_text.
Props ntsekouras, get_dave.
Fixes#60358.
git-svn-id: https://develop.svn.wordpress.org/trunk@57366 602fd350-edb4-49c9-b593-d223f7449a82
When we run composer format these changes are applied so I guess we should just commit them to avoid seeing the changes again the future.
git-svn-id: https://develop.svn.wordpress.org/trunk@57365 602fd350-edb4-49c9-b593-d223f7449a82
This updates the `caniuse-lite` database and includes all resulting CSS and built file changes, which are all minor changes due to fluctuations in browser usage.
Props gziolo, jonsurrell.
See #59657.
git-svn-id: https://develop.svn.wordpress.org/trunk@57363 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@57357 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@57354 602fd350-edb4-49c9-b593-d223f7449a82
More categories, better organization for patterns
as they grow and power more WordPress websites.
Props aaronrobertshaw, get_dave.
Fixes#60342.
git-svn-id: https://develop.svn.wordpress.org/trunk@57353 602fd350-edb4-49c9-b593-d223f7449a82
Theme.json stylesheets attempting to use a custom root selector are generated with in correct styles.
Props aaronrobertshaw, get_dave, mukesh27.
Fixes#60343.
git-svn-id: https://develop.svn.wordpress.org/trunk@57352 602fd350-edb4-49c9-b593-d223f7449a82
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
git-svn-id: https://develop.svn.wordpress.org/trunk@57348 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@57345 602fd350-edb4-49c9-b593-d223f7449a82
