Dublin Library

The Publishing Project

Building Gutenberg Blocks (Part 1)

  • 6 min. read

 

Whether we like it or use it, the Gutenberg editor is here to stay. While I don't use it for my own content and have developed themes that rely on the classic editor plugins, I realize that any WordPress shop moving forward needs to at least be aware of how to build blocks. It's unlikely that the Classic Editor plugin or other means to disable Gutenberg will remain available past 2022 (when the Classic Editor plugin is supposed to stop being fully supported). So this post will cover the creation of Gutenberg blocks and some basic setup in both PHP and Javascript ## Creating the build system The following block examples are meant to be built inside a plugin. They won't work if installed inside a theme, which is also not recommended and will result in your theme being rejected for inclusion in the plugin directory. ### PHP setup On the root of the plugin folder, we'll add the main PHP file to be the driver for all the blocks that we will create. The first part is the plugin metadata. The information here will allow WordPress to use the plugin. The name is required, everything else is optional. ```php 'rivendellweb-blocks-example-01', ) ); if ( function_exists('wp_set_script_translations' ) ) { wp_set_script_translations( 'rivendellweb-blocks-example-01', 'rivendellweb-blocks' ); } } add_action( 'init', 'rivendellweb_blocks_example_01_register_block' ); ``` ### Javascript / React The Javascript portion of the block uses the `i18n` and `blocks` packages from WordPress to build the block. If you've done work with internationalization you may recognize the `__()` command as the command you use to internationalize strings. We first import the components that we want to use. For this block, we'll define the styles inside a constant, `blockStyle`, that will be used for both the editor and the rendered content. The block title uses a localized string to indicate that translators can work with it. The icon is one of those available in the WordPress dashicon library. The part that surprised me the most is the need for two statements with the same content. The `edit()` creates the content specific to the editor while `save()` works with content specific to what will render on the client. The block will use the same style in the editor and the front end. ```js import { __ } from '@wordpress/i18n'; import { registerBlockType } from '@wordpress/blocks'; const blockStyle = { backgroundColor: '#639', color: '#fff', padding: '20px', }; registerBlockType( 'rivendellweb-blocks/example-01', { title: __( 'Example 01', 'rivendellweb-blocks' ), icon: 'universal-access-alt', category: 'layout', example: {}, edit() { return (

Notice

Hello World, step 1 (from the editor).

); }, save() { return (

Notice

Hello World, step 1 (from the front end).

); }, } ); ``` We could create different constants holding different styles and then use them to produce different results for the editor block versus what appears in the front end. ### External Styles SO far all the styles have been hardcoded to the block. In this example, we'll make the block use an external stylesheet for styling the block. To use external style sheets we first have to remove the constant containing the styles for the element. We then add one or more calls to `wp_register_style` to add the stylesheets. We also have to modify the call to `register_block_type` to accommodate the styles - **`style`** is used for the default styles - **`editor_style`** is used for editor styles if they are different than the default. This loads after the default styles so they will override the basic styles if they are different. ```php 'rivendellweb-blocks-example-02', 'editor_style' => 'rivendellweb-blocks-example-02-editor-stylesheets', 'editor_script' => 'rivendellweb-blocks-example-02', ) ); ```

Edit on Github