Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta Attribute returning empty after upgrading gutenberg #19067

Closed
myleshyson opened this issue Dec 11, 2019 · 10 comments
Closed

Meta Attribute returning empty after upgrading gutenberg #19067

myleshyson opened this issue Dec 11, 2019 · 10 comments
Labels
Needs Testing Needs further testing to be confirmed.

Comments

@myleshyson
Copy link
Contributor

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
Copy link
Contributor

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

@youknowriad youknowriad added the Needs Testing Needs further testing to be confirmed. label Dec 11, 2019
@aduth
Copy link
Member

aduth commented Dec 11, 2019

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

@aduth
Copy link
Member

aduth commented Dec 11, 2019

@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
Copy link
Contributor Author

myleshyson commented Dec 11, 2019

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
Copy link
Contributor

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
Copy link
Member

aduth commented Dec 11, 2019

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
Copy link
Contributor

youknowriad commented Dec 11, 2019

@aduth This is definitely prior to #18960

@aduth
Copy link
Member

aduth commented Dec 11, 2019

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
Copy link
Contributor

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

@epiqueras
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Testing Needs further testing to be confirmed.
Projects
None yet
Development

No branches or pull requests

4 participants