Open nk-o opened 4 years ago
A different issue, but the same problem was discussed in a slack triage session: https://wordpress.slack.com/archives/C02QB2JS7/p1625549733336200
I think the problem happens because there are two API requests happening in the background. One REST request to update the post, and that's followed by an ajax request to post.php to update metaboxes. My hunch is that the second request overwrites the values set by the first.
I can think of two potential fixes:
Probably other options too.
I think the problem happens because there are two API requests happening in the background.
I came to the same conclusion trying to develop a generic post meta field block. https://github.com/bobbingwide/sb-field-block/issues/2#issuecomment-871393212
Notes:
I can think of two potential fixes:
Are these fixes something that would be implemented by core or would each block have to do it? If the latter, what mechanisms are available?
Are these fixes something that would be implemented by core or would each block have to do it?
I'm thinking this would be in the Gutenberg codebase. This is where metabox saving happens: https://github.com/WordPress/gutenberg/blob/1f55df53a0ec469c7abd7cbdb65568b08d84f906/packages/edit-post/src/store/actions.js#L335-L398
So that might be a place to investigate.
EDIT: Please have a look at https://github.com/WordPress/gutenberg/issues/23078#issuecomment-1111220849 for a much better workaround.
Since this can cause major issues and breakage I was looking for a workaround.
I didn't see any other solution than the nuclear option to completely disable the Custom Fields panel.
Please ensure you know what you are doing here before proceeding since
There are actually two parts to it:
Since the preference whether to show the Custom Fields panel is stored in user meta we can just force it to always be false.
add_filter('get_user_metadata', function($value, $object_id, $meta_key, $single, $meta_type){
if($meta_key !== 'enable_custom_fields'){
return $value;
}
return false;
}, 10, 5);
You can still see the toggle to enable the Custom Fields panel in the preferences panel though. But it doesn't have any effect any more which is very bad/confusing UX. So:
Due to this check
we can hide the setting like this:
add_filter('block_editor_settings_all', function ($editorSettings, $editorContext) ){
unset($editorSettings['enableCustomFields']);
return $editorSettings;
}, 10, 2);
Okay, scrap that, it is actually way easier. Just remove the meta box which also hides the settings panel. You can even do it just for those post types you want. Way better than what I had in https://github.com/WordPress/gutenberg/issues/23078#issuecomment-1111194202. 🤣
add_action('add_meta_boxes', function( $post_type, $post ){
if ($post_type !== 'my-custom-post-type') {
return;
}
remove_meta_box(
'postcustom',
null,
'normal'
);
},10, 2);
I found you can either prepend your meta key with an _
to denote it as a private key, or use the is_protected_meta
to mark your keys as private (again) and also excluded from the custom field panel/meta box.
I found you can either prepend your meta key with an
_
to denote it as a private key, or use theis_protected_meta
to mark your keys as private (again) and also excluded from the custom field panel/meta box.
I tried this an I got an error that I'm not allowed to edit the field. Did I miss something?
I found you can either prepend your meta key with an
_
to denote it as a private key, or use theis_protected_meta
to mark your keys as private (again) and also excluded from the custom field panel/meta box.I tried this an I got an error that I'm not allowed to edit the field. Did I miss something?
Turns out you also need to add 'auth_callback' => '__return_true'
when you register the meta or register_meta
will set $args['auth_callback'] = '__return_false'
.
I have started this pull request trying to solve this issue. Although I must say that I am not familiar with that code and I am not sure if that's a viable approach.
Describe the bug We have a block with an attribute, which saves in post meta. This block is working with no problem. Then we activate the Custom Fields panel and now changed in block attribute value will not be saved in post meta.
To reproduce Steps to reproduce the behavior:
Create a block with meta attribute - https://developer.wordpress.org/block-editor/tutorials/metabox/meta-block-3-add/
Don't forget to register meta field in PHP - https://developer.wordpress.org/block-editor/tutorials/metabox/meta-block-2-register-meta/
Insert this block in the post, fill the text control and update the post![image](https://user-images.githubusercontent.com/14810891/84319909-7c1eb080-ab79-11ea-96ff-15fc5213438e.png)
Make sure your meta value saved in post (reload the page and you will see this value in field)
Activate Custom Fields panel![image](https://user-images.githubusercontent.com/14810891/84320321-23034c80-ab7a-11ea-95d2-2784bd3323a8.png)
Try to change the block value, then update the post and reload the page
You will see, that your new meta value was not saved
Expected behavior Custom meta should be synchronized automatically when editing block attributes and editing Custom Fields panel.
Editor version:
Desktop:
Additional context