Bug: 355: Collapsible Block - generate unique id's when blocks are duplicated #356
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #355
May partially fix https://github.com/bu-ist/r3-law/issues/446, though existing pages would need to be updated to remove duplicates.
After performing a bunch of research I agree with others that the clientId is not the best choice for generating unique ID's and a more robust approach is needed. The unique ID's are needed for the Aria Labels in the block for the interactivity, button label, etc.
This approach uses idea from two locations, the implementation in core in a newer version of Gutenberg and some ideas in this issue.
I was unable to get the object map of generated anchors id's to work reliably in our version of WordPress which was how the core heading block tracked "duplicate" unique ID's. They stored all of the id's in an object variable and searched that object for duplicates. This did not work for me based on when the check for duplicates fired. Additionally our block has "Styles" in enabled which appear as live previews in the sidebar. These too were generating unique ID's and being added to the object map and I couldn't find a way to avoid that. That caused odd duplications of the unique ID's.
Instead I combined the core approach with the approach in #17246 where someone else that ran into this simply queried the editor markup for blocks with a duplicate ID to check for unique ID collisions.
The unique ID's generated from clientId's were problematic because they are generated each time the editor is initialized. They are only unique for that session and 17246 outlines some issues with relying on that approach alone. I prefer the unique ID's that are generated from the title of the block. Now there will be times that this might not be unique if there are multiple blocks with the same title on the page. However I was able to check for that with the isDuplicate search of the DOM and if a duplicate is found part of the clientId is appended to that duplicate's ID. I feel that the ID's generated from the title are more user friendly, easier to read, easier for the admin's to use as anchor's, etc.
From my testing this solves the issues in #355 when a block is duplicated in the editor the uniqueID is now checked against other blocks and regenerated with an appended clientId if it is found to be a duplicate. This prevents the issue of the admin duplicating a collapsible block, then editing it and not realizing the unique ID is the same as the previous block.
I also added the ability to disable the autogenerated unique ID's for cases where an admin or a designer in ID has a need to control the ID's and will manage the uniqueness themselves.
Screen.Recording.2023-08-25.at.2.22.58.PM.mov
Demo: https://id-dakota-upgrade.cms-devl.bu.edu/bu-blocks/wp-admin/post.php?post=233&action=edit