At this year’s WordCamp US, I was super excited by the possibilities that Gutenberg presented for WordPress. I came home and started making blocks. Having built a few custom block plugins, I’m even more excited. This isn’t a tutorial, instead, this is a reflection on what it’s like to develop for the WordPress of the future, as of Gutenberg version 1.9.1.
Yes, I was skeptical when Gutenberg was first released as a “beta”. I think calling it a beta was a mistake as what we had to work with six months ago was not feature complete. Version 1.9 isn’t feature complete either, but it’s getting there.
More importantly, the why is clear and the results are starting to show. In the past, I’ve preferred to write in Google Docs rather than WordPress. This is the first time I’ve been drafting Torque articles in Google Docs and wished I was writing in WordPress, but with Gutenberg.
Where Did My PHP Go?
I make no secret that as much as I love writing JavaScript in ES6, I’d rather be writing back-end code in PHP then writing front-end code at all. But, learning JavaScript front-end frameworks has made me enjoy front-end development. Still, I really like PHP.
The first complete, from scratch, block plugin I built for release has almost no PHP code. The PHP is just there to load JavaScript, CSS and register the block. I suspect I will write one reusable function to encapsulate all of that functionality.
Keep in mind some blocks, such as this one are static blocks — the HTML markup is created by Gutenberg and outputted as-is. Other blocks use server-side rendering, allowing you to create the HTML markup using PHP. Those types of block plugins will rely on more PHP. Also, so will plugins that require custom REST API endpoints.
Still, I wrote a complete WordPress plugin with basically no PHP besides setup for my JavaScript and CSS. The WordPress back-end is still a PHP application, but with Gutenberg, the division between front-end and backend is now more clearly divided by language, whereas before front-end development with WordPress was as much about PHP as JavaScript.
I think this is going to be a key step for us as an ecosystem to keep up with changes in the web. Most specifically the move to single page web apps, especially those implemented as a progressive web apps.
I Hope You’ve Been Separating Concerns
I’ve written a lot about the WordPress REST API and PHP design practices and principles. One thing I’ve stressed is how the WordPress REST API and also WP CLI changes WordPress development is that decoupling code from the HTTP request — front-end, admin screens, admin-ajax, etc. — is so important as modern WordPress sites, apps and plugins need to be able to provide the same features via CLI, REST request and different UIs.
That advice is even more important with an editor where the design is based around in place preview. Unless you want to maintain two totally different interfaces — preview and actual — for the same thing, your interfaces will need to be decoupled.
While I find creating new plugins based around the idea of a block a pretty smooth experience, When I created a block for Caldera Forms — my first full block, but also my first experience adding a block to a legacy code base — I had some issues. And of course, the problems arose where I didn’t have a perfect decoupling from the interface I was reusing
As an example of where it was easy, take a look at how the server-side rendering of the form for the front-end works:
<?php
function caldera_forms_render_cform_block($atts ) {
if( ! empty( $atts[ 'formId' ] ) ){
return Caldera_Forms::render_form(
array(
'ID' => caldera_forms_very_safe_string( $atts[ 'formId' ] )
)
);
}
}
I already had that simple function for rendering the form. Adding the server-side rendering of the block was easy and didn’t interfere with my shortcode, which has its own intermediary to call the same render function.
On the other hand, getting a live preview of the form in the block, was a little more work. Getting the HTML in place is easy, but the plugin assumes CSS and JavaScript are loaded in the header and footer. That happens when the theme calls the wp_head and wp_footer actions. That’s not happening here, so I had to write a mini-JavaScript client to append those extra resources to the DOM. It’s more work, but now I have it, which is good.
You Don’t Need To Learn React
While Gutenberg does use React for a lot of heavy lifting, it’s important to note that if you’re developing blocks, you don’t need to use React. There are some new WordPress APIs that are currently built on top of React APIs.
For example, wp.element.createElement is an abstraction over React.component. But it’s important to think of this API as a WordPress API as React might not always be used under the hood, but since this is WordPress we can assume that the public interface of the API will not change.
In addition, you can write blocks using other frameworks. Here is an example block I created using VueJS. You don’t even need to use a framework or ESNext at all. Here is a plain JavaScript block I created.
You Might Not Even Need To Know JavaScript
I’m a plugin developer, not a theme developer. But, I’m super excited for what themes are going to become. Now that WordPress core is providing more default interfaces as blocks, theme developers can really focus on designing unique presentations and collections of those blocks.
If you’re a designer, skilled with CSS or both, theming is going to get really fun and all you’re going to really need is a good design and good CSS skills. I suspect that over the next few years WordPress themes will improve in quality a lot as theme developers are able to focus on design and spend less time on functionality.
Ok, But React Is Awesome
Yes, you don’t need to learn React or even ESNext. That said, I hope you’ve been learning your JavaScript deeply as instructed. If you have been then I think you’re really going to enjoy WordPress development for Gutenberg.
I’m still a big VueJS fan, but I used Gutenberg as my excuse to advance my understanding of React and I’m glad I did. When building simple blocks, I think using ES5 is fine, but one of the big advantages of React or Vue is the modularity of components.At that point, it’s important to break them out into separate files. In the Social Block plugin I built, I have one React component that is used to show the preview and render the front-end. If that was all in the block itself, then I’d have to create second component and keep the two in sync manually.
Dropping a React component into Gutenberg is very simple at this point. If you’ve been developing with React already, this is going to be an easy transition for you.
Some Of The Most Important Stuff Isn’t Ready Yet
I’m writing this a few months from release. I’m able to create some really powerful blocks. Some things are planned but just not there yet. Already, it’s a lot of fun to develop for Gutenberg, which isn’t something I’ve said in awhile about WordPress development. But, even without all the developer-facing features done, this is already a massive improvement in developer experience.
For example, plugin developers do not yet have a good way to access Gutenberg’s state object. This enhancement is planned and will open up some really incredible possibilities. For example, when we have a simple way to get the current post content or title or taxonomy terms and react to their changes in real-time we’ll be able to create more interactive and dynamic blocks or help improve the content based on real-time analysis.
I’m Excited
I’ve been really worried about WordPress. The REST API and WP CLI are major steps forward in terms of developer-experience, but a lot more modernization needs to be done. Moving to the post editor makes a lot of sense for advancing this modernization. Gutenberg is an opportunity to move the developer and end-user experience forward at the same time.
Gutenberg is starting in the post editor, but it’s being written in a way that this interface can take over more of WordPress. This is a vision Morten explained really well in his WordCamp US talk and the companion blog post.
What I love about where we’re going is we’re not just addressing ease of use versus competitors like Squarespace and Medium. What we’re doing is making it easier and more fun to make WordPress plugins that follow a common design pattern. This way, we can do what WordPress and the WordPress ecosystem do well — provide tons of different tools for DIYers, pros and even enterprise sites to use to create millions of unique WordPress sites. Just better.
3 Comments