In this tutorial, you’ll learn how you can create your first simple block in Gutenberg. In recent years, the progress of Gutenberg API has been remarkable. It’s much simpler to get started with Gutenberg block development now than before thanks to @wordpress/create-block.
I assume that you have installed/setup and have basic knowledge of the following pre-requisites listed below:
- Node.js version 12.0.0 (or above).
- NPM (Node Package Manager) version 6.0.0 (or above).
- A Code Editor (recommended Visual Studio Code).
- Some basic knowledge about how CLI scripts work.
How can you scaffold your Gutenberg block?
- Interactive Mode
- Quick Mode
How do you trigger interactive/quick mode?
Unfortunately, there are no particular flags in @wordpress/create-block that simply allow us to specify the scaffolding mode.
Let’s look at the following command as an example
npx @wordpress/create-block [slug]
The slug is optional here, when the slug is not provided, The @wordpress/create-block will trigger interactive mode, otherwise quick mode is triggered.
You may want to run these scaffolding commands within your WordPress installation → wp-content → plugins directory. So that we can test the block plugin in WordPress later in this tutorial.
Let’s scaffold our block with each mode in order.
Scaffolding the Gutenberg block in Interactive Mode
Interactive mode allows you to thoroughly configure your block in a step-by-step process. This can be great when you’re new to Gutenberg API.
Let’s scaffold a new Gutenberg block, Suppose we’re creating an “awesome button block” (cause why not? 😎) for this particular example.
The scaffolding may take a couple of minutes. In order to verify if everything went right this is what you should be seeing on completion.
After scaffolding, there should be a newly created directory for your block. The name of the block should be “awesome-button-block” in our case (because of the slug we provided).
Scaffolding the Gutenberg block in Quick Mode
The task above can be much quicker with some additional flags. Instead of configuring the block in a step-by-step process, You can provide some flags to the script in a single command.
Let’s scaffold a similar block (as we did above) but in a quicker way.
npx @wordpress/create-block awesome-button-block --title "Awesome Button Block" --short-description "This is an awesome button block" --category "theme"
Command-line flags are a common way to specify options for command-line programs. Here is a list of flags you can use when scaffolding with @wordpress/create-block.
Replace the values inside <> with your desired values before using the flags.
|Outputs the current version number of @wordpress/create-block
-t <name> or
|Project template to use, Available values are “static” (default template), “es5”. Aside from these templates, You can also assign the name of an external npm package or a path to a local directory.
|Internal namespace for the block.
|Display title that is used for the block and the WordPress plugin.
|A short description, describing your block and WordPress plugin.
|Category for your block, By default core, provides the following categories:
In addition to these core categories, You can also create your own custom block category, That’s something we will cover in future tutorials.
|Enables the Integration for @wordpress/scripts package
|Disables the Integration for @wordpress/scripts package
|Enables the integration for @wordpress/env package, which lets you easily create a WordPress instance for testing/developing your plugin.
Assuming you’ve scaffolded the block, Open the recently created directory in a code editor. This is how the block plugin structure is currently (at the time of writing this tutorial).
Now that we’ve taken a look at the broad overview of the file structure, Let’s dive into some details regarding each file and its usage.
Main plugin PHP file. Currently, it should only contain server-side block registration.
The name of this file depends on what slug you’ve provided when scaffolding the block.
This directory holds all of your transpiled assets. For example, it contains the compiled CSS code from your SCSS (a CSS pre-processor, usually used in Gutenberg blocks for styling purposes) which can be understood by a browser.
A node_modules directory is a place where all of your block node dependencies are stored. It is recommended to exclude this directory from any version-controlled repository.
Package.json is a JSON-formatted file that is used by Node.js to keep track of the dependencies of a project in order to manage and run the project. It specifies the dependencies needed to build a Node.js project and is often used to manage the project’s dependencies. The file is usually located in the root directory of the project.
This file is automatically generated for any operations where npm modifies either the node_modules tree or package.json. This file allows users to lock their dependencies to a specific version, reducing the risk of breaking code when upgrading npm packages.
This JSON file includes basic metadata regarding the block. block.json was introduced recently and provides many benefits out of the box when used. I think “block.json” is something that we’ll cover in our future tutorials, but here are some top benefits of using block.json:
- Conditional Enqueuing: The frontend assets for the block will only be enqueued when a particular block is used.
- Lazy Loading: When a theme supports lazy loading assets, blocks registered with block.json will have their asset enqueuing optimized out of the box.
Includes an edit component, that represents how a block will behave in Gutenberg editor.
Includes a save component, that represents how a block should render in the frontend.
The save component should only be dependent on block attributes, and should not contain any dynamic react implementations, otherwise, a block validation error may occur.
This is where the block registration takes place in the client-side Gutenberg API.
A stylesheet that will be enqueued/applied in the Gutenberg editor.
A stylesheet that will be enqueued/applied in on the front-end (only when the block is used).
A .gitignore file can be used to tell Git which files to ignore when committing your project to a version-controlled repository.
.editorConfig helps maintain consistent coding styles for multiple developers.
Includes basic description regarding the plugin, Used by WordPress to display plugin information.
Testing the block
Now that we’ve covered how to scaffold a Gutenberg block with some basic overview, let’s test how the block currently looks in the Gutenberg editor and frontend.
Testing the block in Gutenberg editor
This is how you can insert the block in the Gutenberg editor.
In case you wonder, why there is “Awesome Button Block – hello from the editor!” written in the block? well, that content is generated automatically by the scaffolding script (@wordpress/create-block).
Testing the Gutenberg block in frontend
Now, let’s test how the block currently appears on the frontend, in order to test the block on the frontend, save the post first like so
After saving, visit the newly created post like so:
This is how the block should currently appear on frontend:
Again, there is dummy content generated from the scaffolding script.
Here are some useful resources you might want to check out
Official Block API Handbook: Official handbook for creating Gutenberg blocks.
WordPress Environment: Let’s you quickly set up a WordPress instance for testing and developing plugins.
WordPress Scripts: A collection of useful scripts created specifically for WordPress development.
Example Gutenberg Blocks: This repository contains example Gutenberg blocks.
Package.json: Learn more about package.json
Package-lock.json: Learn more about package-lock.json