[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 dmsnell):

 > What about adding a note to the new functions here, that they are not
 related to the serialize() function in PHP?

 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.

 > I wondered about the 'innerHTML' part

 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.

 > What about invalid $block input of serialize_block( $block )
 > What do you think about making sure the input has the correct structure?

 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.


 Otherwise awesome feedback @birgire and thanks so much @jorgefilipecosta
 for helping this along. You are both wonderful!

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