Wp-calypso: Simple Payments: Duplicated Blocks Retain Original Element ID

[tijosh]

Steps to reproduce

1. Add a new page to any site with Gutenberg (WordPress.com or Jetpack-connected)
2. Create a new simple payments block and add dummy content
3. Duplicate the simple payments block and modify the content
4. Publish the page

What I expected

I expected the published page to have two different simple payments blocks.

What happened instead

The page contained two instances of the same simple payments block.

Browser / OS version

Any

Screenshot / Video

Context / Source

1812849-zen
3450644-hc

[gwwar]

cc @rodrigoi do you mind helping gauge the severity of this issue?

[rodrigoi]

TL;DR;

The only way to fix this using the current Block API is disabling the use of multiple SP blocks on the same post, via the multiple support option. And that's not a viable solution.

---

I think this is not fixable right now, given the way Gutenberg clones blocks. Let me elaborate on why.

Simple Payments Blocks are backed up by a custom post type and a shortcode. Every time you create a block, a custom post is created. All the form fields are also saved as attributes and used to render the preview. One of those attributes is the productId, that corresponds to the custom post ID.
The preview rendered on Gutenberg uses the attributes, but the client still uses a shortcode that just takes the postId of the product.

When Gutenberg duplicates a block, it takes all attributes, duplicating the productId. You can edit the information, but it will update the content that backs both blocks. Gutenberg used to have a useOnce support option for blocks that disabled the _Duplicate_ option, but it was deprecated in favor of multiple, that disables the _Duplicate_ option, but also prevents more than one block of that type to be used on the same post. So, using multiple is not an option.

To fix this, we need implement a new version of Simple Payments that does not use a custom post type, nor a shortcode, but instead uses attributes and renders HTML and JS. But I'm not entirely sure it'll be possible due to security concerns.

For the time being, the only workaround to this problem is manually removing the shortcode and the productId attribute using the _Code View_, so a new product post is created. You can see it in action here: https://cloudup.com/c_gCwcImGv7

[gwwar]

cc @Automattic/gutenpack in case this scenario affects other blocks

[gwwar]

Without looking deeply, some options come to mind:

1. Core contribution to add some more flexibility to disable the duplication option on this block
2. Or during duplication, override behavior to make sure that productId is marked as new and we generate a new CPT. This may also need a contribution to core for additional hookpoints.

[sirreal]

Thanks for the report and the ping. This is a tricky one and yet another example of how embedding a custom post type in a block inside the editor is very difficult or impossible (without core changes) to do right.

A quick note that pasting the same Simple Payments shortcode multiple times in the editor will likely produce the same result.

[gwwar]

A quick note that pasting the same Simple Payments shortcode multiple times in the editor will likely produce the same result.

@sirreal Right, I think we'll need to propose a new handler in the core project on any duplication events for these sort of cases. I don't think it's too uncommon of a use-case. For example imagine wanting a custom anchor per block, or a serialized unique id.

[sirreal]

I agree, we'll need some changes in core in order to properly handle this. I did some investigation earlier and there doesn't appear to be anything available that we can use for this case.

[Aurorum]

Report here: Automattic/jetpack#11406

[scruffian]

Closing this in favour of the Jetpack issue: https://github.com/Automattic/jetpack/issues/11406