[wp-trac] [WordPress Trac] #45451: Filter to allow plugins override block attributes

[WordPress Trac]

#45451: Filter to allow plugins override block attributes
------------------------------+---------------------
 Reporter:  kkarpieszuk       |       Owner:  pento
     Type:  enhancement       |      Status:  closed
 Priority:  normal            |   Milestone:  5.1
Component:  Editor            |     Version:  5.0
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch commit  |     Focuses:
------------------------------+---------------------

Comment (by dmsnell):

 I'm going to post this link to the PR in the plugin that I created some
 time ago to address this.

 https://github.com/WordPress/gutenberg/pull/10108

 I was using the `pre_` filter to perform short-circuiting //and// adjust
 the block attributes but I can see where two would be helpful. In my
 reasoning there was a symmetry to the `pre_` and `post_` filters which
 expressed itself as "the filter which affects //how// a block is rendered"
 and "the filter which affects //what// was rendered in a block."

 {{{#!php
 $block = apply_filters( 'render_block_data', $block );
 }}}

 In the above filter definition I wonder if anyone else considered adding
 the `$source_block`. I anticipate that block-transformation will be a
 common way that people write plugins: for example, pulling out a child
 block based on an attribute such as `locale` for translations or
 `es5/es2015/es2017` for example code blocks; alternatively in applying
 different steps of transformation, such as when we want to filter all text
 content generally but have a markdown render - transform first from
 markdown to html then run the transformed block through the next filter in
 the chain.

 In these cases I seemed to remember some valid use-cases for where we'd
 want to or need to know what the original pre-transformed block data was,
 most-frequently the block name, but maybe that can be equally handled via
 filter priority?

 Anyway, those are some thoughts from me. Thanks @kkarpieszuk for working
 on this issue - it's close to my heart as I am pretty sure that with a
 solid filter API for blocks we can eliminate the concept of //dynamic
 blocks// and the `render_callback`, instead meeting that need through the
 consistent filtering API.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45451#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform