Beaver Builder as a Development Platform - Part 2 - WP Developers

Beaver Builder as a Development Platform – Part 2

Part one of Beaver Builder as a Development Platform is here.

A Guide to Beaver Builder for Developers

I've got a number of incomplete draft blog posts to educate people on how to use Beaver Builder to do cool things (well, I think they are cool).

But it's become more and more evident over the last few months, after discussing with many developers, that the question isn't "how to...?", but rather "why?".

"You're not a real developer if you use a page builder".

The role of page builders in the WordPress ecosystem is fairly cemented for end users - those creating their own websites; and site 'builders' - those who create websites for their clients but don't write code.

Without tarring them all with the same brush, they generally want ALL THE THINGS. Lots and lots and lots of features. That is generally how a plugin is deemed 'good' or 'bad' by these user segments.

As developers, however, the questions we need to ask are different.

This article is for those who write code to build WordPress themes for their clients, and who have questions about whether a page builder can or indeed, should, fit into their workflow.

I feel that our attempts as developers to provide content publishing freedom to our clients has often had the opposite effect.

To better explain what I mean, I thought I'd explain my development journey so far, and why I've settled on Beaver Builder.

Perhaps you won't have shared the exact same path, but many of you ended up in a similar place in the latter stages.

Doug's WordPress Development Journey

Phase 1 - WordPress Widgets

"Oh, right. Widgetised... yeah". I said.

"Definitely maybe not a problem.".

Having only recently graduated from writing (bad) HTML and (worse) CSS sites to using WordPress, I had no idea what my client meant.

He knew he wanted his site 'widgetised', so he could have 'full control' over his content.

what does widgetised mean

step by step beginners tutorial on making a wordpress website widgetised

widgetised code generator

These were the types of searches Google received that day. I hope I don't receive any search engine traffic to this article for these phrases in 2017...

I remember adding swathes of copied code into functions.php to create widget areas. I also remember a client having over 40 of them.

I'd then add them into files I'd 'found' in the theme directory, with little understanding of what I was doing. Wash, rinse and repeat until the errors went away.

Not to mention the 'Enhanced Text Widget' which allowed us to write CSS, JavaScript and even PHP inside a widget.

My client could now edit nearly any part of their site, technically speaking.

They just needed a decent grasp of the Appearance > Widgets area, and a lot of patience.

In fact, on a couple of occasions, I felt that the post edit screen was totally unnecessary, and bypassed it altogether.

Content Management FTW.

Phase 2 - Page Templates & the Template Hierarchy

Of course, before deciding to inflict my development 'skills' on the world, I was a user of WordPress. I ran a couple of WordPress sites, and had used themes from various sources to style them.

And while I hadn't really noticed them before, they used 'templates'.

To me, this was some next level stuff; they must've done some serious hacking to make that possible... in my eyes it was a theme 'thing', rather than a WordPress 'thing'.

But I stumbled across an article that showed me how simple it was to create my own templates, and my head nearly exploded!

And I felt pretty damn 31337 when I started to understand the template hierarchy.

So my 'Phase 2' clients had fewer widget areas, but lots and lots of templates, with lots and lots of hard-coded stuff.

It wouldn't be uncommon to see my themes littered with files such as:

template-image-top-right-with-text-left-and-big-text-area-below.php

template-big-text-area-with-three-widgets-below.php

page-133.php

page-about-us.php

And they could update images and things within these templates - just as long as they used the same filename as the old one.

I hope my clients from those formative years of my career now have new websites.

Phase 3 - Custom Post Types

A very useful feature, and a staple of any WordPress developer's toolkit, even now.

A tool for sensible developers to logically group, query and display content.

That is, until I got my hands on them.

Within hours of learning about them, everything was a Custom Post Type.

Some of my favourites that I recall:

  • Homepage Feature Blocks - using the text editor and Featured Image. I would then query and display these within the hard-coded home page. The only issue was that if I had more blocks than space on the page, the layout would break.
  • Company Addresses - I would query and display these on my hard-coded Contact Page template. And no, not one of my clients had more than one address.
  • Company Phone Numbers - As above. Incredible, really.

So it seemed that if there was any chance of a client having more of one 'thing', it was getting CPT'd.

Not only that, each CPT I created only ever used a title, content editor and featured image.

Phase 4 - Advanced Custom Fields

I remember the conversation vividly.

"So let me get this straight. You want a different colour scheme for each category of your posts?", I asked, quizzically.

"Yeah, I've seen lots of sites that do this".

I had no idea how to do this. Why would you want crazy stuff like this anyway?!

I knew, however, that if other sites and themes were doing this, my excuse range was limited.

I had almost resigned myself to hard-coding styles in CSS, and matching it with carefully named files that used the template hierarchy. I even considered free updates to the stylesheet as more categories were added.

There must be a better way...

Other than levelling-up my dev skills (moderately), one other skill had also improved: Googling.

