The Tag Processor stores the byte-offsets into its HTML document where
the current token starts and ends, and also for every bookmark. In some
cases for tags, the end offset has been off by one.
In this patch the offset is fixed so that a bookmark always properly
refers to the full span of the token it's bookmarking. Also the current
token byte offsets are properly recorded.
While this is a defect in the Tag Processor, it hasn't been exposed
through the public interface and has not affected any of the working
of the processor. Only subclasses which rely on the length of a bookmark
have been potentially affected, and these are not supported environments
in the ongoing work.
This fix is important for future work and for ensuring that subclasses
performing custom behaviors remain as reliable as the public interface.
Developed in https://github.com/WordPress/wordpress-develop/pull/6625
Discussed in https://core.trac.wordpress.org/ticket/61301
Props dmsnell, gziolo, jonsurrell, westonruter.
Fixes#61301.
Built from https://develop.svn.wordpress.org/trunk@58233
git-svn-id: http://core.svn.wordpress.org/trunk@57696 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since [60428] the Tag Processor has been misidentifying single-character
funky comments. It has been asserting that the full token-length for a
funky comment must be at least three characters after the opening (e.g.
`</1>`), but it has been starting to look for the closing `>` after
those same three characters. This means that it has been skipping the
actual close of these funky comments and swallowing up the next syntax
until it finds a `>`, often consuming the next tag in the process.
This patch fixes the detector and restores finding the following token.
Developed in https://github.com/WordPress/wordpress-develop/pull/6412
Discussed in https://core.trac.wordpress.org/ticket/60170
Follow-up to [60428].
Fixes#60170.
Props dmsnell, gziolo, jonsurrell.
Built from https://develop.svn.wordpress.org/trunk@58040
git-svn-id: http://core.svn.wordpress.org/trunk@57506 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When making repeated updates to a document, the Tag Processor will end
up copying the entire document once for every update. This can lead to
catastrophic behavior in the worse case.
However, when batch-applying updates it's able to copy chunks of the
document in one thread and only end up copying the entire document once
for the entire batch.
Previously the Tag Processor has been eagerly applying udpates, but in
this patch it defers applying those updates as long as is possible.
Developed in https://github.com/WordPress/wordpress-develop/pull/6120
Discussed in https://core.trac.wordpress.org/ticket/60697
Props: dmsnell, bernhard-reiter, jonsurrell, westonruter.
Fixes#60697.
Follow-up to [55706], [56941], [57348].
Built from https://develop.svn.wordpress.org/trunk@57805
git-svn-id: http://core.svn.wordpress.org/trunk@57306 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When returning modifiable text in the HTML API, if the text segment
coerces to `false` inside `empty()`, then an empty string has been
returned instead of the string itself. For example, the text node in the
following HTML snippet:
{{{
<div>0</div>
}}}
In this patch the `empty()` check is removed. The purpose of the original
check was to skip further processing if the text content is empty, but
the check is not needed and the additioanl processing is minimal.
Removing the code removes the defect and leaves a cleaner method in its
absence.
Developed in https://github.com/WordPress/wordpress-develop/pull/6199
Follow-up to [57348]
Follow-up to #60170
Built from https://develop.svn.wordpress.org/trunk@57738
git-svn-id: http://core.svn.wordpress.org/trunk@57239 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A fix was introduced to the Tag Processor to ensure that contiguous text
in an HTML document emerges as a single text node spanning the full
sequence. Unfortunately, that patch was marginally over-zealous in
checking if a "<" started a syntax token or not. It used the following:
{{{
<?php
if ( 'A' <= $c && 'z' >= $c ) { ... }
}}}
This was based on the assumption that the A-Z and a-z letters are
contiguous in the ASCII range; they aren't, and there's a gap of
several characters in between. The result of this is that in some
cases the parser created a text boundary when it didn't need to.
Text boundaries can be surprising and can be created when reaching
invalid syntax, HTML comments, and more hidden elements, so
semantically this wasn't a major bug, but it was an aesthetic
challenge.
In this patch the check is properly compared for both upper- and
lower-case variants that could potentially form tag names.
{{{
<?php
if ( ( 'A' <= $c && 'Z' >= $c ) || ( 'a' <= $c && 'z' >= $c ) ) { ... }
}}}
This solves the problem and ensures that contiguous text appears
as a single text node when scanning tokens.
Developed in https://github.com/WordPress/wordpress-develop/pull/6041
Discussed in https://core.trac.wordpress.org/ticket/60385
Follow-up to [57489]
Props dmsnell, jonsurrell
Fixes#60385
Built from https://develop.svn.wordpress.org/trunk@57542
git-svn-id: http://core.svn.wordpress.org/trunk@57043 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
Built from https://develop.svn.wordpress.org/trunk@57506
git-svn-id: http://core.svn.wordpress.org/trunk@57007 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
Built from https://develop.svn.wordpress.org/trunk@57489
git-svn-id: http://core.svn.wordpress.org/trunk@56990 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
Currently the Tag Processor assumes that an input document is a ''full'' HTML document. Because of this, if there's lingering content after the last tag match it will treat that content as plaintext and skip over it. This is fine for the Tag Processor because if there is lingering content that isn't a valid tag then there's nothing for `next_tag()` to match.
However, in order to support a number of feature expansions it is important to recognize that the remaining content ''may'' involve partial syntax elements, such as incomplete tags, attributes, or comments.
In this patch we're adding a mode inside the Tag Processor which will flip when we start parsing HTML syntax but the document finishes before the token does. This will provide the ability to:
- extend the input document,
- avoid misinterpreting syntax as text, and
- guess if we have a complete document, know if we have an incomplete document.
In the process of building this patch a few fixes were identified and fixed in the Tag Processor, namely in the handling of incomplete syntax elements.
Props dmsnell, jonsurrell.
Fixes#60122, #60108.
Built from https://develop.svn.wordpress.org/trunk@57211
git-svn-id: http://core.svn.wordpress.org/trunk@56717 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Updates the internal representation of the text span coordinates. The mixture of (offset, length) and (start, end) coordinates becomes confusing, this commit replaces it with a (offset, length) pair. There should be no functional or behavioral changes in this patch. For the internal helper classes this patch introduces breaking changes, but those classes are marked private and should not be used outside of the HTML API itself.
Props dmsnell.
Fixes#59993.
Built from https://develop.svn.wordpress.org/trunk@57179
git-svn-id: http://core.svn.wordpress.org/trunk@56690 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The example code in the PHPDoc comment for the HTML Tag Processor class
previously showed calling `next_tag()` with an array containing a `class`
key, which should have been `class_name`. This patch fixes this by using
the appropriate `class_name` key.
Props dmsnell, gaambo, crstauf, atachibana, audrasjb, krupalpanchal.
Fixes#59891.
Built from https://develop.svn.wordpress.org/trunk@57116
git-svn-id: http://core.svn.wordpress.org/trunk@56627 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When applying updates to HTML, one step was left out in [56941] which updated the position of the end of the current tag. This made it possible to create bookmarks with null or earlier end positions than their start position. This in turn broke the Directive Processor in Gutenberg during the backport of changes from Core into Gutenberg.
In this commit, after applying updates, the HTML document is now scanned fully to the end of the current tag, updating the internal pointer to its end, so that nothing else will be broken or misaligned.
Follow-up to [56941].
Props dmsnell.
Fixes#59643.
Built from https://develop.svn.wordpress.org/trunk@56953
git-svn-id: http://core.svn.wordpress.org/trunk@56464 1a063a9b-81f0-0310-95a4-ce76da25c4cd
After modifying tags in the HTML API, the Tag Processor backs up to before the tag being modified and then re-parses its attributes. This saves on the code complexity involved in applying updates, which have already been transformed to “lexical updates” by the time they are applied.
In order to do that, `::get_updated_html()` called `::next_tag()` to reuse its logic. However, as a public method, subclasses may change the behavior of that method, and the HTML Processor does just this. It maintains an HTML stack of open elements and when the Tag Processor calls this method to re-scan a tag and its attributes, it leads to a broken stack.
This commit replaces the call to `::next_tag()` with a more appropriate reapplication of its internal parsing logic to rescan the tag name and its attributes. Given the limited nature of what's occurring in `::get_updated_html()`, this should bring with it certain guarantees that no HTML structure is being changed (that structure will only be changed by subclasses like the HTML Processor).
Follow-up to [56274], [56702].
Props dmsnell, zieladam, nicolefurlan.
Fixes#59607.
Built from https://develop.svn.wordpress.org/trunk@56941
git-svn-id: http://core.svn.wordpress.org/trunk@56452 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This patch adds two new public methods to the HTML Tag Processor:
- `has_class()` indicates if a matched tag contains a given CSS class name.
- `class_list()` returns a generator to iterate over all the class names in a matched tag.
Included in this patch is a refactoring of the internal logic when matching
a tag to reuse the new `has_class()` function. Previously it was relying on
optimized code in the `matches()` function which performed byte-for-byte
class name comparison. With the change in this patch it will perform class
name matching on the decoded value, which might differ if a class attribute
contains character references.
These methods may be useful for running more complicated queries based
on the presence or absence of CSS class names. The use of these methods
avoids the need to manually decode the class attribute as reported by
`$process->get_attribute( 'class' )`.
Props dmsnell.
Fixes#59209.
Built from https://develop.svn.wordpress.org/trunk@56703
git-svn-id: http://core.svn.wordpress.org/trunk@56215 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When encountering an HTML tag with duplicate copies of an attribute the tag processor ignores the duplicate values, according to the specification. However, when removing an attribute it must remove all copies of that attribute lest one of the duplicates becomes the primary and it appears as if no attributes were removed.
In this patch we're adding tests that will be used to ensure that all attribute copies are removed from a tag when one is request to be removed.
**Before**
{{{#!php
<?php
$p = new WP_HTML_Tag_Processor( '<br id=one id="two" id='three' id>' );
$p->next_tag();
$p->remove_attribute( 'id' );
$p->get_updated_html();
// <br id="two" id='three' id>
}}}
**After**
{{{#!php
<?php
$p = new WP_HTML_Tag_Processor( '<br id=one id="two" id='three' id>' );
$p->next_tag();
$p->remove_attribute( 'id' );
$p->get_updated_html();
// <br>
}}}
Previously we have been overlooking duplicate attributes since they don't have an impact on what parses into the DOM. However, as one unit test affirmed (asserting the presence of the bug in the tag processor) when removing an attribute where duplicates exist this meant we ended up changing the value of an attribute instead of removing it.
In this patch we're tracking the text spans of the parsed duplicate attributes so that ''if'' we attempt to remove them then we'll have the appropriate information necessary to do so. When an attribute isn't removed we'll simply forget about the tracked duplicates. This involves some overhead for normal operation ''when'' in fact there are duplicate attributes on a tag, but that overhead is minimal in the form of integer pairs of indices for each duplicated attribute.
Props dmsnell, zieladam.
Fixes#58119.
Built from https://develop.svn.wordpress.org/trunk@56684
git-svn-id: http://core.svn.wordpress.org/trunk@56196 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When encountering elements that imply switching into the RAWTEXT parsing state,
the Tag Processor should skip processing until exiting the RAWTEXT state.
In this patch the Tag Processor does just that, except for the case of the
deprecated XMP element which implies further and more complicated rules.
There's an implicit assumption that the SCRIPT ENABLED flag in HTML parsing
is enabled so that the contents of NOSCRIPT can be skipped. Otherwise, it would
be required to parse the contents of that tag.
Props dmsnell.
Fixes#59292.
Built from https://develop.svn.wordpress.org/trunk@56563
git-svn-id: http://core.svn.wordpress.org/trunk@56075 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 moves a reference link in `::get_attribute_names_with_prefix()` below the code example, so that it is correctly displayed in the Developer Resources.
Includes updating some other `@see` tags for consistency as per the documentation standards.
Additionally, the example code for `WP_HTML_Tag_Processor::get_tag()` is updated to show lowercase tag names in the input HTML, so that it does not convey the wrong impression that the uppercase output from `::get_tag()` depends on the case of the input HTML.
Follow-up to [55203].
Props dmsnell, johnbillion, audrasjb, SergeyBiryukov.
Fixes#58254.
Built from https://develop.svn.wordpress.org/trunk@55724
git-svn-id: http://core.svn.wordpress.org/trunk@55236 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [55718] the Unicode replacement character was mistakenly removed. The purpose of including the character was to communicate what it looks like and why the Tag Processor won't insert it into the document.
This changeset brings the character back and adds a small clue to fix the confusion that may lead to its removal.
Follow-up to [55718].
Props dmsnell.
Fixes#58256
See #57840.
Built from https://develop.svn.wordpress.org/trunk@55723
git-svn-id: http://core.svn.wordpress.org/trunk@55235 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A bug was discovered where where the parser wasn't returning to the
start of the affected tag after making some updates.
In few words, the Tag Processor has not been treating its own internal
pointer `bytes_already_parsed` the same way it treats its bookmarks.
That is, when updates are applied to the input document and then
`get_updated_html()` is called, the internal pointer transfers to
the newly-updated content as if no updates had been applied since
the previous call to `get_updated_html()`.
In this patch we're creating a new "shift accumulator" to account for
all of the updates that accrue before calling `get_updated_html()`.
This accumulated shift will be applied when swapping the input document
with the output buffer, which should result in the pointer pointing to
the same logical spot in the document it did before the udpate.
In effect this patch adds a single workaround for treating the
internal pointer like a bookmark, plus a temporary pointer which points
to the beginning of the current tag when calling `get_updated_html()`.
This will preserve the assumption that updating a document doesn't
move that pointer, or shift which tag is currently matched.
Props dmsnell, zieladam.
Fixes#58179.
Built from https://develop.svn.wordpress.org/trunk@55706
git-svn-id: http://core.svn.wordpress.org/trunk@55218 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Comments created by means of a tag closer with an invalid tag name, e.g. `</3>`.
- Comments closed with the invalid `--!>` closer. (Comments should be closed by `-->` but if the `!` appears it will also close it, in error.)
- Empty tag name elements, which are technically skipped over and aren't comments, e.g. `</>`.
Props dmsnell, costdev.
Fixes#58007.
Built from https://develop.svn.wordpress.org/trunk@55667
git-svn-id: http://core.svn.wordpress.org/trunk@55179 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When setting a new value for an attribute multiple times and providing
multiple case variations of the attribute name the Tag Processor has
been appending multiple copies of the attribute into the updated HTML.
This means that only the first attribute set determines the value in
the final output, plus the output will //appear// wrong.
In this patch we're adding a test to catch the situation and resolving it
by using the appropriate comparable attribute name as a key for storing
the updates as we go. Previously we stored updates to the attribute by
its given `$name`, but when a new update of the same name with a
case variant was queued, it would not override the previously-enqueued
value as it out to have.
Props dmsnell, zieladam.
Fixes#58146.
Built from https://develop.svn.wordpress.org/trunk@55659
git-svn-id: http://core.svn.wordpress.org/trunk@55171 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In this patch we're adding `has_self_closing_flag()` to the HTML Tag Processor.
This exposes whether a currently-matched tag contains the self-closing flag `/`.
This information is critical for the evolution of the HTML API in order
to track and parse HTML structure, specifically, knowing whether an
HTML foreign element is self-closing or not.
Props dmsnell, zieladam.
Fixes#58009.
Built from https://develop.svn.wordpress.org/trunk@55619
git-svn-id: http://core.svn.wordpress.org/trunk@55131 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While `WP_HTML_Tag_Processor` currently only supports changing a given tag's attributes, the plan is to provide methods to make broader changes (possibly through a subclass of `WP_HTML_Tag_Processor`). The API will have the potential of replacing a tag that a bookmark points to. To prepare, this changeset makes sure that all bookmarks affected by a HTML replacement are invalidated (i.e. released).
Changes:
* Extends the existing loop in `WP_HTML_Tag_Processor::apply_attributes_updates()` that adjusts bookmarks' start and end positions upon HTML changes to check if the entire bookmark is within a portion of the HTML that has been replaced.
* Adds `WP_HTML_Tag_Processor::has_bookmark() to check whether the given bookmark name exists.
References:
* [https://github.com/WordPress/gutenberg/pull/47559 Gutenberg PR 47559]
* [https://github.com/WordPress/gutenberg/releases/tag/v15.3.0 Released in Gutenberg 15.3.0]
Follow-up to [55203].
Props bernhard-reiter, dmsnell, zieladam.
Fixes#57788.
Built from https://develop.svn.wordpress.org/trunk@55555
git-svn-id: http://core.svn.wordpress.org/trunk@55067 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Documents the shorthand usage, i.e. `$this->next_tag( 'img' )`, of `WP_HTML_Tag_Processor::next_tag()`.
Also includes table alignments and formatting adjustments in the class docs.
Follow-up to [55203], [55206].
Props zieladam, poena, dmsnell, costdev, hellofromTonya.
Fixes#57863.
See #57575.
Built from https://develop.svn.wordpress.org/trunk@55477
git-svn-id: http://core.svn.wordpress.org/trunk@55010 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Setting a bookmark on a tag should set its "start" position before the opening "<", e.g.:
{{{
<div> Testing a <b>Bookmark</b>
----------------^
}}}
The previous calculation assumed this is always one byte to the left from `$tag_name_starts_at`.
However, in a closing tag that index points to a solidus symbol "/":
{{{
<div> Testing a <b>Bookmark</b>
----------------------------^
}}}
The bookmark should therefore start two bytes before the tag name:
{{{
<div> Testing a <b>Bookmark</b>
---------------------------^
}}}
This changeset achieves this by:
* Using the correct starting index for closing tag bookmarks.
* Adding `array( 'tag_closers' => 'visit' )` in `WP_HTML_Tag_Processor::seek()`.
Follow-up to [55203].
Props zieladam, dmsnell, flixos90.
Fixes#57787.
See #57575.
Built from https://develop.svn.wordpress.org/trunk@55407
git-svn-id: http://core.svn.wordpress.org/trunk@54940 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When the HTML API was introduced a number of fields were switched from private visibility to protected so that Gutenberg and other systems could more easily enhance the behaviors through subclassing. The $this->html property was overlooked but important for systems using the Tag Processor to stich HTML, specifically performing operations on innerHTML and innerText.
Follow-up [55203].
Props dmsnell.
See #57575.
Built from https://develop.svn.wordpress.org/trunk@55402
git-svn-id: http://core.svn.wordpress.org/trunk@54935 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
dmsnell
Pascal Birchler
Sergey Biryukov
Bernhard Reiter
zieladam
Andrew Ozz
audrasjb
John Blackbourn
hellofromTonya
gziolo