Conversation
|
This hits top-level blocks but in some cases I think it might be problematic (such as the column block). This would be a good use-case for the filter I've toyed with in #10108. If we applied a pre-render filter to the blocks then we could whitelist or blacklist down the tree. Then we wouldn't have odd behaviors with top-level vs. nested blocks. |
|
Thanks for the review @dmsnell, that's a good point about nested blocks. I've actually added |
|
No rush to get this merged today, pushing to 4.6. |
|
@pento is this still relevant or is it replaced by the change in core? |
|
Core uses the same code as in this PR, so both Gutenberg and core are currently wrong, in their own special way. 🙂 I think we can just implement something like #10108, and modify this change to use that new filter. This can be done in core, we don't need to bother in Gutenberg. (Let's leave this PR open until there's a corresponding core ticket.) |
|
I opened a corresponding ticket in core, which means this one can be closed as mentioned above. Let's continue on trac 👍 |
|
The new ticket: https://core.trac.wordpress.org/ticket/46133 |
|
Thanks @Soean, I planned to share the link but somehow I missed it :) |
Now that #11141 has landed, we can use the same logic when generating an excerpt, which allows us to deprecate
get_dynamic_blocks_regex().By using a list of allowed blocks, we can avoid the other issue that
strip_dynamic_blocks()is intended to address, when a dynamic block can callget_the_excerpt(), causing an infinite loop.Out of interest, 198c82f is an alternate method, which just tweaks
strip_dynamic_blocks()to use the parser, but I think this is the better method.