[wp-trac] [WordPress Trac] #47375: Blocks API: Add server-side `serialize_block()`

[WordPress Trac]

#47375: Blocks API: Add server-side `serialize_block()`
--------------------------------------+------------------------------
 Reporter:  dmsnell                   |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Editor                    |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------

Comment (by birgire):

 @dmsnell thank you for an informative reply.

 > Admittedly I have mixed feelings but I'm hesitant to add superfluous
 comments when I think they are
 > incidentally needed. serialize() is a wildly-generic term and I'm not
 personally familiar with any
 > common trends that create some kind of specialized version of
 serialize() for specific data types. I
 > won't try and block an additional comment but in some ways I find the
 extra explanation a little unwarranted.

 My initial thought was that this new PHP function was related to the
 commonly used {{{serialize()}}} function in PHP, but I might be the only
 one experiencing that initial thought :-) Maybe a general dev-note
 introducing this new function, might then be more relevant instead?

 > That's a shortcut based on the way the blocks are designed. We could
 have replaced it with (the
 > arguably more reliable) $block['innerContents'][0] but I left it short
 for clarity. Maybe that's the
 > wrong call - not sure.

 That sounds good to me.

 > I've intentionally not validated the inputs and while that may sound
 bizarre I do it for the sake of
 > improving the quality. First of all, I think if we are worried about
 invalid input we might gain by
 > addressing this from another angle - make it clearer that this should
 only get the contents of the
 > block structure provided by parse_blocks() or equivalents.

 > At this low level I consider it a game of tense alliances between all
 the different subsystems. If
 > any block data is passed around which doesn't conform to our
 expectations than multiple systems will
 > fail - to that end I'd rather we fail right out front at the boundary
 then cover the error - it's
 > going to fail either here or right away somewhere else.

 > That block structure does bring certain assumptions and you're right to
 call them out. I'm not sure
 > if I'll get this in but some links to documentation/specifications can
 hopefully help fill in the
 > contextual gap here.

 Yes I think it would be helpful to mention the relation to
 {{{parse_blocks()}}} in the docs.

 As this will become a public API (unlike the underscore {{{_}}} prefixed
 functions), I can imagine it will be used in all kinds of situations and
 all kinds of inputs.

 I think it could be helpful to validate the input, in such a way that the
 function will not output a "block zombie", for my lack of a better word
 :-)

 This kind of output might look valid from a distance, but can scare the
 hell out of us when we look closer :-)

 Here's an example:

 {{{
 serialize_block( [ 'blockName' => [] ] )

 }}}

 with output:

 {{{
 "<!-- wp:Array /-->"

 }}}


 I wonder if these kind of outputs should be allowed to go through?

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