WP_HTML_Processor: Add set_content_inside_balanced_tags

[ockham]

What?

Part of #44410.

Work in progress. Branch based on @dmsnell's #46345, which introduces the get_content_inside_balanced_tags counterpart.

Why?

This is going to be a handy multi-purpose method for HTML manipulation. Needed for the Block Interactivity API, see WordPress/block-interactivity-experiments#125.

How?

By hijacking WP_HTML_Tag_Processor's established $attribute_updates mechanism. This seems to work well enough at a basic level but will of course require some changes.

What's interesting here is that while $attribute_updates is keyed by ("comparable", i.e. lowercase) attribute name, those keys are only relevant for set_attribute() (to check if an attribute of the same name already exists). They are however entirely ignored by apply_attributes_updates -- which is why we can use that mechanism for set_content_inside_balanced_tags without much modification 🎉

TODO

• WP_HTML_Tag_Processor: Rename attribute_updates to lexical_updates #47053
• WP_HTML_Tag_Processor: Allow non-attribute lexical updates #47068

Testing Instructions

Locally:

npm run test:unit:php -- --group=html-processor

[github-actions]

Flaky tests detected in 6850a65.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/3933179913
📝 Reported issues:

• [Flaky Test] results in two remaining blocks and positions the caret at the end of the second block #39805 in specs/editor/various/block-deletion.test.js
• [Flaky Test] should insert media, convert to blocks, and undo in one step #36123 in specs/editor/blocks/classic.test.js

[dmsnell]

I almost proposed a lexical_updates rename yesterday but deferred it so we can sync all our open PRs/branches to that rename.

On finding the balanced tag we also probably need to heed void and self-closing tags (void tags are the only thing currently supported by my HTML processor, but I plan to add support for self-closing tags (of which only foreign elements can be self-closing; HTML elements with a self-closing flag are errors and the self-closer is ignored).

I found this while working on the CSS child selector, as I was inappropriately skipping past the first element following a void element before taking that into account.

[ockham]

I almost proposed a lexical_updates rename yesterday but deferred it so we can sync all our open PRs/branches to that rename.

FWIW, I filed one now: #47053 😊

(I hope I read you correctly -- you did mean a separate PR that we can land and then rebase our open PRs on?)

[dmsnell]

you did mean a separate PR that we can land and then rebase our open PRs on?

This, plus a good place to pause/merge other development to avoid needless conflict resolution.

[ockham]

Now implementing add_lexical_update by cherry-picking 435987b from #47053, and bc92001 from #47068.

[ockham]

test_set_content_inside_balanced_tags_preceded_by_set_attribute_works (a989f71) is failing. For reference, here is what it does:

public function test_set_content_inside_balanced_tags_preceded_by_set_attribute_works() {
	// For reference: self::HTML === '<div>outside</div><section><div><img>inside</div></section>';
	$tags = new WP_HTML_Processor( self::HTML );

	$tags->next_tag( 'section' );
	$tags->set_attribute( 'id', 'thesection' );
	$tags->set_content_inside_balanced_tags( 'This is the new section content.' );
	$this->assertSame( '<div>outside</div><section id="thesection">This is the new section content.</section>', $tags->get_updated_html() );
}

1) WP_HTML_Processor_Test::test_set_content_inside_balanced_tags_preceded_by_set_attribute_works
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'<div>outside</div><section id="thesection">This is the new section content.</section>'
+'<div>outside</div><section id="thesection"><div><img>insideThis is the new section content.</section>'

I think I've tracked down why, and how to fix. Stay tuned...

[getdave]

Will this PR allow for the following use case?:

• filter on replace_block
• find a <button> in the DOM of the block markup
• replace an SVG tag within that button with a new SVG I have.
• commit those changes back to the block markup

I was looking for this and I realised Tag Processor doesn't currently allow and @adamziel pointed me at this PR.

[dmsnell]

Will this PR allow for the following use case?:

@getdave the short answer is that it probably will, but probably not this PR. look for WP_HTML_Processor->replace_inner_markup() and WP_HTML_Processor->replace_outer_markup() which uses the tag processor to provide tree-level HTML operations. it may take a while to get there.

[ockham]

Closing, for the same reasons as outlined in #47573 (comment):

Closing. Per recent discussions, we're going to unblock the work in the BHE repo by implementing missing features in a subclass of WP_HTML_Tag_Processor right there (e.g.).

Development of the HTML Processor API is expected to progress more cautiously/slowly, to take into account more exotic HTML constructs; it will happen in (forks of) the wordpress-develop repo (e.g.).