[wp-trac] [WordPress Trac] #59783: Block Hooks: Mark and document publicly available global functions as being Core-only internal functions.

[WordPress Trac]

#59783: Block Hooks: Mark and document publicly available global functions as being
Core-only internal functions.
------------------------------+---------------------
 Reporter:  hellofromTonya    |       Owner:  (none)
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  6.4
Component:  Editor            |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:  docs
------------------------------+---------------------

Comment (by azaozz):

 Replying to [comment:5 gziolo]:

 > `traverse_and_serialize_blocks` is an attempt to simplify that
 processing in WordPress core and to consolidate modifications necessary to
 the blocks serialized as HTML more formally.

 Yep, that sounds good. Seems it may be repeating some similar (or the
 same) functionality that already exists in `render_block()`?

 Another thing that seems unclear is what is it intended for and how it is
 supposed to be used in combination with or instead of the existing
 functionality like `serialize_block()` (which is not supposed to be used
 on the front-end according to the docs,
 https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/blocks.php#L974), `parse_blocks()`, `render_block()`, etc. and
 all the available filters there.

 > From my perspective, the biggest challenge is that these callbacks are
 passed down through recursive calls of `traverse_and_serialize_block` when
 processing also inner blocks. I'd be happy to discuss ideas on how we
 could refactor the existing code to use filters instead.

 Sure, sounds good! Lets have another look at all the block serializing,
 parsing and rendering functions and all the filters that run there and
 come up with something clearer and "unifying" :)

 > The simplest way to approach it I can think of would be setting filters
 inside `traverse_and_serialize_blocks` so anyone could extend the
 functionality of callbacks

 Filters are generally a way to run callbacks. If using filters it won't be
 necessary/good to also pass callbacks as function arguments.

 > However, this way, you don't have access to additional information that
 we pass to block visitors, like the list of all hooked blocks...

 Hmm, as far as I see all context can also be passed to the callbacks that
 run through filters. There's no difference.

 > I'm sure there are many alternative ways it could be refactored, so what
 I shared is more of a conversation starter. The most important question is
 whether this should be opened to extenders, knowing that we use the same
 processing every time we need to inject hooked blocks.

 Yep, that's the first/most important question. As far as I understand for
 now this should not be used by extenders so making
 `traverse_and_serialize_blocks()` and friends `private` would be best. If
 this is eventually added to the (public) blocks API, it would probably
 have to be refactored a bit to make it more useful.

 BTW the `make_before_block_visitor()` and `make_after_block_visitor()`
 don't seem to make sense in PHP. I know returning a lambda function from a
 function is a common pattern in JS, but scopes in PHP work differently so
 these functions look... somewhat weird :)

 All functions in PHP are always defined in the global scope, no matter how
 and where they are written. Also if I remember right these may also cause
 a memory leak, perhaps only in older PHP versions. Would definitely need
 refactoring whether they are private or not.

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