Letâs acknowledge that developing for WordPress is weird right now. Whether youâre new to WordPress or have worked with it for eons, the introduction of âFull-Site Editingâ (FSE) features, including the Block Editor (WordPress 5.0) and the Site Editor (WordPress 5.9), have upended the traditional way we build WordPress themes and plugins. Even though itâs been five years since we met the Block Editor for the first time, developing for it is difficult because documentation is either lacking or outdated. Thatâs more of a statement on how fast FSE features are moving, something Geoff lamented in a recent post. Case in point: In 2018, an introductory series about getting into Gutenberg development was published right here on CSS-tricks. Times have changed since then, and, while that style of development does still work, it is not recommended anymore (besides, the In this article, I intend to help you get started with WordPress block development in a way that follows the current methodology. So, yes, things could very well change after this is published. But Iâm going to try and focus on it in a way that hopefully captures the essence of block development, because even though the tools might evolve over time, the core ideas are likely to remain the same.
What are WordPress blocks, exactly?Letâs start by airing out some confusion with what we mean by terms like blocks. All of the development that went into these features leading up to WordPress 5.0 was codenamed âGutenbergâ â you know, the inventor of the printing press. Since then, âGutenbergâ has been used to describe everything related to blocks, including the Block Editor and Site Editor, so itâs gotten convoluted to the extent that some folks depise the name. To top it all off, thereâs a Gutenberg plugin where experimental features are tested for possible inclusion. And if you think calling all of this âFull-Site Editingâ would solve the issue, there are concerns with that as well. So, when we refer to âblocksâ in this article what we mean are components for creating content in the WordPress Block Editor. Blocks are inserted into a page or post and provide the structure for a particular type of content. WordPress ships with a handful of âcoreâ blocks for common content types, like Paragraph, List, Image, Video, and Audio, to name a few. Apart from these core blocks, we can create custom blocks too. That is what WordPress block development is about (thereâs also filtering core blocks to modify their functionality, but you likely wonât be needing that just yet). What blocks doBefore we dive into creating blocks, we must first get some sense of how blocks work internally. That will definitely save us a ton of frustration later on. The way I like to think about a block is rather abstract: to me, a block is an entity, with some properties (called attributes), that represents some content. I know this sounds pretty vague, but stay with me. A block basically manifests itself in two ways: as a graphical interface in the block editor or as a chunk of data in the database. When you open up the WordPress Block Editor and insert a block, say a Pullquote block, you get a nice interface. You can click into that interface and edit the quoted text. The Settings panel to the right side of the Block Editor UI provides options for adjusting the text and setting the blockâs appearance. When you are done creating your fancy pullquote and hit Publish, the entire post gets stored in the database in the What does this representation look like? Have a look:
Looks like plain HTML, right?! This, in technical lingo, is the âserializedâ block. Notice the JSON data in the HTML comment, Letâs say that you close the Block Editor, and then some time later, open it again. The content from the relevant
â¦it says out loud to itself:
As a block developer, your job is to:
One thing to note is that all of this conversion from serialized data to graphical interface â and vice versa â takes place only in the Block Editor. On the front end, the content is displayed exactly the way it is stored. Therefore, in a sense, blocks are a fancy way of putting data in the database. Hopefully, this gives you some clarity as to how a block works. Blocks are just pluginsBlocks are just plugins. Well, technically, you can put blocks in themes and you can put multiple blocks in a plugin. But, more often than not, if you want to make a block, youâre going to be making a plugin. So, if youâve ever created a WordPress plugin, then youâre already part-way there to having a handle on making a WordPress block. But letâs assume for a moment that youâve never set up a WordPress plugin, let alone a block. Where do you even start? Setting up a blockWe have covered what blocks are. Letâs start setting things up to make one. Make sure you have Node installedThis will give you access to Create a project folderNow, you might run into other tutorials that jump straight into the command line and instruct you to install a package called I personally go this route when setting up my own blocks, but humor me for a moment because I want to cut through the opinionated stuff it introduces and focus just on the required bits for the sake of understanding the baseline development environment. These are the files Iâd like to call out specifically:
In addition to these files, thereâs also the Having these files and the The aforementioned
Install block dependenciesAssuming you have the three files mentioned in the previous section ready, itâs time to install the dependencies. First, we need to specify the dependencies we will need. We do that by editing the
View without comments
The There are a number of other packages that WordPress maintains for various purposes. For example, the You donât actually need to install these packages, even if you want to use them. This is because these During block registration in the plugin file, the âassetsâ file is implicitly used to tell WordPress the package dependencies for the block. These dependencies are automatically enqueued. All of this is taken care of behind the scenes, granted you are using the
Now that If youâre coming from classic WordPress plugin development, then you probably know that all plugins have a block of information in the main plugin file that helps WordPress recognize the plugin and display information about it on the Plugins screen of the WordPress admin. Hereâs what
Thatâs in the main plugin file, which you can call whatever youâd like. You might call it something generic like Youâre going to want to change some of the details, like making yourself the author and whatnot. And not all of that is necessary. If I was rolling this from âscratchâ, then it might look something closer to this:
I wonât get into the exact purpose of each line since thatâs already a well-established pattern in the WordPress Plugin Handbook. The file structureWeâve already looked at the required files for our block. But if youâre using Hereâs whatâs in there at the moment:
Phew, thatâs a lot! Letâs call out the new stuff:
Block metadataI want to dig into the Hereâs what
Thereâs actually a bunch of different information we can include here, but all thatâs actually required is
Register the blockOne last thing before we hit actual code, and thatâs to register the plugin. We just set up all that metadata and we need a way for WordPress to consume it. That way, WordPress knows where to find all the plugin assets so they can be enqueued for use in the Block Editor. Registering the block is a two-fold process. We need to register it both in PHP and in JavaScript. For the PHP side, open up the main plugin file (
This is what the
Why are we pointing to the Alright, letâs move over to the JavaScript side of registering the block. Open up
Weâre getting into React and JSX land! This tells WordPress to:
Whatâs up with the A quick testWe can do some quick work to see our block working in the Block Editor and rendered on the front end. Letâs open
This is basically a stripped-down version of the same code we had before, only weâre pointing directly to the metadata in We can compile this by running If we drop the block into the content area, we get the message we return from the If we save and publish the post, we should get the message we return from the Creating a blockLooks like everything is hooked up! We can revert back to what we had in
Notice that the Back end markup (
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
April 2023
Categories |