Develop your own WordPress block - Part 2: Create a block plugin with create-guten-block

In this series of articles, I'll explain how you can build your own WordPress block from scratch. In the second part we will look at how you can create your first block plugin with create-guten-block , a starter toolkit for Gutenberg Blocks.

At the start of the series and first part is here .

Develop WordPress blocks with create-guten-block

The configuration of Webpack, Babel and Co. is quite confusing and complicated at first. For developers, however, it is worthwhile to deal with it a little. I can recommend the following two tutorials to those who would like to deal with this in more detail:

For this tutorial we choose the quick and easy way and use Create Good Block by Ahmad Awais. This is a zero configuration dev toolkit for WordPress Gutenberg Blocks, so we don't have to configure React, Webpack and Babel ourselves.

Create WordPress Block Plugin

To use the tool, you should have Node.js installed and be familiar with NPM . You also need a local server with a WordPress installation.

The installation takes place via the command line. First, go to the plugin directory of your local WordPress website.

 cd wp-content/plugins

Then you can create your block plugin with the command npx create-guten-block . The name for the WordPress plugin is also given to the command. You can choose any name. For our tutorial we will use themecoder-block .

 npx create-guten-block themecoder-block

The tool creates the plugin folder for us and installs all required node modules.

Create Good Block Installation

The installation can therefore take a few minutes.

Activate WordPress Block Plugin

After completing the installation, you can activate the plugin in your WordPress backend.

Theme Killer Block Plugin

The toolkit contains a dummy block as a boiler plate. In the Gutenberg Editor, you can search for CGB block to insert. The block just shows some text, with no input fields or options. We'll change the name later and make the block editable.

CGB standard block

For now, we now know that the installation worked properly.

Structure of the WordPress Block Plugin

For the next steps you will need an editor, e.g. VS Code .

We take a closer look at the files of the block plugin. If you open the plugin folder themecoder-block , you will find the following folders and files:

 ├── dist | ├── | ├── | └── | ├── node_modules | ├── src | ├── block | | ├── block.js | | ├── editor.scss | | └── style.scss | | | ├── blocks.js | ├── common.scss | └── init.php | ├── .eslintignore ├── .eslintrc.json ├── .gitignore ├── plugin.php ├── package.json ├──

At first glance, that looks complex. In part 1 I mentioned that a simple block plugin consists of only four files. Even if we now have a little more files, the basic block architecture can be found in them.

But one after anonther:

JavaScript tooling

In the root directory of the plugin you will find a number of files for the configuration of Git, ESLint and the NPM packages (.gitignore, package.json, etc). These are necessary for the entire tooling, but not for the actual functionality of the plugin.

The same goes for the folder / node_modules / where all tools like Webpack, Babel and ESLint are installed.

PHP files

The two PHP files plugin.php and src / init.php are important for the initialization of the plugin. The first file contains only the plugin header and includes the second file.

Init.php contains two functions that load the block script and the block stylesheets in the theme and in the WordPress editor. The two new action hooks enqueue_block_assets and enqueue_block_editor_assets are used for this.

 /** * Enqueue Gutenberg block assets for both frontend + backend. */ function themecoder_block_cgb_block_assets() { // Styles. wp_enqueue_style( 'themecoder_block-cgb-style-css', plugins_url( 'dist/', dirname( __FILE__ ) ), array( 'wp-editor' ) ); } add_action( 'enqueue_block_assets', 'themecoder_block_cgb_block_assets' ); /** * Enqueue Gutenberg block assets for backend editor. * */ function themecoder_block_cgb_editor_assets() { // Scripts. wp_enqueue_script( 'themecoder_block-cgb-block-js', plugins_url( '/dist/', dirname( __FILE__ ) ), array( 'wp-blocks', 'wp-i18n', 'wp-element', 'wp-editor' ) ); // Styles. wp_enqueue_style( 'themecoder_block-cgb-block-editor-css', plugins_url( 'dist/', dirname( __FILE__ ) ), array( 'wp-edit-blocks', 'themecoder_block-cgb-style-css' ) ); } add_action( 'enqueue_block_editor_assets', 'themecoder_block_cgb_editor_assets' );

For the sake of clarity, I've shortened the code and comments a bit.

In the latest version of Create-Guten-Block, the scripts are now only registered and integrated with register_block_type () :

 register_block_type( 'cgb/block-themecoder-block', array( 'style' => 'themecoder_block-cgb-style-css', 'editor_script' => 'themecoder_block-cgb-block-js', 'editor_style' => 'themecoder_block-cgb-block-editor-css', ) );

Even if the implementation has changed, the purpose of the file is still the same. I recommend opening init.php yourself in the editor and reproducing the code.

Folder dist /

dist stands for distribution and therefore contains the bundled files with compiled code, i.e. the result of our build process with Webpack. If you have studied the two PHP functions carefully, you have already noticed that they load the three files from the dist / folder:


Are you familiar with that? These are the block JS, block stylesheet and editor stylesheet, which I introduced in the first part as the central components of a block.

Folder src /

src stands for source and thus for the source files. This is where the development of the blocks takes place.

You can create as many JS and Sass files as you want here and have them bundled by Webpack. The folder structure is also up to you. After the build process, we always get the three compiled files in / dist /, regardless of whether you are programming one or two dozen blocks.

With Create-Guten-Block the file src / blocks.js is set as a so-called entry point . This means that Webpack reads this file and bundles all files that are imported from there. It is practically the start of our funnel, into which we dump our source files and code (ES6, JSX, SCSS) to stick with the metaphor from the first part.

Block development with create-good-block

If you now change a JavaScript file from the source folder and adjust the name of the block, for example, you will find that the change in WordPress initially has no effect. This is because in the Gutenberg Editor only the compiled scripts from the distribution folder are integrated, not the source files.

Therefore, before we can start developing Gutenberg Blocks, we have to initiate our Webpack process so that our code is also compiled. We go back to the command line and switch directly to our new plugin folder.

 cd themecoder-block npm start

You can start the build process with the npm start command.

create-good-block build process

Webpack will now automatically monitor the src folder and recompile the code every time you make a change. If you have syntax errors in your code, you will see a compilation error in your terminal.

In addition to the development mode, you can also generate production code with npm run build :

 npm run build

The code is compiled, minified and all comments are removed. The file size is thus reduced as much as possible in order to ensure that our blocks are integrated as efficiently as possible. The build process runs once and is not suitable for ongoing development, but for making your plugin available to the end user.

Outlook on part 3

After the setup and setup of our plugin and the tooling, we can finally start developing our own block in Part 3. Questions about the block setup or tooling can be asked in the comments 🙂

Overview of all articles in this series