Blocks that don't support being reusable can be added to a reusable block using Manage all reusable blocks > Edit

[talldan]

Describe the bug
In the post editor for reusable blocks, blocks that don't support being 'reusable' can be inserted.

A user also reported that this could be achieved in Code Editor mode (in the post editor), but I wasn't able to reproduce this. (#15916 (comment))

To reproduce
Steps to reproduce the behavior:

1. Open the post editor
2. Add a classic block and type some content within it
3. Try saving the classic block as a reusable block and note that this is not possible.
4. Add a paragraph and type some content within it
5. Save the paragraph as a reusable block
6. Go to Manage all reusable blocks (using the + button in the header, switching to the 'Reusable' tab, and clicking the link)
7. Edit the reusable block you just created
8. Add a classic block to the reusable block

Expected behavior
Because the classic block doesn't support being 'reusable' it shouldn't be available as a block.

[carlomanf]

This is quite comical. This feature has been available in core for 2 years. Not in the "experimental" zone, in core. The argument of maintenance/overhead doesn't apply here because removing this feature would be accomplished by adding more code, not removing old code. I don't know if you are suggesting to add new code that serves the pure purpose of deliberately breaking sites?

[carlomanf]

I also just verified that if you group a block that doesn't support reusable with one that does, you can add the group to reusable. This is without even using code view. Potentially scores of people have done this without any knowledge that it was "against the rules." Even more reason to wontfix this one.

[talldan]

I don't think there's any need to break existing reusable blocks that might contain disallowed blocks, but instead prevent them from being inserted. You're right that some care needs to be taken in order to preserve existing content.

My opinion is that it makes sense to obey the reusable setting on blocks as much as possible. This is particularly true for custom blocks where there might be a very good reason for disallowing reusability.

[carlomanf]

My opinion is that it makes sense to obey the reusable setting on blocks as much as possible. This is particularly true for custom blocks where there might be a very good reason for disallowing reusability.

I was surprised such a setting exists and have been reading up on its origins. This comment is interesting because it warned that it might not be possible to comply with. That led to the idea being shelved.

Months later, the setting got added anyway, apparently because people had forgotten about the reasons it wouldn't work. Sigh.

I think the setting should be deprecated, not because it's necessarily a bad idea, but because you shouldn't be giving block developers false hope that they can declare their block non-reusable when it's not possible for core to comply.

How could it be complied with anyway, while still preserving old content? Run a database upgrade that sets a post meta _supports_classic_block on all reusable blocks present pre-update? Then I'd just delete the post meta and it would work again. Why does this feel like a game of cat and mouse?

[mtias]

I stand by my comments there but it doesn't imply the setting itself is spurious :) It's similar to how "locked" templates can be bypassed if you use the code editor. This is merely a UI configuration to reduce the weight and confusion in options that might not be the most convenient for the user experience. I don't think it should be enforced beyond that, though, so I'd +1 closing this for now.

[carlomanf]

That's a good point that I've not seen being made before. WP has plenty of features that are supported but not exposed in the UI for good reason, for example, the ability to assign two or more roles to a user.

If this really is just a UI setting it should be clarified in the API and then we could focus on building new features and fixing real bugs instead of wasting time on silly plans to police users.

I would encourage the same UI-only approach to other issues that concern availability of blocks. (#15916, #22875, #24900) This would be a good middle ground between not overwhelming novice users with options and not causing needless headaches for developers and power users.

[jordesign]

It seems there was no final direction or resolution on this post. And as many things have changed in the ensuing 3 years - I will close this one. If the issue is still of concern a new issue can be opened addressing the current state of things.