And I'm only being partially sarcastic.

When you can ask better questions, whether of a person or a search engine, you often get better answers.

I remember stumbling across Advanced Custom Fields previously, but as it used the word 'Advanced' in it's name, I dodged it.

But this time, during my expert-level Googling, I had seen it referenced in a short example on a forum.

It stored 'stuff', in this thing called 'meta', which you could then output on your page - in addition to the title, content editor and featured image!

Wow. This is serious business!

The possibilities were ENDLESS.

"We can have a custom colour scheme on each category, no problem!" I said, enthusiastically when following up with my client.

"How many colours do you want? In fact, we could have a colour scheme on each category, and then we can overwrite this on each individual post!!"

And so, my obsession with custom meta, and more specifically, ACF, began. There were now fields for everything.

  • Different featured images for items on archive pages and single posts/pages
  • Ability to overwrite titles for items on archive pages and single posts/pages
  • Blocks of content that would appear in various places in my many page templates
  • Obscure check boxes that did (horribly inefficient) 'stuff', like featuring items of content on the home page
  • And of course, LOTS of colour options.

Phase 5 - Advanced Custom Fields Flexible Layouts

After getting comfortable with regular fields within ACF, I began to explore further.

I remember being on my knees, with my nose almost pressed up against my screen as I watched a demo of ACF Flexible Layouts.

"No way. That is not happening... This guy is dragging and dropping stuff into a WordPress page. He's moving it UP AND DOWN the screen!"

I couldn't understand my girlfriend's lack of excitement.

$25 later, I was the proud owner of the Flexible Layouts plugin (nowadays, bundled into ACF version 5, rather than a separate add-on).

For those of you who have never used Flex Layouts before, you can create blocks of content that you can then add, remove and vertically reposition on a page/post.

(It sounds pretty vanilla, nowadays. How expectations change...)

Each block has its own set of fields, such as a text field or an image, and you can add as many as you like on to a page. And did I mention you can DRAG AND DROP THEM?!!

But to cut a long story short, this happened:

Here we have a page that uses Flexible Layouts. There are 5 layout blocks on the page (this particular client/page got off lightly - there are as many as 20 sometimes), and each block is different.

Doesn't look so bad, right?

Let's edit one.

But before I show you this, you must know that on my 24" screen, I've zoomed out to 35% to fit this into the screen. This makes my effective screen resolution 5760 x 3300.

We are editing the 'Content' tab of the block called 'Department Feature Row'.

  1. We have a section heading, and introduction text field
  2. We then have a repeating field - each field is a single department, which equates to a column on the front end
  3. In each department column, we have a column title, icon, intro text and image
  4. In the 2nd department column, we are editing the buttons which are in another tab. There are 2 of these, and are a repeating field.

Can you blame clients for insisting I make the changes, despite me crafting this interface for them?

But, it's DRAG AND DROP!

And while this is incredibly convoluted for a client, it also has shortcomings from a developer's  perspective.

Where possible, I'd opt for adding CSS classes to elements, which I would then style in SCSS. This would give the client the option of choosing a preset style from a select field, rather than individual style properties.

And while this helped with keeping options to a minimum, you can't stay away from writing inline styles at some point, or dare I say it, <style> blocks.

This was usually the case with something like a 'hero' block, or a slider, which are sensitive to screen size changes. Perhaps it'd make sense to have a much smaller font size on tablet and mobile. Maybe it's necessary to change the margin of an element on tablet, but not mobile or desktop.

These scenarios are always 'solvable', sure, but often with workarounds that are layered on top of one another.

Not only that but managing a variable number of columns within a row was fiddly.

For me, this was too exhausting, and you often had to reinvent the wheel for each project.

Is the post edit screen dead?

As you can see by my history, I've likely let my obsession with a new toy go too far. That said, I have inherited many sites who also use ACF flex layouts, with even more complex interfaces. Not to mention themes and plugins that stuff more buttons into the edit screen.

Shortcodes, TinyMCE buttons, template selectors.

Not only are we trying to provide an interface for content publishing, we're also trying to design the page. As soon as you need to give a client some layout flexibility, it's a tough balance to find.

These solutions have obvious shortcomings:

  • You spend a significant amount of time on designing the UI to make it as friendly as possible for users to edit
  • It leads to a 'hit publish and hope' guessing game for users. When you, as a developer, can see both the code and the interface, this stuff seems simple. As a less tech-savvy user, using brain-twisting interfaces for simple tasks isn't nice.

And let me be clear: ACF is an incredible plugin, and for structured data (and tons of other things), it, and similar plugins/custom meta, are fantastic tools. However, I feel that Flex Layouts has had it's time.

We're now in the age of the page builder.

But Page Builders Have Been Available for Aaaages

OK, OK.

We're now in the age of 2nd-generation page builders. It doesn't quite have the same dramatic ring to it, but whatever.

Dragging and dropping layouts together has, for a while, been seen as the holy grail of layout building.

Developers have tried many different ways to build plugins that do just that.

Site Origin, Visual Composer, Toolset and many others. They're all examples of page builders, which have been very popular in the WP space for a while and that do drag and drop.

Some have achieved commercial success and widespread usage by being bundled into popular themes. Others have offered their page builder as a complimentary product, to an existing customer base.

But what do I mean by 1st-generation and 2nd-generation?

I'd recommend checking out Pippin Williamson's not-so-recent-as-time-seems-to-be-passing-at-warp-speed-and-i-could-have-sworn-it-was-this-year-but-was-actually-last article on page builders where he reviews 13 different WordPress page builders.

Each product he mentions has different characteristics and features. But they have one similarity: they are trying to allow a user to build rich layouts without writing code. And they probably all achieve that, to some degree.

1st-generation page builders would have you create the layout in one section of WordPress admin, whether in the post edit screen or somewhere else, rather on the front end.

So in effect, you still have "back and forth publishing". You don't have full confidence in the change you've made and need to check the result on the front end.

2nd-generation builders have moved editing to the front end. WYSIWYAG (What You See is What You Actually Get).

And even this shift has been evident by the commitment to the Customizer project. Project Gutenburg shows significant movements towards front-end editing too.

There is also the big question of plugin 'lock in' - page builders that make a mess of your content if you stop using it. It seems that 2nd-generation builder developers consider this first, rather than last, and that's great news for everyone.

But why do I make this distinction between the 2 generations?

Because of the reputation that 2nd-gen page builders have as a result of 1st-gen shortcomings.

There was little consideration for how data was stored. Nor was there consideration for the look and feel of the interface.

In fact, as you'll see in Pippin's article, some favoured brash, heavily branded interfaces, over a WP 'native' style. It felt like you were working with a 3rd-party application, bolted on to the side of WordPress.

As long as it was 'drag and drop', with no coding, it was deemed fit for purpose. Being a ground-breaking feature in the WordPress world, these design choices were forgiven, but now times have changed.

But actually, the biggest factor for me was the consideration for developers.

Before Beaver Builder, I struggled to find any page builder that really encouraged developers to get involved. You kinda got what you were given. This is something I highlighted on a recent WP Builds podcast. If you look after your developer community and encourage innovation, you'll see organic growth. Look at Gravity Forms, ACF, Easy Digital Downloads et al.

So what are the 2nd-generation page builders?

As you'll likely see from the rest of the blog, I'm a big Beaver Builder fan. But there are others that I could've easily fallen for had they come around at the right time.

Elementor and Tailor seem to be the two other plugins that match my ideals for 'modern' page builders - at least from a technical standpoint. There are also others in Pippin's article (and beyond!) that fit into this category too, but these 2 have popped up on my radar the most.

It should also be noted, that some 1st-gen page builders have started to make the switch from back-end to front-end editing, such as Visual Composer.

I'd encourage you to do your own research and testing, but I'll highlight some points in this article about Beaver Builder. I'm not doing this to promote Beaver Builder over others, but I have more experience working with it than the rest. In fact, I'll go as far as saying, I have no experience with other 2nd-gen page builders other than Beaver Builder.

Queries and concerns that I had while searching for a solution (and that others have since raised with me) will likely be relevant to your research and might help you form questions, regardless of the direction you finally take.

And while those of you who have debated this topic with me might think that I'm a Beaver Builder evangelist (and I am, to a degree), the debates have never been about 2nd-gen page builder VS 2nd-gen page builder.

If you ask me about Elementor VS Beaver Builder, you'd get off lightly with an "I don't know" kinda response. As much as I love Beaver Builder, I don't know Elementor in-depth enough to say which is 'better'.

Besides, it's a personal thing. Elementor might suit you better because you know Backbone/Marionette well, which it uses, whereas I don't.

Instead, we're discussing the reasons why a page builder is better than ACF Flex Layouts (or other solutions). Or why 2nd-gen page builders are much different to 1st-gen - and how the questions to ask of them are now different. But other than a quick installation and scan of their source code, I don't have much point of reference other than Beaver Builder.

I've decided to layout these points in an FAQ style. Partly as these literally are frequently asked questions about Beaver Builder, that I receive. It makes sense really...

Basing my entire site/client's site on a 3rd-party plugin seems risky...

On one hand, this is a perfectly reasonable concern to have. On the other, you do this anyway with WooCommerce, ACF or something else.

