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

Deleting a block or template does not delete postmeta #45

Open
tharsheblows opened this issue Apr 20, 2018 · 3 comments
Open

Deleting a block or template does not delete postmeta #45

tharsheblows opened this issue Apr 20, 2018 · 3 comments

Comments

@tharsheblows
Copy link

When a block or template is deleted, the postmeta is not deleted. This is an issue because in templates, the data will be retrieved using get_post_meta.

Reproduce:

  • make a template
  • make a post, fill out the template and save
  • go back into the post, delete the block then save

You can keep an eye on the postmeta table to see that it's still there or put a filter on the content to view it (at the bottom)

There are a couple of ways of fixing:

  • delete postmeta on block deletion and delete all instances of the meta_keys used in a template on template deletion (so as not to leave orphaned uneditable/undeletable data)
  • use a dynamic render which won't show the postmeta data unless the block is there

I think the first is the way to go as it avoids the orphaned data issue.

Cheap and cheerful content filter:

function mjj_filter_content( $content ){
	$post_id = get_the_ID();
	if( empty( $post_id ) ){
		return $content;
	}
	$gcf_postmeta = get_post_meta( $post_id, 'main field', true );
	if( empty( $gcf_postmeta ) ){
		return $content;
	}
	return '<h2>' . print_r( $gcf_postmeta, true ) . '</h2>' . $content;
}
add_filter( 'the_content', 'mjj_filter_content' );
@youknowriad
Copy link
Owner

For me this is not a bug. Conceptually, you can use the same meta in several blocks in Gutenberg. Deleting a meta shouldn't be achievied by the removal of a block, but by the removal of the value inside the block.

Maybe deleting a field from a template should delete this meta for all posts, but I'm not yet sold on the idea.

@tharsheblows
Copy link
Author

Keeping the meta makes sense if any block on the post uses the same postmeta key and remains in the content, definitely. (When I say "block" I mean a template block)

This is how I'm thinking of it though: say I have a paragraph block where I've written something and I've decided that it's a horrible horrible paragraph so I delete the block. I assume that the paragraph is gone and won't show up on the post.

This isn't true of the template blocks — I wouldn't think to delete the content of the template block field by field then save the empty block, the same way I wouldn't think to delete the content of the paragraph block and save an empty paragraph block.

Also, thinking about this, I am not sure your example works there either. If I delete the contents of one block and there's another on the page with values, which one takes precedence?

I get where you're coming from — meta is different! It's stored differently and can be used differently. The brilliance of Gutenberg though is that the user now doesn't need to know any of that, they can just add and delete blocks and assume if it's there it will work the same as all the rest.

But what an interesting discussion, thank you! I had never thought through what happens to postmeta when a block is registered and uses 'meta' as an attribute type and an instance is deleted, mainly because I've only used the dynamic render for those so the issue didn't show up. :)

@youknowriad
Copy link
Owner

Also, thinking about this, I am not sure your example works there either. If I delete the contents of one block and there's another on the page with values, which one takes precedence?

they are synced, so whatever you update on a block, it's updated on the other blocks too.

Maybe the way forward is to add an explicit "reset value" on each of the fields.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants