Why WordPress Page Builders are here to stay
And what we can learn from them
I’m just going to come out and say it: I hate most of the current page builders.
I know hate’s a strong word, and “dislike” is probably a nicer way to put it — but I’m sitting closer to hate than dislike on the love-hate scale..
Perhaps I just haven’t found the right one yet? Who knows.
I love the concept though — giving layout editing power to users/developers is a great idea. But every time I come across these Page Builders on a client site, it makes my job a lot harder.
It doesn’t have to be this way.
Search through any WordPress community site and you’re bound to find arguments centered around the use of Page Builders.
Fans will argue that they make their lives easier, get more done quickly, allow them to build any kind of layout and won’t build a site without one.
Others will argue that they are misusing shortcodes, promote vendor lock-in, give the average business owner too much control and make their content unreadable outside of their site/theme.
I really want to see Page Builders succeed — I think they’re the next step in the evolution of WordPress.
But to gain developer support, they need to fundamentally change before that can happen.
Why we need Page Builders
WordPress might be the leader in the CMS world at the moment — having almost 60% market share and powering over a quarter of the web.
But there’s growing competition in the form of website builders. While they don’t yet seem to be significantly impacting the growth of WordPress, more are popping up every day.
Even Matt Mullenweg has pointed out that these website builders are a threat.
Wix, Squarespace, Weebly and similar website builders offer an experience that WordPress cannot match, which is exactly why plugins such as Visual Composer and Divi Page Builder exist.
Some users want/need that level of customization and power. And I have no doubt that this has contributed to the growth of WordPress over the past few years.
So, it’s not a question about whether or not these Page Builders should be used. The WordPress community needs them.
The real question is how can we (the development community) support them?
How can we help them fit into the WordPress development process?
How can we get to a point where these Page Builders will be accepted (and used) by users and developers alike?
The ideal solution
In my opinion, the ideal page builder must meet the following requirements:
- Allow Complex Layouts
This one might seem obvious, but the ideal page builder must allow the user to customize their layout however they want.
- Minimize shortcodes/html
The (ab)use of shortcodes by page builders must be stopped. They were not designed to control layout — an alternative must be found.
The Post Content field should be used to store content only — not layout/structural markup.
- Minimize Vendor lock-in
While preventing vendor lock-in altogether is almost impossible, we can certainly try to minimize it. All content must be easily readable/usable other plugins and themes without requiring any proprietary parsing/rendering libraries.
- Maintainable within the text editor
Content should be readable when not in WYSIWYG mode, and easy to modify via the Text editor — even complex layouts.
- RSS/API friendly
The content must make sense when viewed via RSS or via the API. Currently, WordPress will render shortcodes (when viewed by RSS at least)— but often this results in a lot of DIV elements with no styling.
Content should use semantic tags where possible, and should be consumable/readable by clients who have no idea what plugins/themes the site may be using.
- Allow the use of templates
Allow plugin and theme developers to override styles/html via templates.
- Must feel native
The end result must feel like it belongs in WordPress.
- Developer friendly
As a developer, I’d love to use a page builder. Unfortunately, most of the time they get in the way. I’m sure that if a page builder found a way to cater to both sides of the community, it’s popularity would skyrocket.
But most importantly, we need to (as a community) decide on a standard approach for building pages.
Whether that’s using special markup or templates or something else — if there’s a global, standard way of doing something then it’ll make everyone’s lives a lot easier.
Midway through writing this post, I stumbled across this link — https://make.wordpress.org/core/2016/12/24/idea-uniform-resource-identifiers-as-an-alternative-to-shortcodes/
So I’m not the first one to come up with this idea — which is encouraging.
I definitely recommend reading through that post to clarify what I’m talking about below.
I’ve been thinking about these problems for many months now — in particular how to generate layouts without the use of shortcodes or HTML in post_content.
And I recently came up with (what I think is) a valid solution:
Use URLs to embed content block “partials”.
When you think about it, a URL is simply a pointer to a resource — it specifies the protocol and encapsulates everything needed to locate that resource.
In my opinion, this makes the most sense going forward. Now that the the REST API is in the wild, we need to start thinking about our data as resources rather than just HTML content.
Rather than sending an API client a complex mess of shortcodes/HTML that they can’t possibly know how to render, we should be sending them the information they need to decide what (and how) to fetch and render these resources themselves.
To explain things a little more, let’s break down a typical layout built by page builders.
If I had to pick a favorite, it would be Beaver Builder. I love the interface, and it keeps post_content clean. Once you use it, you’re not locked in — disable the plugin and your content still looks ok.
Take a look at Beaver Builder’s site below.
The Header Section, Testimonial Banner and 2-column Content Section
Alternating Feature Section
Call to Action Banner, Testimonials List Section
I’ve spent a lot of time thinking about Page Builders and ways they could fit more naturally within WordPress. While trying to come up with ideas, I asked myself the following questions:
Question 1: How should data be stored?
How content is stored is very important. I really wanted to find somewhere that it could fit naturally. Shortcodes in post_content wasn’t the right place. The Post Meta table also felt wrong.
Which section should be added as the main post_content? And which should be added as widgets/metadata? Then I realized something:
Do any of the sections in the page above stand out as the main/primary content section of the page?
No. Each of those sections is just as important as the next.
This page doesn’t showcase a single piece of content — it’s stitches together multiple distinct-but-related content sections.
We could move some of those sections to other pages or reorder them, and the overall page would still make sense.
This led me to the conclusion that these distinct sections should be treated as distinct pieces of content within WordPress. Stored in the database as separate records in the Posts table, but using a “section” or “partial” post type.
I like this idea — it feels natural. Hopefully others agree?
Anyway, now we can move onto the next question….
Question 2: How can we embed these sections into a page?
By now, everyone should know how URLs are embedded in WordPress. Just copy+paste a URL into a post and it’ll display a rich preview of that link.
WordPress is smart enough to detect these URLs and replace them on the fly.
So if it’s good enough for external links, why not use it for internal links as well?
Imagine if you could simply add “http://mysite.com/testimonials/chris-lema” to your post and it would automatically turn into the Testimonial Banner section shown above.
Or simply “http://mysite.com/testimonials” to display a 2 column testimonials list
Or “http://mysite.com/features/” to display a list of features
Add some UI that hides away the URL text and displays a TinyMCE widget in it’s place — similar to how the gallery/media widgets work — and it should be pretty user friendly.
The user editing the page wouldn’t know that these sections are stored as URLs in the background.
Or we could build a full-blown WYSIWYG Page Builder plugin that simply uses these URLs behind the scenes, using metadata and/or templates to control the styling and layout.
Question 3: What are the advantages over the more traditional Page Builders?
No shortcodes used. The content added to the database can be shortcode-free — simply URL pointers to other sections of content.
No vendor lock in. Since URLs are designed to encapsulate the details required to locate a resource, any plugin will be able to detect/read these URLs and instantly know how to render them.
RSS/API Clients. Similar to above, the content will make sense to any REST API clients as well. They can choose to fetch the content from the API and embed it (even in a different format), or they can simply render the content as links and allow their users to discover these “sections” via their browser.
See a list of links to 5 features in my API-based blog reader would make a lot more sense than a set of nested shortcodes that don’t mean anything.
Edited via text editor. (Advanced?) Users can simply use the Text editor to rearrange or modify URLs to change content, no need to worry about nested shortcodes or HTML.
Templates. Themes could provide built-in templates for common types of content. For example, one theme could render a set of testimonials as a list while another might render them as a slider/carousel.
Embeddable on other sites. This one is particularly interesting. Imagine you had a list of testimonials on your WordPress site and wanted to show them on another site (such as Medium.com).
This functionality would allow you to simply paste the testimonials section URL into Medium and have it automatically embedded.
Or paste the URL to your “Contact Form” section/partial.
Of course, we’d need to worry about securing these URLs — we don’t want to give public access to all sections by default. But it definitely could be useful in a number of situations.
Question 4: Will it be easy to design layouts?
There’s absolutely no reason why we can’t include a full-featured Page/Layout builder that’s built on top of the concepts discussed here.
Any Page Builder plugin would be able to adopt this approach without sacrificing any functionality.
In fact, you’ll also gain the ability to re-use content sections in multiple pages without any additional work.
Proof of concept
I’m working on a proof of concept at the moment. It’s not going to be a full-featured page builder, but it will definitely demonstrate how the concepts fit together.
If you’re interested seeing the proof of concept, sign up to the newsletter below — I plan to post it publicly (open source of course) within the next week.