-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider a scaffolding command dedicated to Gutenberg blocks #88
Comments
👍
I'm generally in support of this. We can discuss the specifics of the implementation along the way.
If the scaffolded code was solely JavaScript, I think
I'm on the fence as to whether this is a good idea. I don't fully understand the value, nor am I sure this is a reasonable expectation for usage. Open to further exploration though.
Potentially. If this is the direction you'd like to head, it might make more sense to create a standalone plugin that implements both a web interface and a WP-CLI command. Personally though, I think the level of effort is low enough to add a |
I agree, |
👍 on having |
I was referring to the specific use case of JS scripts. At the moment {
"name": "gutenblock",
"version": "0.1.0",
"main": "Gruntfile.js",
"author": "Gutenberg",
"devDependencies": {
"grunt": "~0.4.5",
"grunt-wp-i18n": "~0.5.0",
"grunt-wp-readme-to-markdown": "~1.0.0"
}
} Grunt exposes two tasks: {
"name": "gutenblock",
"version": "0.1.0",
"author": "Gutenberg",
"devDependencies": {
"wp-scripts": "~0.1.0",
},
"scripts": {
"i18n": "wp-scripts i18n",
"readme": "wp-scripts readme",
}
} There are a few advantages of this approach:
This becomes even more useful when you introduce new scripts and have dozens of plugins to update. More advanced example from the article Tools without config by @kentcdodds: |
Yes, this is what I'd like to start with and then we can discuss further steps. @danielbachhuber, what would be your advice on the technical level on how to tackle this new command? It looks like it could a slightly modified version of $files_written = $this->create_files( array(
- $plugin_path => self::mustache_render( 'plugin.mustache', $data ),
+ $plugin_path => self::mustache_render( 'plugin-block.mustache', $data ),
$plugin_readme_path => self::mustache_render( 'plugin-readme.mustache', $data ),
"$plugin_dir/package.json" => self::mustache_render( 'plugin-packages.mustache', $data ),
+ "$plugin_dir/$plugin_slug.js" => self::mustache_render( 'plugin-block-js.mustache', $data ),
"$plugin_dir/Gruntfile.js" => self::mustache_render( 'plugin-gruntfile.mustache', $data ),
"$plugin_dir/.gitignore" => self::mustache_render( 'plugin-gitignore.mustache', $data ),
"$plugin_dir/.distignore" => self::mustache_render( 'plugin-distignore.mustache', $data ),
"$plugin_dir/.editorconfig" => file_get_contents( self::get_template_path( '.editorconfig' ) ),
), $force ); |
I think we'd want something closer to Generally, the behaviors should be similar to
Correct. At a high-level, you'll need to implement your base block code as one or more mustache templates. The command's responsibility is to populate the templates and then create files with the template content. |
@danielbachhuber many thanks for your great hints, it makes perfect sense to have My last 2 questions (for now 😄 ):
|
|
Nope. Commands are expected to be orthogonal. However, we can include block scaffolding as a default behavior of |
@nerrad, this is exactly what I was looking for. Yes,
@danielbachhuber I will code it with the assumption that plugin is already there. Let's circle back to this once it's done. Thanks again 💯 |
@gziolo As a total aside, that inquirer library looks really cool. |
@danielbachhuber, can you assign me to this one? I'll work on it this week. I'll open a PR tomorrow. |
@gziolo I've tagged v1.1.0 of From your PR:
This would be a very helpful next step, I think. In reading through the scaffolded code to understand it (not solely review for code quality), my immediate thought was: "how do I update my existing shortcode to work like a block?" |
Does it mean it will be available in the latest version of
Yes, let's do it as part of the issue you just created. I need to find out what advanced examples are out there :) Should we close this issue? |
Ah, this was for Gutenberg, I will start another PR probably next week. Thank for your amazing help @danielbachhuber 💯 |
Nightly build is a bit of a misnomer. It's available now :) I've put out a call for feedback too. |
Another idea to throw into the mix: Add jsDoc to the scaffolded |
First implementation, together with extensive inline documentation, has been completed. |
I plan to add |
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:
It also raises the question if
wp-cli
would be able to install all dependencies listed inpackage.json
and execute the build step behind the scenes.Open questions
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.
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./wp-admin/plugin-editor.php
page to edit the new plugin directly in the code editor bundled with WP and implementssave
andedit
JavaScript methods for a newly bootstraped Gutenblock.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?The text was updated successfully, but these errors were encountered: