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

Duplicate Block - Unique ID not updating #17536

Closed
diggeddy opened this issue Sep 23, 2019 · 9 comments
Closed

Duplicate Block - Unique ID not updating #17536

diggeddy opened this issue Sep 23, 2019 · 9 comments
Labels
[Status] Not Applicable Issue outside Gutenberg, is not a bug, or is a support request. [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes.

Comments

@diggeddy
Copy link

Describe the bug
Bug since 6.5 update. When duplicating a 3rd Party grid container block the unique element ID does not update when first published. Editing and updating the post will update the IDs.

To reproduce

  1. Install Kadence Blocks plugin
    2.Add a row container with 2 column Grid and populate.
  2. Make duplicate of block and make style changes to differentiate.
  3. Publish the post.
  4. View the Post.
  5. Inspect the HTML of the original and duplicated block to see the IDs

Example:
Screenshot 2019-09-23 at 23 39 17

I have tested this with other blocks that use the clientID method of registering a unique ID and they display the same issue. This seems to only happen when the 'container' block has a grid within it.

Expected behavior
Duplicated block should register new ID in editor before publishing. This is pre-6.5 behaviour.

@HardeepAsrani
Copy link
Contributor

Hey @diggeddy,

Seems to be an issue with how blocks are doing their ID. We do something similar in https://wordpress.org/plugins/otter-blocks/ and it works fine (or at least I'm not aware of such issues), so you should ask the plugin author to make sure IDs are not getting duplicated.

When a block is added, they should check if the clientId & IDs used in the block are same, if not then update.

@diggeddy
Copy link
Author

@HardeepAsrani the method used in Otter Blocks forces the ID to be updated every time the editor is loaded which is something we're trying to avoid. I used Kadence as an example as their unique IDs remain constant on editor load.
This bug, albeit related to the method of registering the ID, only arose on 6.5 update.

@HardeepAsrani
Copy link
Contributor

HardeepAsrani commented Sep 23, 2019

@diggeddy When I say updates each time the block is loaded, it meant on its initial load. If you add a block in the editor, then it will have the same ID forever. (Update, i If you duplicate it or copy-paste the block to somewhere, only then the ID will change. So the ID stays the same, while getting updated when duplicated. :)

Update, it does change on every block load, I forgot about it. But yes, that's the best we could find. We ask users to not use the ID but to add a custom CSS class for CSS customizations.

But I'm not sure how Gutenberg can have something to make the process better, unfortunately. Let's see what we find. :)

@HardeepAsrani
Copy link
Contributor

Regarding "Duplicated block should register new ID in the editor before publishing. This is pre-6.5 behavior."

Blocks don't really register a new ID in Gutenberg, but it's done by the plugins like Kadence & Otter. :)

@talldan talldan added [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes. [Status] Not Applicable Issue outside Gutenberg, is not a bug, or is a support request. labels Sep 24, 2019
@talldan
Copy link
Contributor

talldan commented Sep 24, 2019

@diggeddy I see you've created stellarwp/kadence-blocks#65, which in my opinion is the best first step since Gutenberg isn't the creator those unique IDs, the plugin implements this behaviour.

I think the best approach would be for the plugin developer to investigate first. If they discover that there is a backwards compatibility issue in Gutenberg, they should be able to report which APIs have the issue and it can then be investigated here.

I'll close the issue in the meantime, but it can always be reopened if it's discovered the problem lies here.

@talldan talldan closed this as completed Sep 24, 2019
@diggeddy
Copy link
Author

Thanks @talldan - in the absence of a core function for generating stable unique IDs the Kadence method has proven to be the only stable method. We're trying like Ben from Kadence to understand what was changed in 6.5 that broke this function when duplicating blocks. Any insights are appreciated. Ben has commented on the Kadence github regarding this.

@talldan
Copy link
Contributor

talldan commented Sep 27, 2019

@diggeddy I've had the same issue previously with ids, definitely something that's not so easy to implement in blocks.

I have an open issue where I'm trying to gather ideas - #17246.

@htmgarcia
Copy link

htmgarcia commented Jan 18, 2021

@HardeepAsrani the method used in Otter Blocks forces the ID to be updated every time the editor is loaded which is something we're trying to avoid. I used Kadence as an example as their unique IDs remain constant on editor load.
This bug, albeit related to the method of registering the ID, only arose on 6.5 update.

Hi @HardeepAsrani,
I'm curious if there is a technical disadvantage to allow the editor assign new IDs to blocks every time the post/page is edited?


Regards

@HardeepAsrani
Copy link
Contributor

Hi @HardeepAsrani,

I'm curious if there is a technical disadvantage to allow the editor assign new IDs to blocks every time the post/page is edited?

Hell no, just something I hadn't realized then and fixed after the issue came to my notice. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Status] Not Applicable Issue outside Gutenberg, is not a bug, or is a support request. [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes.
Projects
None yet
Development

No branches or pull requests

4 participants