A world where (some) development blocks are just a system of models without a building process? – WP Tavern

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 through the block editor? Or, we had a system where we could create blocks without a build step?

While there are many reasons why the modern WordPress editor is not yet the best fit for everyone, one stumbling block has been creating custom UI components. The ecosystem has a long history of creating tailor-made solutions for clients using PHP. Most of these are custom meta boxes and form fields in the classic editor screen. 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 devoting enormous resources to learning React to create blocks. or interact with the new edit screen.

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

While we are talking 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 to take them with it. Solutions like ACF Pro and Genesis Custom Blocks have filled some of the technical gaps. However, the user experience can be poor when using server-side rendering in the Block Editor. This method works well for some types of blocks, but not for all. We must go one step further.

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

Hou-Sandí followed up with a detailed article on the concept, but stressed that this was only an exploratory phase.

“The React-based WordPress block editor (sometimes called Gutenberg) is a powerful tool for WYSIWYG editing that continues to sit somewhere between a speed bump and a roadblock for longtime WordPress developers who have historically been over PHP-centric, ”she wrote in the post.

If you are a WordPress developer, chances are you are thinking, Yes, I hit a few of these speed bumps and crashed into this roadblock several times. This is unlikely news for you. What might start to win hearts and minds is to recognize and understand where much of the problem lies for personalized development.

“By taking advantage of the familiar parts of PHP-based models and creating a bridge that demonstrates the power of React when combined with the markup and styling already done for the front-end, we can deduplicate the code, help Demystify the critical role of JavaScript in modernizing WordPress and serve as a ramp for PHP-centric developers to create compelling and enjoyable 1: 1 live preview editing experiences, ”Hou-Sandí wrote.

It all basically comes down to the process of writing template code that works both on the front end and the editor without all of the complexities of current setup and building blocks. It’s an exciting prospect, as evidenced by the many likes, retweets, and replies to Jaquith’s tweet.

Hou-Sandí pointed out that the current thinking process is mostly about easing the transition for custom client blocking solutions and not necessarily for WordPress itself. However, that doesn’t mean that this or a similar solution might not be part of the future of the main platform.

Project manager Gutenberg Matías Ventura replied to Ben Gillbanks in the same Twitter thread that it was definitely something they were considering. “Centrally, we needed to make sure that primitives and interactivity weren’t compromised, but there’s no reason why this would involve a full JS toolchain for simpler blocks. It is important to lower the entry barrier.

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

“It’s hard to do something like this from the start until the build target APIs are robust enough,” he tweeted. “We’re getting to a point where a lot of interactive properties are grouped into primitives and components, which makes a modeling approach more appealing. “

Automattic developer Riad Benguella shared a similar solution last week, launching the Blocky project on GitHub. With his approach, developers use the block.json to create the model or view component and run it through a simple build step to generate the block code.

While it’s not too early to hope and dream, it might be a little premature to seriously start considering whether such tools will land in the heart of WordPress. However, seeing some of the top WordPress and Gutenberg developers at least openly talking about solutions deserves special attention.



Source link

Comments are closed.