[wp-trac] [WordPress Trac] #45312: parse_blocks return non-existing empty blocks

[WordPress Trac]

#45312: parse_blocks return non-existing empty blocks
--------------------------+----------------------
 Reporter:  Chouby        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Editor        |     Version:  5.0
 Severity:  normal        |  Resolution:  invalid
 Keywords:                |     Focuses:
--------------------------+----------------------
Changes (by dmsnell):

 * status:  reopened => closed
 * resolution:   => invalid


Comment:

 > show what I'm trying to do

 Thanks @leec87 for sharing that code. I'm seeing where the `Undefined
 offset: 0` error is coming in and I do think here will be further problems
 beyond he empty blocks if you keep that code.

 The root cause is hard-coding assumptions about what blocks will appear.
 It may be the case in the posts you are working with that you get blocks
 in the structure you want to modify but generally we'll run into problems
 when we access `$block['innerBlocks'][ $any_index ]` without verifying
 that such inner blocks exist.

 In your case I'd consider using something along the example code I have
 here instead of in the GitHub issue as it should end up being more
 reliable for you as you process posts of different block types. Most
 blocks we encounter will have no inner blocks.

 The method I'd recommend involves different parts: the process you take
 will largely hinge on what role those CSS classes play. I'm not sure what
 you mean when you say "swap the order of the image and text around." I'm
 going to assume that you want alternating columns where odd rows have the
 image on the left, text on the right but even rows get the image on the
 right, text on the left.

 **Note that we should avoid printing the output of `parse_blocks()`
 because it won't continue processing nested blocks and it won't render
 shortcodes. We'll use `do_blocks()` instead.**

 Assumptions:
  - your media and text are sitting inside a custom block whose name is `my
 /media-text-pair`
  - your media is a `core/image` block and the text is a `core/paragraph`
 block

 You'll be able to answer questions I can't because of my limited exposure
 to your code.

 {{{#!php
 function is_media_text_pair( $block ) {
         if ( 'my/media-text-pair' !== $block['blockName'] ) {
                 return false;
         }

         if ( count( $block['innerBlocks'] ) < 2 ) {
                 return false;
         }

         if ( 'core/image' !== $block['innerBlocks'][ 0 ][ 'blockName' ] )
 {
                 return false;
         }

         if ( 'core/paragraph' !== $block['innerBlocks'][ 1 ][ 'blockName'
 ] ) {
                 return false;
         }

         return true;
 }

 function reverse_inner_blocks( $block ) {
         $blocksReversed = array_reverse( $block['innerBlocks'] );

         return array_merge( $block, [ 'innerBlocks' => $blocksReversed ]
 );
 }

 function swap_media_text_pairs( $block ) {
         return is_media_text_pair( $block )
                 ? reverse_inner_blocks( $block )
                 : $block;
 }

 function add_zebra_stripes( $content, $block ) {
         static $is_even = true;

         if ( ! is_media_text_pair( $block ) ) {
                 return $block;
         }

         $is_even = ! $is_even;

         return sprintf( '<div class="%s">%s</div>', $is_even ? 'order-
 md-1' : 'order-md-2', $content );
 }

 add_filter( 'render_block_data', 'swap_media_text_pairs' );
 add_filter( 'render_block', 'add_zebra_stripes' );
 $output = do_blocks( $post->post_content );
 }}}

 Feel free to poke me in the WordPress Slack team - I'm @dmsnell. I'm going
 to close this issue again in the meantime.

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