A filter to disable or tweak how container classes are generated with indexes

[mateuswetah]

What problem does this address?

A popular plugin, Greenshift, has a feature that allows lazy loading patterns in pages (they actually still call patterns "reusable template parts"). The feature is very powerful for situations where you have long pages that end up making both editing and browsing heavy.

The dynamic loading itself works. However, if the Ajax loading is used, some styling goes broken. Specially those related to core container classes, such as .wp-container-core-group-is-layout-<some-index> from a Group Block. The reason seems obvious… when I inspect the browser I can see that there are two elements with the same class, one from one reusable template part, another from the lazy-loaded one.

So it looks that the way WordPress renders the dedicated css for each of these classes won’t work because not all page is loaded from start, thus it cannot properly parse the content to create the indexes. I brought this up to the plugin developers in their forum and it seems that they aren't aware of a way to overcome this issue.

Due to that I believe it might be something that could use some help from the core side. I asked @ndiego earlier for help to see if we can come up with a solution.

What is your proposed solution?

I guess messing with this engine is possibly very complex and I don't understand the internals. From my naive point of view, things that come in mind are:

• A filter that could allow extenders to disable this dynamic index-based styling logic. At first I thought the disable-layout-styles theme support was related but now I see that it has impact on other settings;
• An action that could allow extenders to detect when these indexes are being rendered, so that situations like this dynamic rendering could be managed by them... maybe invoking the rendering by themselves?
• Even better, some logic in core itself to detect that things are loaded later in order to take account of this elements when creating the indexes? I'm not sure but maybe the same problem could affect other situations where blocks are lazy loaded...

[aaronrobertshaw]

So it looks that the way WordPress renders the dedicated css for each of these classes won’t work because not all page is loaded from start, thus it cannot properly parse the content to create the indexes

I think you touch on the root cause here, that the page content isn't rendered all at once. The problem this causes is slightly different though.

If the asynchronously loaded blocks have these layout classes in their markup it shows the various block supports are run, successfully parse, and manipulate the block markup. The catch is the block supports that generate these classes and the associated layout styles also enqueue a custom stylesheet that styles those new classes.

It might be possible for the plugin when rendering the async content, to also check for enqueued block support stylesheets and return that data. The plugin could then inject the styles to that page as needed. It's worth noting that block supports for layout, elements, and block style variation styles all use this same approach and they'd all need to be covered by the plugin.

This isn't an area I'm hugely familiar with so feel free to take that with a grain of salt.

Ultimately, I'm not sure this use case is something that core should support. I'm happy to hear others thoughts though, just my two cents 🙂

[mateuswetah]

It might be possible for the plugin when rendering the async content, to also check for enqueued block support stylesheets and return that data. The plugin could then inject the styles to that page as needed.

I don't know any of the authors of the plugin from WPSoul to tag them directly here but I feel they could explain their technique in order to discuss a way. I figure that even if core does not handle this particular case, there might be situations in the future where dynamically loading a pattern in the page should be possible... I'm thinking popup contents, for example.