As the work on the new WordPress editor progresses, we thought that it would be great to simplify Gutenberg on-boarding process for plugin developers. It is still being discussed how native Gutenberg extensibility would look like, but we are confident that the most common use case will be that developers will want to create new blocks. We discussed it a bit already and it seems like the best way to start is to create a scaffolding command which creates a block registered into the editor that needs to have only logic updated. It would be great to have it included in the core of wp-cli.

Initial implementation

On the technical side, the only thing that is necessary to create a plugin that registers a new block is to provide two files similar to what @pento shared here:

https://gist.github.com/pento/19b35d621709042fc899e394a9387a54

Please note that this code doesn't use build step (no Webpack, Babel, etc.). It's only PHP and JavaScript code that will work out of the box. JS uses ES5 syntax that can run on every browser including IE11. It's a conscious decision to provide a default starter kit that produces code be approachable for developers coming from all possible backgrounds.

Side note: This sample code is a more advanced use case which uses post meta, which we can omit in the initial implementation.

Further iterations

We want to support also developers that want to use more advanced JavaScript tooling and we are happy to discuss how to provide more advanced tooling that would be enabled on demand things like:

• build step (Webpack, Grunt, whatever)
• code transpilation to allow ES.next syntax
• linting
• testing
• etc.

It also raises the question if wp-cli would be able to install all dependencies listed in package.json and execute the build step behind the scenes.

Open questions

1. We can also trigger a wider discussion if we want to move that tooling to a separate npm package to make them easier to reuse. I have also shared a blog post where I explain more in-depth advantages of starter kits and reusable scripts in the context of WordPress and Gutenberg.

2. I already asked this question on Slack, but let me rephrase and ask again here. What do you think about the following flow for new developers:

   • wp scaffold plugin gutenberg (or something like that) using ssh to do it on the server the gutenberg plugin is being used on.
   • User goes to /wp-admin/plugin-editor.php page to edit the new plugin directly in the code editor bundled with WP and implements save and edit JavaScript methods for a newly bootstraped Gutenblock.

3. Would it be possible to wrap wp-cli command with the interface exposed in Gutenberg, and create a new plugin that registers a block behind the scenes by filling in a form that mirrors CLI options?