If you edit a post using Text Mode, any shared blocks will appear as though they have been deleted when you return to Visual Mode.
The Shared Block should render properly in the visual editor.
The Shared Block appears as though it has been deleted.
This is because RESET_BLOCKS is dispatched when PostTextEditor is blurred. This has the unintended side effect of deleting the block that the Shared Block is referencing.
One solution is to change RESET_BLOCKS so that it doesn't delete any blocks in blocksByUid that are referenced by orderedBlocks or reusableBlocks.
cc. @aduth

https://github.com/WordPress/gutenberg/pull/5228 introduced this bug. I discovered this while debugging https://github.com/WordPress/gutenberg/issues/2978 which is vaguely related.
https://github.com/WordPress/gutenberg/pull/7453 (or any similar refactor of how we implement shared blocks) will likely fix this.
Iāve checked related the tickets related to this. Is it right to assume that this problem probably wont be resolved until 5.0 or later?
For me this is an incredibly annoying issue since my only plan atm for templating involves using e.g. an 3rd party section block or a hacky 1 column column block to store a bunch of blocks as a reusable block (and to convert that to a regular block after importing the ātemplateā)
I know thereās a way to make a specific template load for CPTs but we need to be able to have multiple templates availiable for each CPT.
Sorry, rant over.
@slimmilkduds my current workaround until this is fixed is creating custom html reusable blocks.
@dkieffer The custom html reusable block, how does that work?
@slimmilkduds add a custom html block, make some sections or divs or whatever, then convert it to a reusable block.

Now since
https://github.com/WordPress/gutenberg/pull/7453# got pushed to phase 2, is there any chance of some stop gap solution to this or will 5.0 actually ship with this bug?
Yes we will need to fix this. Note that it's up to the release lead whether or not #7453 will be punted. Right now, it's still in the 5.0 milestone.
For me this is an incredibly annoying issue since my only plan atm for templating involves using e.g. an 3rd party section block or a hacky 1 column column block to store a bunch of blocks as a reusable block (and to convert that to a regular block after importing the ātemplateā)
If I'm understanding you correctly, https://github.com/WordPress/gutenberg/pull/9732 which was shipped in Gutenberg 3.9 should let you turn multiple blocks into a single reusable block.
Yes we will need to fix this. Note that it's up to the release lead whether or not #7453 will be punted. Right now, it's still in the 5.0 milestone.
For me this is an incredibly annoying issue since my only plan atm for templating involves using e.g. an 3rd party section block or a hacky 1 column column block to store a bunch of blocks as a reusable block (and to convert that to a regular block after importing the ātemplateā)
If I'm understanding you correctly, #9732 which was shipped in Gutenberg 3.9 should let you turn multiple blocks into a single reusable block.
Yeah, that was written before 3.9. The problem is that with the reusable templates released in 3.9 this bug only becomes more apparent. Creating a reusable block from multiple blocks is a 100 times smoother than what I was planning to do pre 3.9. I imagine loads of users will be pretty disapointed to have such an awesome feature rendered unusable if you want the reusable template to contain a column or any other block with nested support.
Just to be clear, itās another issue Iām referring to (
https://github.com/WordPress/gutenberg/issues/9278) that you mentioned likely had the same root cause as the one described in this ticket
Thanks for the clarification @slimmilkduds! I'll look into getting a quicker albeit less ideal fix in for these two bugs š
That sounds great! āŗļø
This is because
RESET_BLOCKSis dispatched whenPostTextEditoris blurred. This has the unintended side effect of deleting the block that the Shared Block is referencing.One solution is to change
RESET_BLOCKSso that it doesn't delete any blocks inblocksByUidthat are referenced byorderedBlocksorreusableBlocks.
This still holds true and is a little tricky to address. Some ideas:
blocksByClientId and orderedBlocks are removed in lieu of a blocks object with a byClientId and order subtrees. Then, RESET_BLOCKS could ignore blocks that are present in the .order subtree. @aduth also did this as part of https://github.com/WordPress/gutenberg/pull/10844.blocksByClientId with a flag e.g. isReusable: true. Then, RESET_BLOCKS could ignore blocks that have the isReusable flag set. getBlock could strip this flag out so that there isn't any extra API which we have to maintain.