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

Closed
ckanitz opened this issue Jan 31, 2019 · 1 comment
Closed
Labels
[Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed

Comments

@ckanitz
Copy link

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"

Screenshots

Desktop (please complete the following information):
all

Smartphone (please complete the following information):
all

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

@aduth
Copy link
Member

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).

@aduth aduth closed this as completed Jan 31, 2019
@designsimply designsimply added the [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed label Feb 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed
Projects
None yet
Development

No branches or pull requests

3 participants