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.
