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

Attributes of source: 'meta' not available/undefined in save on pageload #13621

ckanitz opened this issue Jan 31, 2019 · 1 comment

Attributes of source: 'meta' not available/undefined in save on pageload #13621

ckanitz opened this issue Jan 31, 2019 · 1 comment


Copy link

@ckanitz ckanitz commented Jan 31, 2019

Describe the bug
I have a metavalue with key mymetakey.
My blockattributes:

const blockAttributes = {
  metaAttribute: {
    type: 'string',
    source: 'meta',
    meta: 'metakey',

Within my edit function I modify the attribute with onChange={ ( value ) => setAttribute( { metaAttribute: value } )

In my save function I get the attribute as usual with const { ..., metaAttribute } = attributes;

Problem: If I reopen / reload the post at the backend metaAttribute is initially undefined. That leads to either a "whitescreen"-error with length of undefined because, well, the attribute itself is undefined or a blockvalidation-error if I handle it with a default value.

Just a moment later the save function is triggered again and console.log( metaAttribute ) got the correct value. But that doesn't help with the problem since blockvalidation is triggered before the attribute is read from post meta.

To Reproduce
Steps to reproduce the behavior:

  1. Have an attribute from meta
  2. setAttribute within edit function
  3. use the metaattribute within save

Expected behavior
No errors ¯_(ツ)_/¯
The attribute should be the saved value and not undefined on "init"


Desktop (please complete the following information):

Smartphone (please complete the following information):

Additional context
This issue might be duplicated, see: #4989
If so please let me now so I'll follow the other issue instead.

Copy link

@aduth aduth commented Jan 31, 2019

Thanks for the report. I do think this a duplicate of #4989, but the other issue could have done better to explain more detail to how the bug occurs. I've tried to elaborate on this point at #4989 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants