[wp-trac] [WordPress Trac] #59551: Respect non-null values from the `pre_render_block` filter

[WordPress Trac]

#59551: Respect non-null values from the `pre_render_block` filter
--------------------------+------------------------------
 Reporter:  danieliser    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  6.0
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by pbiron):

 Replying to [comment:4 jeremyfelt]:
 > IMO, the general promise with `pre_` filters in core is that I can
 short-circuit something entirely.

 Agreed...and the last callback hooked to such filters is what determines
 whether something is short-circuited.

 > In `pre_render_block`'s current form, if I `add_filter(
 'pre_render_block', '__return_empty_string', 1 );`, I would expect that
 all blocks are rendered as an empty string.

 I would expect all blocks to be rendered as empty strings **if no other
 callbacks are hooked after the above**, and it is documented that core
 hooks into the filter at priority 10.  So, if you really want to ensure
 that `__return_empty_string` wins, then hook at `PHP_INT_MAX` (and make
 sure that you hook in at that prio after every other plugin/theme has done
 so ;-).

 > Because core's own use of `pre_render_block` does not respect the value
 of `$pre_render` set earlier than priority 10, the filter doesn't work as
 promised. Instead, I need to set my priority so that it runs after core.

 > It seems that if these two functions are treating `pre_render_block` as
 an action rather than a filter, they should pass through the value of
 `$pre_render` untouched rather than force it to always be `null`. That's
 the patch I would propose here.

 Agreed again...since core's callbacks to this _filter_ is acting like an
 _action_, core's callbacks should return `$pre_render` rather than `null`.
 Jeremy, would you like to do the honors of submitting a PR/patch?

 With Dennis' comment (he commented while I was composing this ;-), I think
 a patch to return `$pre_render` instead of `null` will get a lot of
 support (including from me).  But I'm weary of Dennis' "additional
 caveat", because I can imagine a plugin rendering a block **almost** like
 it would "normally" but maybe adding a `data-xyz` attribute to some HTML
 element...and expecting core to have output the styles it would normally
 do.

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