WordPress.org

Making WordPress.org

Opened 5 months ago

Last modified 4 months ago

#5513 new defect

Registered blocks list on plugins README displaying wrong labels.

Reported by: wetah Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

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?

Change History (9)

#1 follow-up: @Otto42
5 months ago

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

#2 in reply to: ↑ 1 @wetah
5 months ago

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

#3 follow-up: @Otto42
5 months ago

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?

#4 in reply to: ↑ 3 @wetah
5 months ago

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

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?

#5 follow-up: @dd32
5 months ago

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?)

Last edited 5 months ago by dd32 (previous) (diff)

#6 in reply to: ↑ 5 ; follow-up: @tellyworth
5 months ago

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.

#7 in reply to: ↑ 6 @dd32
5 months ago

Replying to tellyworth:

That's only run on block directory plugins.

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

#8 @wetah
5 months ago

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?

#9 @wetah
4 months ago

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

Note: See TracTickets for help on using tickets.