One of Pippin Williamson’s repeated concerns during his review of page builders was over data loss. He praised the plugins that, when deactivated, maintained HTML markup and content in the_content() so the site owner could still use their content without the plugin. I’ve been thinking about this a good bit since.
“Data loss” and content
There is no real excuse for total data loss. Historically I’ve always thought spitting out rendered content from a page builder is better than nothing. But I’ve been thinking perhaps there’s a better way.
Most of the time, page builders are blocks of content of various types: a list of posts, a two column block of text, a text and image, a call to action, a form — and so on. It’s pretty rare that I’d call that data the content. It’s a part of the page, but not always what I’d define as primary content.
And that’s the rub with WordPress and the_content(). It’s a restrictive concept. Within the_content(), you are confined to the kind of stuff that makes sense there. That’s how shortcodes became what they are today in the first place: a way to execute arbitrary code within that confined space.
Modern web pages are not header, footer, sidebar, content. But if you look at WordPress, it’s still the default. We make little room for enabling more than that outside of custom development or highly specialized plugins (like eCommerce). For general “pages” or standard content, we don’t have a lot of flexibility.
Of course, that’s where page builders come in, and the gold rush, as Pippin called it, is obvious. Rich layouts are in demand. Rich layouts are in supply. Because there is no standard for how to do things, lawlessness is the law.
Page builders that are try to be good citizens of the web are doing what they can to preserve content when their plugins aren’t activated. While spitting out markup into the_content() is better than total data loss, or a shortcode laden content area, it’s still not good, and leaves a ton of work if a website owner wants a clean site. At best, it’s a stopgap before a refactor.
What I think I’d like to see is a standard for content blocks and how to store that data.
A case for content blocks
I’m still a proponent of the content blocks concept. I don’t care (as much) whether content blocks are an admin-side interface, a customizer interface, or a front-end interface. I want content blocks to be a storage standard.
When I think of page builders today, it reminds me of custom fields before custom meta box frameworks came into existence.
The “custom fields” metabox still exists in WordPress core, but it’s far too arbitrary for serious use. Early on, some people would hack their themes to support custom fields by appending what they put into those fields as output after the content — just loop right through them and spit it out. The custom fields page on the Codex still shows them as cute little bits of data like that.
It’s called meta data because it was originally add-on data, not the meat of the page. Today, we utilize meta data in all sorts of important ways. Can you imagine if you looped through all meta fields on a post today and output it on the front end? Of course not. I can’t even guess what would be there. Tens of thousands of plugins and themes make use of meta data and use it in all kinds of ways that we cannot assume.
We now have best practices for creating, manipulating, and using meta data. There’s still not really a standard, as people do all sorts of crazy things with meta data, but there are best practices and frameworks for responsibly creating and managing meta data that are consistent. We’d still benefit greatly with a fields API to further standardize, but that’s for another conversation.
Meta data isn’t the wild west. But as web pages have become more complicated and the user’s desire to be able to, “make changes without a developer” (as Chris Lema put it) have increased, the standard content area is becoming more and more of the wild west.
Page builder plugins are squeezing modules and layout into a field that wasn’t designed to be more than a rich text area. Shortcodes have just enabled that spirit of tossing anything and everything into the_content().
Meta data can be structured, whereas the content area is purposefully unstructured. Page builders take advantage of that lack of structure to insert their own structure inside that space. That gets really complicated, really fast, especially when you consider other plugins want to treat the_content() like a simple rich text area.
Putting structure into the content
What if we did put structure into the_content()?
One thing we can be fairly sure of is that a web page will continue to be some flow of modular sections of data.
In my perfect world, we would be able to split the main content of a page into multiple structure components, where each component could have a specific structure. Then, the sum of those components would become the main content when rendered.
This sounds a lot like how a sidebar works (aside from storage itself). A sidebar is a specific content area. Widgets are modular components within. They can be re-ordered, highly structured, customized, and extended beyond default widgets.
There’s even an effort to store widgets as custom post types. In my world, a post utilizing a “page builder” concept would look a lot like a sidebar.
If there are bits traditional rich text content in there, that’s fine. If there are more structured components — testimonials, columns of content, or whatever else — that’s fine. In the end, it is all structured and saved to the parent post ID, and the content itself is relatively pure and structured.
The content of the page would be like a sidebar. The sections within the content would be like widgets. We could create standards around how to register components, manage manage markup, scripts, and other things that are pretty tough right now in the content.
That’s how I envision content blocks. And core support for the concept would help create a standard for page builder plugins to be built in a way that makes sense and where page builders and other plugins can respect one another, versus everyone fighting over the_content() constantly.
I don’t know the best way to store everything and manage everything. But I think that way of thinking about content is better than what we do right now.
There’s a ticket that’s similar to what I’m talking about on Core Trac right now, which is “blessed” for 4.7, where these concepts are being debated. The Twenty Seventeen theme has a “multi-panel” feature for the home page, and it’s being discussed how to handle it.
Weston Ruter proposed a child/parent post solution not too dissimilar from what I describe above. What comes from that ticket will definitely be illuminating for the future — both for content blocks (which they are trying to stay away from going all in on) and especially in regard to potential user flows for creating multi-panel content.
