Registered blocks list on plugins README displaying wrong labels.

[wetah]

Hi, I hope this is the right place to point that out. Recently we released a new version of our plugin, which registers 11 blocks. In the README, the list is there, but al the blocks are labeled with the name of our plugin:

​https://wordpress.org/plugins/tainacan/

This was not happening in previous versions, but I am not sure if it is something related to our plugin because we didn't change much related to block registration. Besides that, I noticed it is happening in a few other plugins:

​https://wordpress.org/plugins/grids/
​https://wordpress.org/plugins/kadence-blocks/
​https://wordpress.org/plugins/wpforms-lite/

Are we doing something wrong?

[Otto42]

It is possible that it is not recognizing the blocks from the registerBlockType call because your JS code is compressed and unreadable.

Where are the calls to the registerBlockType function in the plugin, for these blocks? If it can't find the title of the block, then it defaults the title to the name of the plugin.

The code to find the blocks in the plugin is complex, but public:
https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/cli/class-import.php#L729

[wetah]

Replying to Otto42:

Hey, thank you for the quick reply! Yes, we minimize our javascript, where the registerBlockType function is called. But that really has been done the same way in the last versions...

I checked the code that you linked. In this line:
https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/cli/class-import.php#L739

Where the regex matches the content, there is this

"#registerBlockType[^{}]{0,500}[(]\s*[\"']([-\w]+/[-\w]+)[\"']\s*,\s*[{]\s*title\s*:[\s\w(]*[\"']([^\"']*)[\"']#ms"

Now, I am a total noobie on ReGex, please don't judge me. But trying a bit on this playground: ​https://regex101.com/, it seems that if I paste:

registerBlockType[^{}]{0,500}[(]\s*[\"']([-\w]+/[-\w]+)[\"']\s*,\s*[{]\s*title\s*:[\s\w(]*[\"']([^\"']*)[\"']

They explain me an error: "/ An unescaped delimiter must be escaped with a backslash (\)". So updating the pattern to:

registerBlockType[^{}]{0,500}[(]\s*[\"']([-\w]+\/[-\w]+)[\"']\s*,\s*[{]\s*title\s*:[\s\w(]*[\"']([^\"']*)[\"']

It was able to detect my blocks names, even in the minified js. Does it sounds correct or am I being naive?

It is possible that it is not recognizing the blocks from the registerBlockType call because your JS code is compressed and unreadable.

Where are the calls to the registerBlockType function in the plugin, for these blocks? If it can't find the title of the block, then it defaults the title to the name of the plugin.

The code to find the blocks in the plugin is complex, but public:
https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/cli/class-import.php#L729

[Otto42]

I am not a regex master, but I'll take a look later. In the meantime, where can we find the original javascript code? Just for comparison?

[wetah]

Great! We have 11 blocks, so I'm choosing one as example here. You can check the other based on the path:

• Source file on github: ​https://github.com/tainacan/tainacan/blob/develop/src/views/gutenberg-blocks/tainacan-collections/carousel-collections-list/index.js
• Bundled file on trac: ​https://plugins.trac.wordpress.org/browser/tainacan/trunk/assets/js/block_carousel_collections_list.js

Replying to Otto42:

I am not a regex master, but I'll take a look later. In the meantime, where can we find the original javascript code? Just for comparison?

[dd32]

Just noting that to remain plugin-directory compliant / GPL compliant either the source files need to be bundled, or it's obvious where to find the non-built versions.. I haven't looked at the plugin, but I'm just noting that here since it's common for JS plugins to not include the human readable source or make it obvious where to find it..

Looking at the minified JS here, using regular expressions makes it very hard to match, as it's hard for PHP to know that the call to f() here is a __() and is within a registerBlockType() call: var d=wp.blocks.registerBlockType,f=wp.i18n.__, ..... d("tainacan/carousel-collections-list",{title:f("Tainacan Collections Carousel","tainacan"),

We do have some JS-based parsing that should detect these blocks (Stored as e2e_blocks in the directory) which was intended on replacing this regex method, but that hasn't been done (yet?)

[tellyworth]

Replying to dd32:

We do have some JS-based parsing that should detect these blocks (Stored as e2e_blocks in the directory) which was intended on replacing this regex method, but that hasn't been done (yet?)

That's only run on block directory plugins. It's possible it was part of the problem. After running the CLI import script a couple of times while attempting to debug, the data appears to be good now. I'm not sure if that was the cause of the change or not.

[dd32]

Replying to tellyworth:

That's only run on block directory plugins.

Ahh yes, that certainly explains why we're not using that here.

[wetah]

Hey guys, thank your for everything!

@tellyworth it is indeed working fine now!

@dd32 I am aware of the need for offering a clear display of the source files. We have links to the source code in our official website, which is linked in the plugin page as well. But I believe we can make it more explicit with the links directly on the readme, our intention is to keep it as open source as we can. If you have any suggestions to improve this, I am open to hear it as well. The idea of removing the non-built files from the SVN came from a core contributor, because he suggested that having both files there (bundle and source ones) was causing another issue that I have with translations in my gutenberg blocks.

Finally, should I close this ticket or do you guys will discuss it more?

[wetah]

Ok, false positive... the list of blocks is messed up again :(

[dd32]

​https://wordpress.org/plugins/tainacan/

This plugin has moved to using block.json, no longer shows the issue.

Based on my comment above, if the minified JS was the following, we had no chance at parsing it:

d=wp.blocks.registerBlockType,f=wp.i18n.__, ..... d("tainacan/carousel-collections-list",{title:f("Tainacan Collections Carousel","tainacan"),

​https://wordpress.org/plugins/grids/

This plugin uses a ​block registration in PHP that doesn't include the title, and the ​Javascript doesn't include a clear way to get the title either - the minification obfuscates the code too much.

​https://wordpress.org/plugins/kadence-blocks/
​https://wordpress.org/plugins/wpforms-lite/

These plugins have switched to using block.json.

I'm not seeing anything we can do to improve the situation here for the time being. The only way we could potentially resolve this would be loading a Javascript WordPress environment.

Related: #5971