5 WordPress page builders from a web developer’s perspective

Some thoughts and experiences about page builders in WordPress: my subjective ranking and specific pros, cons, workarounds, and workflows.

Introduction: WordPress development in 2024

From a web developer’s perspective, all page builders share the same disadvantage: They strive for a “what you see is what you get” no-code approach, discouraging or preventing the editing of a page’s source code. This makes it even harder to safely transfer code and content between development, staging, and production instances.

This is fine for startups and hobbyists who want maximum flexibility without spending money on professional web development.

The problem starts when small businesses start to scale and want to change and extend their websites step by step beyond the initial do-it-yourself approach. I usually prefer a relaunch with a proper (child) theme when we have enough time and money. We can still follow a hybrid approach and give website owners a lot of flexibility to edit their layout thanks to the Gutenberg block editor, but we can restrict that freedom and yield the benefits of code-based development: separation of concerns, testability, deployment and rollback, code reviews etc.

Full Site Editing is bad, but not the worst

However, many of those advantages are lost when we activate Full Site Editing. Our theme’s template parts and block patterns can get overwritten by alternative versions only available in a specific WordPress instance. Worse, even without Full Site Editing, the block editor’s poorly documented JSON-in-HTML-comments syntax required inconsistent code formatting. So when you add a line break or omit a redundant parameter, you risk causing a “broken” block in the visual editor, even when the block still works in the theme’s frontend.

At least we can open a code view in the block editor to copy its output to a theme file, another page, or another WordPress instance. Other page builders, like Divi, hide their source code more consequentially.

My Top 5 WordPress page builders in 2024

I have shared my problems and workarounds with current WordPress technologies and extensions in several blog posts, so I don’t need to repeat every detail here. My listicle of page editors for WordPress in 2024 only has negative numbers, because I really don’t like any of them. But as far as I can see, Bakery is still one of the lesser evils, and so is Gutenberg, as I have to say after trying to work with Elementor and Divi.

We can possibly add more items to the bottom of the list. The more specific and the more restricted no-code solutions become, the harder it gets for web developers to get their work done. Semplice is just one example for a specialized page builder that can do a great job but only as long you don’t need to do anything beyond its intended scope.

Legacy WordPress web development workflow

What I do when I have to work with page builders to modify existing legacy websites:

• Investigate the existing setup by
  • taking screenshots
  • running automated audits like
    • PageSpeed Insights
    • WebPageTest
    • WebsiteCarbon
    • WAVE accessibility check
  • and saving the current state to web.archive.org
  • for the most important page types, e.g.
    • the home page
    • another static page
    • a blog archive (category page)
    • a single blog entry.

Next:

• Make a backup! UpdraftPlus is a good tool as its backups can be used for cloning WordPress websites, including purchased plugins, to development and staging systems.

• Download the backup files to my local computer!

• Setup a development instance! We can start with a 1-click-installation on shared hosting, or use a Docker-based template like wp_cli_docker for local development.

• Restore the original content. UpdraftPlus will adjust all absolute URLs and ensure a working media library on the target instance.

• Reset the main admin user (either in wp-admin or using the mySQL cli inside the database Docker container) and change its email address.

• Delete all other users.

• Delete all personal and customer data!

• Change the site title and the bookmark icon. My local development setups titles usually start with “Local” and the icons can’t be confused with the production ones.

• Update WordPress and its plugins in my local development instance.

• Verify that everything still works!

Don’t update any part of a customer’s production site before making and downloading a full backup! Don’t do it before making screenshots and saving archive examples! If anything breaks, we need to know the last working state!

• Examine the existing setup for custom code and styles, e.g.
  • Appearance -> Customize -> additional CSS
  • Widgets
  • any other place where themes or custom plugins allow to define custom code
  • custom PHP code in a child theme;

• copy the existing code to project files like custom.css, custom.js, example-child/functions.php and commit it.

• Disable performance, caching, and security plugins locally before proceeding with the actual web development. They don’t help while developing, but their optimization can get in our way, cause outdated page styles and waste memory and energy.

• If we want to show our customer a preview to test, we can setup a public staging instance, transfer a new backup from localhost (which is already free from customer data and optional plugins), and set up password protection to make sure only the right people have access to our stage!

• If we don’t do staging, we can add a draft page on their production server where we can show some progress and make sure that we are really able to copy our work from localhost to production selectively.

Next, I try to find out how best to work with the given setup, how to persist my changes, and how to safely transfer them to another page or instance without breaking or forgetting anything.

As a web developer with a frontend focus, I try to use global CSS as much as possible. I know this contradicts the intention of no-code page builders, but so does coding in general. I found this to be a pragmatic compromise between staying in control of my code and not completely throwing away existing code and software.

Global custom CSS is prominent and easy to find compared to element-specific custom CSS or plugin-specific configurations that might stop working after the next major update.

Depending on the website’s complexity and our experience with its technologies, we might have spent at least half an hour or the whole day getting a grip on a legacy setup without any visible achievement. Before we start coding, we should review our assignment and find an easy subtask to begin with, ideally something that causes a change that is obvious at first sight.

So we can finish our first hour or day of work with a feeling of achievement.