Gutenberg: post_name not updated when name of reusable block changed

[LarrySwanson]

Issue Overview

When name of reusable block is changed from "Untitled block" to new name, the old slug, "untitled-block" persists in the database. I would expect it to update to the new block name.

Steps to Reproduce (for bugs)

1. create new block
2. change to reusable block
3. update block name
   

Gutenberg ver 2.2.0 on local MAMP installation.

[designsimply]

I tested adding a shared block and then changing its name. When I did that, the name changed for all instances of the block and when I add a new block in a different post the updated name appears there as well. Tested with WordPress 4.9.7 and Gutenberg 3.2.0.

@LarrySwanson I am not exactly sure where to check shared block slug name in the database though, could you walk me through how to check that?

[mtias]

Closing for now, feel free to reopen.

[earnjam]

This is still an issue, not sure why it was closed.

[mtias]

I think I misread it at the time as not updating the name, which was a separate issue for a bit.

[noisysocks]

One way of seeing this is by running wp post list --post_type=wp_block in WP CLI.

We don't show the reusable block slug anywhere, so my question is: Why does this matter? @LarrySwanson, what are you using the reusable block's slug for?

We could "fix" this by having the API update post_name automatically when the title is changed, but this would cause any code that references the block using the old post_name to break.

Another idea is to commit to reusable blocks not having proper slugs by setting post_name to be "block-$ID" when the block is saved. Without knowing more about what the desired use-cases are here, this would be my preferred approach.

[earnjam]

I don't think we should change post_name any time the post_title for the block changes because that makes it unreliable for any use. I _do_ think we should use something other than untitled_reusable_block as the slug.

Given the challenges of having to save the block immediately on creation, we can't use the title of the block to generate the initial slug value for now, so I think I'm +1 for using block-$id unless we have some changes to the reusable block creation flow where a name is provided first before converting/saving. If we can get a name, then it would be better to use that.

If there is a good use-case for having custom post_name values, I could foresee a possible future enhancement that would allow changing it when editing by itself in its own editor (not from within another post), as it's basically just a normal post then, so being able to edit the slug seems logical.

[mtias]

I do think we should use something other than untitled_reusable_block as the slug.

I agree. I'd place this in the same bucket of naming template-part blocks (the slug, specifically) and even adding a "name" to group blocks — it's useful to have access to that info, even if it's more advanced in a way.

The fact we save "untitled_reusable_block" by default should be considered a bug, even if it's not immediately exposed in the interface, it's data being saved inelegantly.

[noisysocks]

Let's go with this for now:

Another idea is to commit to reusable blocks not having proper slugs by setting post_name to be "block-$ID" when the block is saved. Without knowing more about what the desired use-cases are here, this would be my preferred approach.