I use a loose set of criteria (and gut feeling) to ascertain whether a plugin is safe to use, over and above from it's technical capabilities:

  • The plugin authors must embrace open-source.
  • If complex, I generally prefer a team of people rather than a single author.
  • Plugin updates must be frequent, relative to complexity.
  • Ideally, a premium version of the plugin exists. This indicates the plugin isn't only a sideline that could fall out of favour. It also indicates financial security. I'll always choose to pay for this by default if it means a higher level of support.
  • WordPress.org star rating of 4 or more (and even then I'll check to see what the quality of ratings are like).
  • Fairly mature, with plenty of installations.
  • I like transparent companies. Full disclosure of any screw ups. Even income reports.
  • A developer community around it.

Of course, small plugins with only a single file that serve a very limited purpose are exempt, as I can easily read the code and see for myself.

Specific to Beaver Builder, another real positive is that they have formed a relationship with GoDaddy. The free version of the plugin will be bundled into GoDaddy's managed hosting platform. This in itself gave them 10k of new installations almost overnight (probably more now). Although GoDaddy once had a bad reputation in the WordPress world, they've made bold moves to turn this around. Seeing a large organisation put their trust into Beaver Builder is a big positive for me.

How is layout data stored?

Some people mentioned that their perception and concern with data storage was that it was all in a huge serialised object.

In Beaver Builder, layout data is stored in meta for a specific page.

Inside a layout, you might have custom CSS/JS, as well as rows, columns and modules. A module is an element, such as a button, call to action, image or perhaps an entire photo gallery.

When you publish a layout, the contents of it are enumerated, and settings stored.

The render process of Beaver Builder will calculate the relevant CSS and JS from everything that exists on that one page, cache it in your uploads directory, and then enqueue a unique CSS/JS file for each layout.

The benefit of this is that there's little bloat - you're not storing all of your layout styles in one huge CSS or JS file that's shared across multiple pages.

Asset dependencies, such as jquery plugins, use methods from the base module class (add_js() and add_css()) which are a wrapper for regular wp_enqueue functions.

This means assets get enqueued as normal, and make use of the same benefits of doing so, but customisations to the page/modules are bundled into the unique CSS/JS files.

You mentioned the hassle of inline styles, and handling different screen sizes. How does Beaver Builder tackle these issues?

You can define breakpoints, in pixels, in the site's Global Settings.

These widths are then query-able by property name elsewhere through either using the $global_settings object (when you're working with a module), or simply by using the FLBuilderModel::get_global_settings() method.

What do I mean by 'working with a module'?

I won't go into the specifics of file and folder structures, class inheritance, built in methods etc. I plan on talking about these in more depth, individually over time (remember my many unfinished blog posts I mentioned at the start of this article...?).

But Beaver Builder introduces the concept of dynamic CSS and JavaScript. That is to say, PHP files that you write CSS or JavaScript in.

So for example, you can do something like:

[fuelled-code language="php"]

<?php if ( $settings->icon_size_medium ) : ?>

@media (max-width: <?= $global_settings->medium_breakpoint; ?>px) {
.fl-node-<?= $id; ?> i {
font-size: <?= $settings->icon_size_medium; ?>px;
}
}

<?php endif; ?>

[/fuelled-code]

(Apologies for formatting... I haven't mustered up the energy to fix that)

You'll see that we've queried a $settings object, which is made up of fields that I've added to a settings form. Also, we query the $global_settings object to get the 'medium_breakpoint' property, to form a media query.

You'll see an $id variable used, which is also made available to us while working in dynamic CSS or JS fields. This is a unique identifier for the module we're currently working with, allowing us to safely target this element in CSS.

And when I say 'unique', it is unique to the whole site. If you were to add 2 of the same type of elements to the same page, each would have a unique $id. And not only do modules have a unique $id, but so do columns, rows and entire layouts.

So you can write your CSS or JS in a PHP file, with query-able settings values. When you publish the page, your styles and scripts are rendered and written to respective, single files in your uploads directory.

Before I finish up this point, I'll just touch back on the responsive styles. You'll have seen earlier that we have use dynamic CSS, with media queries at breakpoints queried from the $global_settings object. This in itself is great, but Beaver Builder (and I know Elementor does too) goes one step further. When using a 'unit' (number) field, you can set a 'responsive' flag to 'true' which will give you the ability, when editing settings, to cycle through the screen sizes and define values for each.

In reality, each 'cycle' is just exposing a new field - but it looks fairly snazzy, and changes the viewport to preview the site at that breakpoint.

What about my development workflow, while working with Beaver Builder?

My rule of thumb here is to write 'structural' CSS in my theme or custom module's SCSS file, but anything that the client can overwrite, such as colours or font sizes, I'll define in dynamic CSS. This means you're not writing large chunks of CSS/JS in a PHP file, and can maintain your use of tooling, like preprocessors and linters for the bulk of it.

You might also find yourself wanting to keep custom SCSS inside your module for portability across projects. A limitation here is that you will sacrifice global variables, such as brand colours, that you have in your theme's SCSS.

And if you want to, you can include your custom CSS (and JS, of course) in the rendered CSS/JS generated by Beaver Builder.

What on earth do I mean by that?

I have a module. Within the directory, I have /src and /dist subdirectories.

The src directory contains my uncompiled, non-dynamic styles and scripts (the 'structural' stuff, as I mentioned before - the styles you won't let your users modify).

I use Gulp to compile them. Stuff in /src gets written to /dist.

Using file_get_contents() and my friends, the fl_builder_render_css and fl_builder_render_js filters, I can merge everything together, rather than enqueuing my dist assets separately.

Why would you do this?

Sure, enqueueing might suffice, I'm sure. But for small style or script snippets that are conditionally added according to a setting (field value) on an individual module, this is preferable to me. You get access to $nodes, which allows you to easily check for this value, without querying another way.

Honestly, it's 6 of 1 and half-dozen of the other, but this felt cleaner (and a little bit cooler).

Overall, it's perfect balance, in my opinion, and no more inline CSS!

How do input fields work?

Out of the box, Beaver Builder includes a number of different fields that you can incorporate in your custom modules.

You can see the native fields that are available here.

The basic principle is that you add fields to settings forms - whether on a module, a column, a row or an entire layout. Each form produces an object, and each field that you add becomes a property of that object. So it's really easy to add fields, and later query them.

Here's how you add fields to a form in code:

If you can create a PHP array, you can create settings forms.

Here's how it looks for the user:

And this isn't just for custom modules that you write. You have the ability to modify any settings form that you see, including global and layout settings, through the use of filters.

If you've added an additional field to an existing/native module, you can then retrieve that value with another filter that is used when a module is rendered.

Note, however, that you can't (yet) filter the whole output (ie the markup) of a module, but you can add CSS classes or data attributes. If you're writing only custom modules, then this isn't an issue for you.

In addition to the fields available out of the box, you also have the ability to add your own custom fields. You add these to your settings forms in exactly the same way. Find out how to create fields in the Beaver Builder documentation.

Some example fields that I've created can be found in WPD BB Additions; specifically, a geolocation field, using Google Places:

and an input range slider:

The point being, it's very easy to extend as you need.

One limitation I've found, particularly coming from ACF is the lack of repeating groups of fields (repeating single fields exists).

The latest version of Beaver Builder (in alpha at the time of writing) does introduce the concept of meta connectors, with a specific ACF connector too.

Currently calling repeating ACF fields isn't possible, but we'll see what the future brings.

(Although on my final edit of this post, while procrastinating and browsing Facebook, I saw this article which shows a workaround... I'm not sure I'd be comfortable with this myself, but it shows that it's an issue on people's minds.)

I like clean interfaces - won't the default Beaver Builder modules overwhelm and confuse my clients?

I, personally, use Beaver Builder as an empty 'shell'.

With a filter, I disable every Beaver Builder module, apart fromTinyMCE editor and Image.

The 30 modules that are bundles in, becomes just 2.

It's not because their code is bad, but I am just a bit of a control-freak.

I then have full control over markup, styles and scripts - instead of overwriting other people's work, adding my modules, for each project as I deem necessary.

As an aside: I mentioned earlier that you can't filter the markup of a native module. You do have the option of completely overwriting the markup by creating your own file. I always opt to write from scratch.

This way you get to write your own markup, CSS and JavaScript yet leverage an intuitive UI that your users can actually use.

I've even used VueJS to build an ROI calculator which I wrapped up into a Beaver Builder module. It was super quick and simple to do, almost to the point of being trivial, but highlights how much freedom you have.

My clients cause havoc when they edit their site - can I lock stuff down?

Yes.

It's possible to do now with some trickery, but it's barely worth mentioning as the next minor release of Beaver Builder has reworked user roles and permissions very nicely.

As a developer (and full admin), you can put your client's site together. You can then restrict your client to only editing content, such as text and images.

As usual, it seems to be very hookable, so you will likely be able to create more granular rulesets.

What about support?

I can't speak about other 2nd-gen page builder support functions, but I have a few stories about some 1st-gen.

I'm not going to name names, but bad support has been the reason I've dropped products in the past, rather than the product itself.

Numerous times I was made to feel patronised, and SLAs were often 'met' by generic 'filler' comments, only to wait weeks for replies thereafter. Countless times I was 'bounced' from person to person. Often the emphasis was on closing the ticket than solving the problem.

Why this happens is a topic in itself, but is often training, process and culture related. Or too few support staff; either an indication of bad management or a product that's too cheap. Pippin publishes in his income reports an interesting metric of Revenue per Ticket. A lot of companies would do well to take support as seriously as he does.

Nowadays, as there's more choice in the market, bad support simply isn't an option.

Rant over.

Beaver Builder's support is great. It seems to be from an end user's perspective, but it certainly is from a developer's too. On numerous occasions, I've thrown complex issues at these guys. In return they've

  1. Added new parameters to filters
  2. Walked through custom code, and suggested improvements
  3. Let me submit pull requests to add new features to the core plugin

Their responses are quick and friendly too.

On top of that, there's a great Facebook group and Slack channel, where I tend to lurk most days (I'm @db9429).

Further Opportunities

Other than being a great page builder that you can use as a development platform to build themes for your clients, it should be worth noting that there are other business models you could consider if you offer your clients a page builder.

With it's multisite friendliness, there could be scope to offer what I call WPaaS (WordPress as a service).

Many people do this already. WordPress.com being a prime example, but others include EduBlogs and InvestorCarrot. It's a model I want to make work some day.

Perhaps this starts to commoditise your development offering, but it does give scope for you to offer value in other ways. In my previous life as an IT consultant, the exact same thing happened. Individual components of an IT infrastructure were moved up the channel to cloud providers. In fact my role as a Microsoft Exchange specialist probably wouldn't exist now. It makes little commercial sense not to use Office 365 (or Google Apps).

I digress.

You can even white label it.

No longer does it have to be 'Beaver Builder', but it could be DougBuilder. Or WhateverYouWantBuilder. Complete with the ability to change the logo that client sees when they use the editing interface, and even the plugin name and description in WordPress admin.

Taking it one step further, you could even look at what I (had to) call WPaasaas.

WordPress as a service, as a service.

My BBF (Beaver Builder friend... see what I did there?) Adam Lacey and I had a conversation on Slack (he's @bannerpenguin) a few weeks ago, around exactly this.

Take for example a wedding planner. As part of their service, they could offer single page websites to their clients to talk about smooshy couple stuff and collect RSVPs.

But they're not going to start spinning up their own Multisite and installing Beaver Builder. If that's your 'space', then there's an opportunity to create tailored, managed solutions for them to resell.

Shortcomings of current page builders

There are 1.5 opinions I have on this currently.

Too much control

I don't like too many options. Too much control confuses people, and it makes things harder to manage over time. Take the style properties that you can modify on a simple Beaver Builder button, for example:

  • Background colour - default
  • Background colour - hover
  • Text colour - default
  • Text colour - active
  • Width
  • Alignment
  • Font size
  • Padding
  • Border radius

(But no border colour/width/style...).

Doing this for every button is laborious. Sure, you can clone a module within the same page, but not across pages.

There is also the concept of global modules - you can customise a module, and then save it globally, for reuse elsewhere. But you can't then edit a single instance of it, without modifying them all (text too).

As a developer, and as I mentioned earlier, I create my own modules. So this isn't an issue for me. I preset styles in SCSS, and let users choose a style and size from a select field. I then add the relevant CSS class to the button.

Personally, I'd prefer the option of defining styles globally, via a UI, and then using select fields to apply those styles to individual modules. This could be for small modules, like buttons, as well as site colour schemes.

I have a rough idea in my mind of how this would work. If only I didn't spend my time writing really long blog articles like this one (OK this is a one-off), I might be able to knock something up.

That, and something similar might be in the next major release of Beaver Builder (but that's pure speculation).

Appeasing your users

The half point, in extension to this, is that I think page builders have a tough time appeasing their users. But this is mainly because, as I said in the introduction, their user base consists of website owners, website builders and developers.

Ie. it's very hard to stay out of the 'everything to everyone' trap.

This therefore causes lots of settings to appear on the site, while also being fairly opinionated in other ways.

That said, Beaver Builder does give you the flexibility to rip out entirely what you don't want, and only use what you do. There are 2 well known Beaver Builder plugins, UABB and PowerPack that take care of providing lots of new modules and features, which means Beaver Builder itself can remain pretty clean.

Elementor, seems to bundle more and more things into their offering. Tailor seems to be very clean.

Conclusion

Using a page builder has forced me to adopt a very modular approach to theme development. And as a result, I feel much 'freer' now than I used to while writing endless ACF loops, and trying to calculate how columns will 'work' on the front end. The shackles are off.

As a developer, it's important to consider the value of your offering. For me, it took a while to understand that this isn't tied directly to the amount, or complexity of code you write (in the context of WordPress theme development).

A fully content-managed website might be the core part of your service. But the website needs to be easily maintainable and should adapt as an organisation does.

Giving your client a website that they can 'manage' is one thing, but this means more than simply making a field available somewhere. If the interface is hard to understand (like with my ACF Flexible Layouts examples above), that value is diminished, and the chances of a website becoming stale and simply 'existing' increase.

If a content-managed site is only a "tool" in a wider scope of services in a full-service offering, then I think you'll enjoy the benefits of front-end editing anyway. Landing pages, for example, can be created in minutes and not hours or days.

Although Beaver Builder is my weapon of choice, I would invite you to research and test it and others yourself.

I'd also suggest that you look beyond what each plugin 'has', but rather what it can 'be'. Download the ones you're interested in, and do a search for 'do_action' and 'apply_filters'.

Go further, and give your users a demo of some of these tools and collect their feedback.

Test for 'shortcode hell' - download the free versions of the plugins, add/edit content, disable them and see what happens.

Of course, if you have any comments, questions or points for debate - get commenting below.

Finally, and I don't normally do this, if you've found this article interesting, I'd appreciate if you'd share far and wide!

The Aftermath 🙂 Debates with others on this topic

But even only 24 hours after posting this, I've had some great conversations with people on this topic, and I'm sure I'll continue to do so.

Some have been via Slack, and some via email.

As I posted this initially in the Beaver Builder Slack and Facebook groups, I got a lot of positive comments (as well as error checking of my writing!), but I guess that's to be expected given the audience.

But as the purpose of this article isn't to (intentionally!) shove Beaver Builder down people's throat, but rather build a case for page builders in general, I thought I'd try and hunt out people who had made firm decisions not to adopt them.

Again, to be clear, this isn't an attempt to "convert" them, but just create debate:

Keith's a knowledgeable developer, who I've heard speak at a few WordPress events in London.

He's also not keen on page builders!

I'd seen him involved in a Twitter conversation recently about this very topic, so I got in touch with him to ask for his thoughts - and he very kindly obliged.

Before we jump into them, by coincidence (I think), he had published an article of his own only today (10/03/2017) on the pitfalls of page builders, which you can find here.

I'll touch on a few points from his article, but most of them are addressed in the 'meat' of this article, however, I think I perhaps need to go back and reword some of my explanations better, or even provide visual examples.

His email reply was as follows:

Re: the client becoming the designer - This goes hand in hand with my issue of 'too much control'.

In the current alpha version of Beaver Builder, however, you can create the structure and design and give your client only access to write text and add images. Demo video on the way!

Re: You can't set global grid structures - Yeah - agreed. This is something I found too. Eventually, I conceded and created full-width templates, and simply let Beaver Builder manage the structure inside, but it took me nearly a year of wrestling to get to this stage; a very tough decision to make, and fully understandable.

Re: Maintenance and consistency across pages - Perhaps I need an example of what this means in practical terms to give a better answer, but I think this comment is in relation to control of styles globally, which is a bugbear of mine as I highlighted in the article. There's things you can do, as a developer, but definitely an area for improvement.

Re: CSS in the DB/PHP doesn't sound maintainable - To be clear, in my opinion, you should only include styles in PHP that have small, incremental changes - like pixel values or hex colours.

My PHP CSS files are usually no larger than 30 lines per module, if there's a media query, but usually ~10. Comparing this to inline styles (which I used to use a lot of, perhaps Keith doesn't), it's hugely more manageable.

Re: All the lock-in, shortcode stuff -This comes up a lot. But I will say, that shortcodes are definitely a 1st-gen 'thing'. If you've used Visual Composer, you'll likely have been 'bitten' by this, but the difference between these page builders is, honestly,  chalk and cheese.

Of course, if you build a set of columns with Beaver Builder, or use a Beaver Builder 'accordion' module on your page, and then disable Beaver Builder, your columns won't be there, and your accordion will be converted into plain text.

I'd also argue that any plugin has lock-in to some degree. If you disable ACF on a site that heavily uses ACF, you'll find a lot is missing. You can't just swap it out with another custom field solution. It's the same with WooCommerce, Easy Digital Downloads, Gravity Forms. Once you start using them, you're locked in.

In fact, I'd say Beaver Builder is one of the most anti-lock-in plugins I've used.

Touching on his points from his article:

Re: Built-in, inconsistent design - His point being that built in modules won't fit with your theme design, without lots of tweaking.

As I mentioned before, but would like to highlight again, is that I use Beaver Builder as an empty shell. I use it as an interface API, almost. Nearly everything gets removed:

  • All modules, apart from 'image' and 'WYSIWYG' (text editor)
  • Default settings fields, such as visibility to logged in/out users and CSS class and ID selectors unless I need them
  • Templates are hidden
  • Global settings, including custom CSS and JS options are well and truly hidden

All I'm left with is an interface to drag and drop my own 'stuff' into the page with.

Re: Content mismanagement system - The example screenshot used in the article is Visual Composer, and yes - that isn't fun.

As I said earlier in the article, those 'bitten' by the use of 1st-gen page builders might feel that even the likes of Beaver Builder and other 2nd-gen, front-end builders might suffer from the same inadequacies. A lot has changed (thankfully!).

Thanks Keith!

Here's the thing... I love to write and teach, but I'm terrible at self-promotion. If you found this article interesting, I'd really appreciate if you'd share this article with people you think would also enjoy it.

17 thoughts on “Beaver Builder as a Development Platform – Part 2

  1. Thanks for this in-depth analyses of pagebuilders. For sure pagebuilders, combined with CPT/CF will change the playing filed of WordPress more and more. Already many years people say the WP is a CMS. Technically spoken tehy were right, but there were not that many solutions which showed. Of course many plugins used the CPT/CF’s to do their things, like WooCommerce plugin.

    With BB and the new Beaver Themer, the combination with CPT/CF’s become more powerful, because you don’ have to code your own template files to get a nice appearance of both archive and single post page.

    In that way business applications could be created more efficiently than before. But yes, there will always be some kind of ‘border’ between buidling a website and programming a website. And yes there will always be some difference in code queslity between using a box of plug-ins and one from the ground up developed plugin for just one specific purpose, which had everything in it, to do those tasks.

    But for me, in the end, only the value to the customer counts. Can I solve his/her problem? Yes, I can. For sure, at this moment I have the right tools to do that in the way my client do expect me to.

    • Hey Peter! Thanks for stopping by and commenting.

      You’re completely right, value is what matters. And the playing field is changing.

      Your comment about ‘the way my client expects me to’ – I do agree with that, and I do feel that expectations are changing. Perhaps more people are seeing the likes of Wix & SquareSpace offering much more intuitive editing experiences. Content management doesn’t just mean adding a field to an interface anymore. As you see in my ACF example, that field might require navigating through lots of different layers!

      Thanks again Peter.

        • Well, I don’t know if I am looking the right way in the Beaver Themer collection of possibilities, but until now I cannot find support for the ‘flexibel’ field type……

  2. The best read of 2017 so far Doug! I have a short attention span, but this kept me fully engaged.

    I shudder at some of my own crazy widgetizing and php templating experiments. Incredibly painful for a code hacker like me and worse it never once felt less than ludicrous.

    Mostly, I’m pleased not to have to touch code. I like to see the big picture, but Beaver Builder’s logical simplicity and ever expanding knowledge is starting to inspiring me to tinker some more.

    I have no idea about the other 2nd Gen Page Builders. I have a similar criteria to you and have not feel to need to look further, but if a battle is stirring I’m pleased to be on your side.

    • David,

      I also found my way through PHP to make (not develop) archive and single post pages within PHP. I learned a lot but it was so time consuming, that Beaver Themer is like a real ‘gift’ for me 😉

    • I don’t know if that says more about my article or your choice of content sources 🙂

      Thanks for taking the time to read all of this and commenting – I’m sure we’ll be discussing this (and more) in depth as this topic evolves.

      In fact, I already have to update the article (and make it even longer!!) as I’ve been debating this with a couple of anti-page builder developers.

      And I will send you a copy of my other plugin(s) soon(ish) that I promised you… 🙂

      • Doug,

        Ha ha my comment above was suppose to say “ever expanding knowledge base”. And right there is why I really should not touch code.

        I’d love to hear the anti-page builder augment. The folk I hear only seem to set up strawmen to argue against.

        I’m holding you to the plugin promise 🙂

  3. Doug, amazing write-up – thank you so much!

    Beaver Themer is a unique product in WordPress ecosystem. Just like a quality page builder aka Beaver can get hooked many people – Beaver Themer will most likely have same impact.

    Themer gives absolute control of every aspect of the theme. How cool is that?

    • Hey Davinder!

      Thanks for dropping by – great to see you here 🙂

      I do agree, Themer will be very powerful. I think for developers who are not yet adopting page builders, however, it might be one step too far just yet! In fact, I don’t think I’ll personally adopt Themer for a few months, as I prefer the control with code.

      I did say exactly the same with Beaver Builder, and now I use it on every project 🙂

  4. Nice to read about your Journey into WordPress Development 😀

    Reading some other comments about CMS/Content – take a look at pods.io especially for structured content!
    It work’s for end users && dev with php 🙂

    And Yes Beaver Themer is a really big game changer! – especially in combination with post meta ( even without a plugin for it )

    Thanks!

    • Hey @quasel

      Thanks for your comment 🙂

      I am watching the videos on Pods that you sent to me earlier. I think whatever is used, it will be a great combination now that there is support for pulling in meta to Beaver layouts!

      I’m glad you enjoyed the journey story. Everyone has to start somewhere! 🙂

      Speak to you soon.

  5. Hey, Doug. Awesome write up. Thanks for taking the time to put all this together. Glad the experience has been “freeing.” We love hearing things like that! 🙂

  6. I dream of a CMS, or a CMS plug-in, when the text input part and the layout part are separated. In the layout part I am designing views, templates and layouts. I only insert the fields in which to display the appropriate content. Content you enter elsewhere. Like a Toolset from wp-types, but toolset is deadly slow. This is part for Beaver!
    The copyrighter uses only the standard wordpress section (expanded by the necessary fields) to enter the content.
    What You think about that idea?

    • Hi Thomas, thanks for stopping by!

      What you’re describing is actually fairly simple to do. using Advanced Custom Fields/CMB2 and some fairly basic PHP (or, perhaps not even that with the new version of Beaver Builder & Themer), you can do exactly that.

      For structured data, such as products with certain attributes, this is absolutely the best way.

      For regular pages or blog posts, however, the content publisher will need to hit ‘publish’ and view their content on the front end before they really know what it looks like. This is where page builders really shine, as users can see what their content looks like as they create it.

Leave a Comment