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

Transforms: "isMatch" does not work for shortcode transformation #10674

Open
sayontan opened this Issue Oct 17, 2018 · 4 comments

Comments

Projects
None yet
5 participants
@sayontan
Copy link

sayontan commented Oct 17, 2018

Describe the bug
The Block API documentation talks about the use of isMatch to filter or specifically target certain blocks or nodes. This however does not seem to work if the transform from is of type: "shortcode".

To Reproduce
Steps to reproduce the behavior:

  1. Create a plugin with the following transform:
transforms: {
	from: [
		{
			type: 'shortcode',
			tag: 'gallery',
			isMatch: function(attributes) {
				return !empty(attributes.named.type);
			},
			attributes: {
				shortcode: {
					type: 'string',
					shortcode: function(named) {
						return JSON.stringify(named.named);
					}
				}
			}
		}
	]
},

  1. Create some gallery shortcodes in a post in the "Code Editor" mode:
[gallery ids="139,140,141,142,97"]
[gallery photoset_id="12345" type='flickr']

  1. In the Visual editor click on "Convert to Blocks"
  2. Both, the first and the second shortcode will be transformed to block you are registering

Expected behavior
I would expect the first shortcode to continue to be treated as a regular WordPress gallery, and the second to be treated as a block defined by my plugin. If isMatch is not the right way for this to happen, how would such targeting be done?

Use Case
There are multiple plugins today that use the same shortcode, with the gallery shortcode being one of the more commonly used ones. With the shortcodes there is a way to make them coexist by having specific attributes. Vendors typically use this approach to avoid shortcodes showing up in the front-end. E.g. in the two examples I have provided above the first gallery will render as per the inputs, while the second one will not be visible at all if you don't have the plugin.

When the plugin developer wants to use the Block API they would typically target their specific instances by applying certain match criteria for transformation. Without this capability they will end up inadvertently changing all shortcodes with the same tag to the same block type when the user clicks on "Convert to Blocks" for the first time.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: Windows 10
  • Browser Chrome
  • Version 69.0.3497.100

Additional context

  • Gutenberg version 3.90
@sayontan

This comment has been minimized.

Copy link
Author

sayontan commented Oct 22, 2018

@designsimply,
Not sure why this has been labeled "Help Request". This is a bug. If you look at the code to transform shortcodes to blocks it does not honor the isMatch attribute at all. The documentation on the other hand says that isMatch "provides an opportunity to perform additional checks on whether a transform should be possible".

@designsimply

This comment has been minimized.

Copy link
Contributor

designsimply commented Jan 30, 2019

@sayontan my apologies for not seeing your message sooner. I have updated the labels for you. I think I initially labeled this issue as a help request because you asked, "if isMatch is not the right way for this to happen, how would such targeting be done?" However, sometimes I don't get the labels right on the first try and I'm sorry for the trouble.

@simison

This comment has been minimized.

Copy link
Contributor

simison commented Feb 12, 2019

Just confirmed this bug/missing feature and it's kinda blocker for using conditional transforms, especially for the poor [gallery] shortcode (Automattic/wp-calypso#30723) that gets extended by various different plugins.

Currently, a block with the highest priority attribute wins the transform from all the other plugins.

Suppose these shortcodes and if every plugin implements isMatch, each plugin would only transform its own shortcode:

[gallery ids="1,2"] → core gallery
[gallery ids="1,2" layout="mosaic"] → Jetpack Tiled gallery
[gallery ids="1,2" layout="slideshow"] → Jetpack Slideshow gallery
[gallery] → shortcode block

An alternative approach could be to define specific attributes as required with a possible list of accepted values.

@ryelle

This comment has been minimized.

Copy link
Contributor

ryelle commented Feb 13, 2019

We're running into the same problem with the WooCommerce Blocks– we have a few different blocks that correspond to a single shortcode with different attributes. For example:

  • [products on_sale="true"] should transform to the "On Sale Products" block
  • [products best_selling="true"] should transform to the "Best Selling Products" block
  • [products ids="1,2,3"] should transform to the "Hand-picked Products" block

And so on (we have 7 blocks that all match different configurations of the products shortcode).

Having an isMatch option with the content/attributes from the shortcode would work & match the other transforms. The "required attributes" idea could work for most scenarios, but we might also want to say "don't transform if the shortcode has X attribute", because our block doesn't support it. (happy to give a few more examples & test things out, our shortcode is complex)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment