Create Block: consider not using 'create-block' for namespace

[t-hamano]

What problem does this address?

In this issue, I would like to discuss plugins generated from @wordpress/create-block and whether create-block should be used for the namespace of the block.

For example, run create-block with the following command:

npx @wordpress/create-block guten-pride

In this case, file names, plugin and block are defined as follows:

PHP File

• File name: guten-pride.php
• Plugin Name: Guten Pride
• Text Domain: guten-pride
• @Package: create-block

block.json

• name: create-block/guten-pride
• title: Guten Pride
• textdomain: guten-pride

SCSS Files

• Block class: .wp-block-create-block-guten-pride

Javascript Files

• Textdomain: guten-pride

My main concern is that the namespace of the block is fixed to 'create-block'.

If you search for the keyword create-block/ in WordPress Directory Searcher, you will see that several plugins have already been registered.

Furthermore, since create-block is not allowed as a registrable namespace in the block directory, plugin developers will be aware of this after the plugin is released.

What is your proposed solution?

This is not a perfect solution, but I want to suggest using other string (e.g. brand name) instead of create-block in the generated files:

PHP File

• File name: guten-pride.php (same)
• Plugin Name: Guten Pride (same)
• Text Domain guten-pride (same)
• @Package: create-block > guten-pride

block.json

• name: create-block/guten-pride > my-brand/guten-pride
• title: Guten Pride (same)
• textdomain: guten-pride (same)

SCSS Files

• Block class: .wp-block-my-brand-guten-pride > .wp-block-my-brand-guten-pride

Javascript Files

• Textdomain: guten-pride (same)
  I think the naming would be very reasonable if create-block could support plugins with multiple blocks, as discussed in this issue.

This command does not work now, but I expect the following results in the future:

npx @wordpress/create-block guten-pride --namespace=my-brand --blocks block-a block-b

The block names generated from this command are:

• my-brand/block-a
• my-brand/block-b

[gziolo]

@t-hamano, thank you for opening this issue. It's definitely something that we should document better, so it's easier to reason what is the best practice when picking the block name.

@ryanwelcher, something to think about as we work towards the goal of having better support for multiple blocks in the single plugin. In particular, we need to make it clear that textdomain defaults to the plugin slug when not defined, so it's more likely to have it set to the same value. It contrasts with the namespace from the block name, which is a way to group several blocks under one brand or developer name.

[gziolo]

@mburridge and @jonathanbossenger, you are currently working on learning materials for block development. Any ideas on how to mitigate this issue? We could disallow using create-block as the namespace in the interactive mode when running npx @wordpress/create-block, but it might be more tricky when using the quick mode that doesn’t prompt questions in the terminal.

[mburridge]

When a slug is not provided the command goes into interactive mode and the user is prompted to create one, so likewise if --namespace is not provided the user could be prompted for one even if they've provided a slug.

So even if they've provided a slug and no --namespace is provided on the command line a more limited interactive mode is entered.

The same could be done for --title, i.e. anything needed for identification purposes within the scaffolded plugin that is not already provided on the command line could be prompted for via a more limited interactive mode. What do you think?

[jonathanbossenger]

Hmmm, this is an interesting question.

Personally, as an ex-plugin developer, I expect that any tool I use to create code is going to require me to make changes to things like namespaces. In fact, I specifically reference this in my video tutorial on Learn WordPress about using the code from create-block (https://videopress.com/v/jQnZe0t4?at=555). You will see I change both the namespace and the block name.

Sadly, the truth of the matter is that developers can be lazy, hence the reason there are 146 instances of 'create-block/' in the WordPress plugin directory, and probably the reason why the plugin submission process now prevents that usage.

I don't think disallowing create-block in the interactive mode is the answer, for the reasons @gziolo has listed above. Also, if the plugin checker returns a positive on the use of create-block, it's quick for the plugin developer to make the change.

The one option I thought of when I was recording the above tutorial was to change how the name is generated by create-block:

Given a plugin slug of plugin-slug, the user would run the following command for the quick mode

npx @wordpress/create-block plugin-slug

The name property could then be generated as

plugin-slug/plugin-slug-block

This would keep the namespace unique to the plugin

[gziolo]

The one option I thought of when I was recording the above tutorial was to change how the name is generated by create-block:

Given a plugin slug of plugin-slug, the user would run the following command for the quick mode

npx @wordpress/create-block plugin-slug

The name property could then be generated as

plugin-slug/plugin-slug-block

This would keep the namespace unique to the plugin

That sounds like an interesting idea to reuse the plugin slug as the namespace when using the quick mode. Although it would also impact function and class names that would repeat the same keywords, for example: wp-block-plugin-slug-plugin-slug, or function plugin_slug_plugin-slug_block_init.

[ryanwelcher]

Something to consider here as well is that now that create-block supports --no-plugin mode, users can add more blocks quite easily. My concern with using the slug as the namespace is that you would have a different namespace for each, possibly related, block. This will make it very hard to use registerBlockCollection etc.

I think my vote here would be to have the tool go into interactive mode if there is no slug or namespace passed. As we move the tool forward, I can see how the importance of defining a namespace will become greater.

[ryanwelcher]

As per the bug scrub, perhaps adding something about the namespace issues here would suffice