Cancel

Justin Tadlock

A World Where (Some) Block Development Is Merely a Templating System With No Build Process?

What if WordPress developers lived in a world where we could create PHP-based templates that would output data on the front end and handle editable fields via the block editor? Or, we had a system where we could create blocks without a build step?

While there are many reasons the modern WordPress editor is not the best fit for everyone just yet, one stumbling block has been building custom interface components. The ecosystem has a deep history of creating bespoke solutions for clients using PHP. These have been custom meta boxes and form fields in the classic editor screen for the most part. When WordPress 5.0 launched with its block editor, it turned the world upside down, often leaving agencies and freelancers with no way to move forward without dedicating massive resources to learning React to build blocks or interact with the new editing screen.

The solution? Stick with what you know. It was cheaper and already seemed to do the job well.

As we talk about the support window for the Classic Editor plugin, the WordPress project needs people to provide tools for this segment of the ecosystem if it ever plans on bringing them along for the ride. Solutions such as ACF Pro and Genesis Custom Blocks have bridged some of the technical gaps. However, the user experience can be sub-par when using server-side rendering in the block editor. That method works well for some types of blocks but not all. We need to take this one step more.

Mark Jaquith, a lead WordPress developer, shared a few questions from Helen Hou-Sandí, another lead developer, around this idea and a basic concept about what this might look like:

Hou-Sandí followed this with a detailed post on the concept, but she pointed out that this is merely an exploratory phase.

“The React-based WordPress block editor (sometimes referred to as Gutenberg) is a powerful tool for WYSIWYG editing that continues to prove to be somewhere between a speed bump and a roadblock for long-time WordPress developers who historically have been more PHP-centric,” she wrote in the post.

If you are a WordPress developer, there is a not-so-small chance that you are thinking, Yep, I have hit a few of those speed bumps and crashed into that roadblock a few times. This is unlikely news to you. What might start winning hearts and minds is acknowledging and understanding where much of the problem lies for custom development.

“By leveraging the familiar parts of PHP-based templating and creating a bridge that demonstrates the power of React when combined with the markup and styling already being done for the front-end, we can de-duplicate code, help demystify the critical role of JavaScript in modernizing WordPress, and serve as an on-ramp for PHP-centric developers to create compelling and delightful 1:1 live preview editing experiences,” wrote Hou-Sandí.

This all boils down to the process of, essentially, writing some template code that works on both the front-end and editor without all the complexities of currently setting up and building blocks. That is an exciting prospect, evidenced by the numerous likes, retweets, and replies to Jaquith’s tweet.

Hou-Sandí pointed out that the current thought process is primarily about easing the transition for custom client block solutions and not necessarily for WordPress itself. However, that does not mean that this or a similar solution might not be a part of the core platform’s future.

Gutenberg project lead Matías Ventura replied to Ben Gillbanks in the same Twitter thread that it was definitely something they were considering. “From a core perspective we had to ensure the primitives and interactivity is not compromised, but there’s no reason why that should imply a full JS toolchain for simpler blocks. Lowering barrier of entry is important.”

Like several others, Gillbanks thought that such a system would have made an easier transition for PHP-centric developers from the start. However, the project was not ready for that at the time, according to Ventura.

“It’s tricky to do something like this from the start until the compile target APIs are robust enough,” he tweeted. “We are getting to a point where many of the interactive properties are clustered into primitives and components, which makes a templating approach more appealing.”

Automattic developer Riad Benguella shared a similar solution in the past week, launching the Blocky project on GitHub. With his approach, developers utilize the block.json file to create the template or view component and run it through a simple build step to generate the block’s code.

While it is not too early to hope and dream, it may just be a bit premature to begin seriously considering whether such tools will land in core WordPress. However, seeing some of the lead WordPress and Gutenberg developers at least openly talking about solutions is something worth paying attention to.

Category: ,
9

9 responses to “A World Where (Some) Block Development Is Merely a Templating System With No Build Process?”

  3. If the classic TinyMCE interface is taken away what happens to WooCommerce and the product editing screen?

    While the technical conversation above may be interesting to some, for many usability is more important. The block editor is a great progression but for some use cases it doesn’t offer a great solution.

    The article touches on ACF and you could add Toolset as well. Apart from the tools that these bring to someone designing a site, at the far end of a project, when it is handed over to the end user, some things are missing.

    In the older interface you could set things up with just the required custom fields for a custom post type. The user only needs to concentrate on the key data that needed to be entered. Now the same user needs to think and work through the block editor on each post. Where the key information for a CPT is fronted by a uniform template, the block editor only adds cognitive load and is inefficient. From a time and motion point of view the older meta box with custom fields setup is more efficient.

    It is in catering for these scenarios, even if they seem like edge cases, that I see more value than full theme editing. I am sure that it is not beyond the bounds of the Gutenberg team’s capability to address this, with options to set up a UI that removes the standard bloc editing tools and leaves a simple arrangeable meta box system. In any event Automattic will ultimately have to find a solution for WooCommerce products once the classic editor is pulled.

    Create forum topic from comment

    • Similar but not exactly the same. ACF Pro utilizes server-side rendering (at least the last I checked). That means refreshing from PHP each time an option is changed instead of reacting to changes live. SSR can be reasonably fast and works well for a lot of situations, but it is can also be a clunky experience.

      Create forum topic from comment

  7. As a custom themer and php dev, I threw myself into learning block creation a couple years ago, surmounted the biggest learning hurdles… and then decided that creating blocks for clients was a bad idea.

    First, the editor code was changing too fast. With much effort I’d created a new subhead block that would appear below the title in the editor but save data to post meta. It took me countless hours to figure out that my block wasn’t working because post types have to support custom fields or the editor won’t save to meta. Then as soon as I finished it, the source = meta feature was already deprecated. My clients don’t want to pay an arm and a leg for maintenance, and I don’t want to build something that will break in a year. The php I write is really stable.

    Second, the block editor hasn’t had anything akin to php templating, where the layout is consistent (and updatable!) but the content is filled out on a per post basis. Blocks are deliberately designed so you can’t update the html and have it apply everywhere. Reusable blocks have the same content. Maybe block templating is at least approaching this? But templates aren’t designed for post content as far as I know.

    Last, particularly with the poor documentation, the learning curve is high enough that I’d have to be making blocks somewhat regularly to really get comfortable with it. If I was a full time dev and not also a designer etc that might be viable, but as is, it simply isn’t. My clients don’t need custom blocks often enough.

    I haven’t used ACF blocks yet because it doesn’t offer the editor’s visual interface (though I agree with Stephen that sometimes form fields are better). Instead I’ve been sticking with styles, patterns, variations, and php for now, and hoping the whole dev situation will improve. This proposed solution certainly looks like a smooth on ramp and I’ve love to try it, but it won’t fix everything because the issue isn’t just that initial learning hurdle or that php devs aren’t interested in trying new things.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.