Server directive processing: Stop processing non-interactive blocks

[cbravobernal]

What?

Use render_block_dataand render_blockfilters to differentiate between interactive, non-interactive children of an interactive block and interactive children of an interactive block to minimize the directive processing as much as possible.

Then it stacks the non interactive parts and process only interactive ones. We are replacing interactive inner blocks by a custom tag. Processing them (as they may need data from their parents) and later replacing again the processed inner blocks content by their respective tags. This is done due to how the HTML Tag Processor iterates through every tag present in the HTML.

• Process $interactive_block (innerContent) to return a string like: `
  static_content... ....more _static_content
• Start a WP_Directive_Processor instance with the previous string.
• Process the content before . Process directives if present.
• Process all inner blocks and save them into a variable.
• Come back to the previous processing and finish it, starting at the end of the
• Replace all wp-inner-blocks tags with their processed content, respectively.

Why?

The fewer HTML elements we process, the more performant it will be.

[github-actions]

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

View changed files

❔ lib/experimental/interactivity-api/class-wp-directive-processor.php
❔ lib/experimental/interactivity-api/directive-processing.php
❔ lib/experimental/interactivity-api/directives/wp-style.php
❔ phpunit/experimental/interactivity-api/directive-processing-test.php
❔ phpunit/experimental/interactivity-api/directives/wp-style-test.php

[luisherranz]

Great work 🙂

Next step: start integrating this with the HTML API 🎉

[github-actions]

Flaky tests detected in 22f6131.
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/7330411357
📝 Reported issues:

• [Flaky Test] Should show Columns block only if selected blocks are between limits (1-6) #40369 in specs/editor/various/block-switcher.test.js

[luisherranz]

Nice work!! 🎉

Codewise everything looks great, although I haven't looked at the tests yet because they are failing in my local environment due to some HTML differences.

I tried running npx wp-env start --update but it didn't fix the issue. I could look into it, but I also think that this way of testing is not very reliable and could break in the future when something unrelated changes (i.e., a change in the class names of the group block).

I think we should switch to the HTML Tag Processor and inspect only the tags that we are interested in. To do so, I think the easiest way would be to use data-wp-bind instead of data-wp-text, and add some custom class names to the custom blocks.

Imagine the interactive blocks with something like this:

<div
  data-wp-interactive='{"namespace": "level-1"}'
  data-wp-context='{"text": "level-1" }'
>
  <input class="level-1-input-1" data-wp-bind--value="context.text">
  <wp-inner-blocks></wp-inner-blocks>
  <input class="level-1-input-2" data-wp-bind--value="context.text">
</div>;

The testing could be something like this, only checking the specific attributes of the specific tags:

$post_content    = '...';
$rendered_blocks = do_blocks( $post_content );
$p = new WP_HTML_Tag_Processor( $rendered_blocks );

$p->next_tag( array( 'class' => 'level-1-input-1' ) );
$this->assertSame( "level-1", $p->get_attribute( 'value' ) );

$p->next_tag( array( 'class' => 'level-1-input-2' ) );
$this->assertSame( "level-1", $p->get_attribute( 'value' ) );

[cbravobernal]

I updated the branck with trunk and had to cherry pick @DAreRodz and @luisherranz commits. All tests are green now!

[luisherranz]

Ok, I think this is good enough now 🙂

Let's merge!

[youknowriad]

Has this been backported to Core already?

[luisherranz]

Yesss.