Gutenberg: Meta Attribute returning empty after upgrading gutenberg

[myleshyson]

Describe the bug
We have a block with a meta attribute called directory_block_items and are registering it the way the documentation instructs. It works great with just using WordPress 5.3. However in installing Gutenberg 7.1, the meta attribute for this block, which before returned the meta data, now returns blank data to the block.

However, we are using a server side rendered block in the editor, so because that's just using get_post_meta for to get the meta, it's showing up fine. It's just the javascript side of things isn't picking up the meta attribute anymore for some reason.

function gutenberg_meta_init () {
    register_meta('post', 'has_directory_block', array(
        'show_in_rest' => true,
        'single'       => true,
        'type'         => 'boolean',
    ));

    register_meta('post', 'directory_block_items', array(
        'show_in_rest' => true,
        'single'       => true,
        'type'         => 'boolean',
    ));
}
add_action('init', 'gutenberg_meta_init');

//..other attributes
items: {
  type: 'string',
  source: 'meta',
  meta: 'directory_block_items',
  default: '[]'
}

[youknowriad]

Could this be related to the meta source refactor cc @aduth @epiqueras

[aduth]

It's quite possible to be related to #18960, yes. I'll take a look.

[aduth]

@myleshyson Are you able to share code relevant to your block registration? And the enqueuing of scripts associated to those blocks (if not done using the editor_script property of register_block_type)?

[myleshyson]

Actually, this is helpful to know but still an issue, I'm using wp.data.select('core/block-editor').getBlockAttributes() to get the blocks attributes. The meta value returned from that is empty. However if I were just to log out props.attributes straight from the block, the meta data is there.

[youknowriad]

I'm using wp.data.select('core/block-editor').getBlockAttributes()

While it used to work, I don't think you should expect to retrieve the meta value from this selector. It used to work but I think we should do a dev note about it. Essentially, this hurts performance a lot (for all blocks including the ones not using meta) and it's not a pattern we want to encourage.

[aduth]

Actually, this is helpful to know but still an issue, I'm using wp.data.select('core/block-editor').getBlockAttributes() to get the blocks attributes. The meta value returned from that is empty. However if I were just to log out props.attributes straight from the block, the meta data is there.

That's a useful observation, thanks. It makes me wonder if it's actually a regression of #18960, as even prior to those changes, the "meta compatibility" had been based on filtering editor block rendering (providing the meta value in props.attributes) and this did not change after #18960.

[youknowriad]

@aduth This is definitely prior to #18960

[aduth]

Somewhat related to #4989. The original problem there was similar in needing to set an "initial" value of a meta attribute for a parsed block. The need for this is now likely in contrast with the new recommended direction of entity sources (#17368, #17153). That said, if it were possible to have some control over the parsed blocks result before it's used as the block editor value, it might not be too difficult to provide compatibility for this. I don't know that such extensibility exists, or that it's even desired to exist (again, due to the potential conflicts with the direction of #17368).

[youknowriad]

I added a note on #17368 so we don't forget to document this properly. Thanks for raising the issue.

[epiqueras]

A dev note should be fine. We don't need to/shouldn't set an initial value anymore neither.