#6170 closed defect (bug) (fixed)
Ignore blocks with variables in the name.
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Component: | Plugin Directory | Keywords: | |
| Cc: |
Description
As mentioned in slack, this plugin shows a block defined where the author didn't intentionally add one.
A framework used by the plugin turns out to call register_block_type() with a variable block name, and ultimately ends up with a truncated block name as a result of it.
We should explicitly ignore any blocks that appear to use variables in their name parameter if possible.
Detected block: csf-gutenberg-block/block-
Change History (9)
#2
follow-up:
↓ 4
@
3 years ago
In v1.1.1 I tried commenting out line 301 and line 321-331, but "This plugin provdes 1 block" notice still appears on the plugin description page.
#3
@
3 years ago
The culprit could be this js file: https://plugins.trac.wordpress.org/browser/system-dashboard/tags/2.4.2/vendor/codestar-framework/assets/js/gutenberg.js which has a registerBlockType function? Once I downgrade to free version of the framework, which does not contain this js file, the "This plugin provides 1 block" section on the plugins page in .org repo went away.
#4
in reply to:
↑ 2
@
3 years ago
Replying to qriouslad:
In v1.1.1 I tried commenting out line 301 and line 321-331, but "This plugin provdes 1 block" notice still appears on the plugin description page.
The check is based on regular expressions, not code execution, so commenting it out would've made no difference.
The culprit could be this js file: https://plugins.trac.wordpress.org/browser/system-dashboard/tags/2.4.2/vendor/codestar-framework/assets/js/gutenberg.js which has a registerBlockType function?
Yes. The idea of this ticket is that this code should not be triggering the block extraction:
registerBlockType('csf-gutenberg-block/block-'+block.hash, {
If it was registerBlockType('csf-gutenberg-block/block-', { then that should be imported, but as the block name/slug there is being concatenated, we should probably ignore it (because we can't be sure what the slug actually is)
Thanks @dd32 for opening this ticket!