Hi there! We’re back with our tutorial to develop in Gutenberg. Last week we started a project that added a map block in WordPress. In that first post we defined what the requirements that our plugin has to meet were and we prepared the skeleton of what will end up being the final product, starting with the fantastic plugin boilerplate that we have created at Nelio.
Today comes the second part of the tutorial on how to create the map block. In this post we will see how to add a Google Maps map inside the WordPress editor and how to implement a user interface that allows us to manipulate its behavior.
A Quick Look at the Current Status of the Project…
In the current state of the project we have a simple Demoblock defined in
packages/blocks/demo/. This small block is the one that comes as an example in Nelio’s plugin boilerplate and looks like this:
Obviously, this isn’t what we want. We’re not interested in a heart icon followed by some text, but in something like this:
That is, we want a Google Map block with an optional marker in it. How can we move from the original example block that our boilerplate had to this other, more powerful block? Well that’s what we’re going to answer today!
But before that, let me invest a couple of minutes explaining what we have right now and how we’re going to move forward. I think that, if you understand the current state of the project, you’ll have an easier time following what will come next.
Understanding the Demo block…
As I’ve already said, the demo block is defined in
packages/blocks/demo/. In this folder you’ll find the styles of the block, its icon, and several files with the code that implements its operation. Let’s see the most important files.
On the one hand, there’s the main file:
index.js. This file exports three variables: the name of the block (
name), the definition of the block (
settings), and the styles that the block supports (
styles). These three variables are those used in
packages/blocks/index.js to register the block in Gutenberg (with
registerBlockType) and thus make it available to final users.
This main file, then, serves as an entry point to understand the block we are creating. In the object settings (
settings), we see three important properties:
attributes.jsfile defines all those properties of our block that are dynamic and, therefore, should be tweakable by our users. In the case of our Demo block, the only attribute that exists is the text the user has written, but the map block will have many more options: the coordinates of the center of the map, the default zoom level the map should use, what buttons (if any) should be visible to interact with the map, etc.
- The file
edit.jsis the one that defines how the block is displayed in the WordPress editor and what settings are offered to the user (both in the toolbar and in the sidebar of the block’s settings). In Demo, the
editsimply includes the
RichTextcomponent of WordPress to write the content. As we will see, the map block will be more complex and will also include additional settings.
save.jsdefines the method that will convert the block we were editing in Gutenberg into the HTML that must be rendered in the front-end. Again, in Demo we see that this function simply saves the contents of a
RichText.Content, but it could be anything else (as we will see next week in the third and last part of this tutorial).
Creation of the Map Block Based on the Demo Block Included in the Plugin Boilerplate
Once we understand exactly how the Demo block works, it’s time to ask ourselves: how do we create ours? Well, very easy: as Toni told us a few days ago, we simply have to duplicate the directory
packages/blocks/nelio-maps/ and start to modify everything necessary. I know, it’s easier said than done.
Let’s start with something easy:
attributes.js. This file contains all the properties that should be modifiable by our final users. In the previous post we specified what requirements our plugin should meet and, therefore, we outlined what things should be tweakable. Well, taking a look at the resulting
attributes.js you’ll clearly see what can be tweaked from our map block: zoom level, map center, visibility of different buttons… Super simple stuff!
The next point to modify is all that concerns the edition of the block in Gutenberg. To do this, we must dive into
edit.js. If you look closely, you will see that it is not much more complicated than what we had in our original Demo block.
The most important thing is in the block’s
render method (line 33), where we retrieve the attributes we just defined from an object named
this.props. We’ll use this properties to render the block and its setings, of course. This is what we have:
- A toolbar
ToolbarControls(line 66), which we defined in an external file named
toolbar.js(don’t worry, we’ll see its content in a minute).
- The block settings that appear in the editor’s sidebar (line 68), which we find in a component called
Inspectorthat we defined in
- The content of the block itself, which has two states:
- If I do not have a Google Maps API key available, we show a user notice (line 122).
- If we have this key, we show the map using
MapBlock(line 83). The map might include a
Marker(line 97), which is only visible when the option is activated, and might also be accompanied of a
div(line 104) with additional information about it.
Google Maps as a React Component
If we want to put a Google map in our editor, we must use a component that allows us to use the Maps API of Google Maps. Considering that Gutenberg is built on top of React, the logical thing to do is to find out if there’s a React component of Google Maps. And, sure thing, there’s one!
As you can read in the project’s documentation, first we have to add the component into our project. Just install and add the dependency running the following command:
npm install react-google-maps --save-dev
which adds a new entry in our
package.json and downloads the package into
How to Create a WordPress Component that Encapsulates a React Component
If we continue looking at the documentation of this React project for Google Maps, we will see that they recommend us to wrap their
GoogleMap component with our own component. Once it’s encapsulated, we will have to use our component in our plugin.
Well, let’s follow their lead and create a component called
MapBlock in its own file
map-block.js. And that’s it! We now have a map component ready that we can use in our Gutenberg block.
How to Add Block Settings in WordPress Editor’s Inspector
The next step is to configure how this map should look in the editor and add a few settings to tweak its appearance. To do this, we must add several settings sections in the Gutenberg sidebar. As I have already advanced, we achieve this with a component that we have called
Inspector and that we have defined in the file
If you take a look at this file, you will see that it follows the same pattern as always: we are defining a
Component with a
render method. This method pulls the relevant attributes in
this.props and returns the JSX with all the controls. In this particular case, it returns an instance of
InspectorControls (this tells WordPress that this content goes to the sidebar) with several
PanelBody sections. Let’s see each section in detail.
Basic Map Settings
PanelBody we found (line 47) has no
title and, therefore, always appears as a section that can not be closed:
The section defines a pair of
RangeControls, whose result you can see in the previous screenshot. These two controls allow us to modify the height of the map and its zoom level.
Another interesting and simple section is the one found on line 121. Here we add a few options to activate or deactivate the buttons that should be shown on the map when displayed in the front-end :
To do this, we simply have to use the default WordPress component
How to Add a Custom Style Section for Our Map Block
Another interesting section of our block is the style section (line 68). You can see the final result in the following screenshot:
It’s a special section because the component we use (
MapStyles) is not something that exists in WordPress by default, but something we have created for this block in particular. As you can see in the previous link, it is a component that loads a set of predefined styles in a component of type
ImagePicker (which, incidentally, does not exist by default in WordPress either—you can find it in
When the user selects any of the styles included in
MapStyles component invokes the
onChange function it’s been given (see line 76 of
inspector.js) passing two values: the name of the selected style and the associated JSON.
Finally, notice that one of the options that
MapStyles includes is a Custom style:
When selected, the component renders an additional text box (line 45) so that the user can enter their own style in JSON format. In case you did not know, the maps of Google Maps can be customized a lot!
How to Add a Marker into Our Map
As you see, a search box appears to search for locations in Google Maps (which we have implemented, again, with a custom component called
AddressSearch) and the ability to show or hide the text block in which to put additional information about the marker .
By the way, notice that the
AddressSearch component is based on a component called
StandaloneSearchBox, which is also part of the React project . What a pleasure it is to reuse the work of others!
How to Configure the Toolbar of a Block
The last thing we have to discuss is the toolbar. If you have understood how the sidebar works, the toolbar is a piece of cake.
The toolbar of our plugin is represented by the
ToolbarControls component defined in
toolbar.js. Here we simply add a component to define the alignment of the block (
BlockAlignmentToolbar, on line 42), a pair of dropdowns to center the map (line 50) and to modify the location of the marker (line 79), and a couple of extra buttons to change the location of the text box in which we can put additional information about the marker (lines 107 and 120).
Today we have seen how to create the entire editing interface of our map block. As you can see, it’s a process that might seem complicated at first glance, but becomes pretty natural quickly. In the end, the secret is to start from an example that is well organized (as our plugin boilerplate is) and build the interface step by step, reusing the components that WordPress offers or that already exist, or even creating your own.
See you next week with the last part of this tutorial, where we’ll see how to save our map and how to view it in the front-end.