The Block Editor solves (at least) one major problem WordPress users have faced for years. The Classic Editor was great when it came to content consisting of headings, paragraphs, and other individual elements, but it leaves a lot to be desired when you want to add dynamic or more complex content or features to your WordPress site. You could get around this by adding shortcodes or building out individual modules using ACF and the Flexible Content field, but at the end of the day, these features can only be so user-friendly and easy to manage. Your user can’t see what they’re working on and they’re ultimately filling out a form to build out content on their website.
Enter Gutenberg. Out of the box, you have better support for things like columns and full-width page elements. You can easily build out separate content sections, pull in dynamic content like your latest posts or archives, and embed social media posts or videos. And there’s no documentation on how to extend these features and build your own blocks!
After chatting at WordCamp Greenville earlier this year, Clifton invited me to share my knowledge on Gutenberg and how I felt the Block Editor was going to change the way we built WordPress sites. I thought what better way to do that than to show just how easy it was to get started building your own blocks. I returned to Greenville looking to remove as many barriers to entry as I could.
The way I presented this topic I suggested that you didn’t need to know React in order to get started building blocks. That’s because there are a couple of fantastic tools out there that can get you started, and WordPress provides a number of components designed to standardize block building and ultimately make it a lot easier to add some basic functionality to your block. Of course, some React knowledge will make it a lot easier to understand what is going on, but I wanted to cover this topic in a way that would empower developers used to working in PHP to build their own blocks.
I separated the demonstration out into three main tasks. Step 1: getting a custom block up and running, step 2: adding functionality (an editable field), and step 3: building a practical example.
You can find an entire walkthrough of this talk in my building-gutenberg-blocks repo on my Github profile. It walks through the demonstration I did from beginning to end. The only prerequisites being access to a local development environment (Local By Flywheel will get you started very quickly) and having Node.js installed on your machine.
After you have a local WordPress environment set up and Node.js (with npm 5.2+) installed, I used create-guten-block to install a pre-configured bare-bones Gutenberg block plugin on my WordPress environment. To do this, navigate to your plugins directory in Terminal, and run
npx create-guten-block my-block where
my-block is the name of your block. If everything is done correctly you should have a new plugin available to you on the Plugins page of your WordPress Admin. Activate that plugin and you will be able to add a new block to pages or posts that use the block editor.
You now have a custom block that is ready to be modified to do whatever it is you need to do! For the rest of the demonstration, we first gave the block some functionality. Up until this point, the block was static and displayed hard-coded content on the front end and in the admin. We worked through giving the block an editable field that saved and displayed on the front end of the site. With that complete, we moved on to build a simple content dropdown that displayed a heading and hidden content. When clicked, the content would dropdown and display below the heading.
I chose a content dropdown for this demonstration because it’s something I have built for almost every client website. It was simple in design and functionality but presented a very practical use case for building a custom block. In the past, I might have created this as a Flexible Content field using ACF or using a shortcode that had the content inside of it and the title as an attribute, but I feel that the end result we came up within this demonstration is a lot more user-friendly. The style on the back end is exactly what you will get on the front end and there’s no guesswork in what attributes it will accept. What you see is what you get.
Mark Marzeotti is a WordPress developer specializing in custom theme and plugin development.