A professional association needed an updated, easy to maintain site. Time to purge the page builder.
A small organization that brings together people who provide expert services to the arts community in Canada needed an update to their WordPress-based front-facing and membership services site. Their previous site was attractive enough and did all the things that they needed, but it had been built with a commercial page builder plugin. I won’t say which one. It could be any of them.
The site’s publishers found it next to impossible to do page maintenance on any of the site’s pages because of this.
Page builders are meant to provide a visual interface for a complex coding language to enable people who don’t code to build websites as if they do.
But in trying to create a visual representation of a complex language they create labyrinthine form interfaces with obscure labels and icons that are cryptic at best.
And, while they’re built by private companies, they operate over top of a public, open source project. No doubt the developers put a lot of time and effort keeping their products in sync with WordPress itself. But they don’t always succeed. And as someone who maintains quite a few page-buildered sites, I can tell you that the end users of said plugins most certainly do not.
They don’t or can’t pay for the licenses that allow upgrades. So the page builder stays installed as it was on launch day while WordPress itself progresses forward until the version comes (automatically and without warning in a lot of cases) when it pulls the rug out from under the out-of-date page builder and the site turns purple. Or goes all WSOD.
So I try to get rid of them wherever I encounter them. Especially since WordPress itself supplies visual tools in the form of its Block Editor (and increasingly) its Site Editor, that are easier to use and yet more transparent than every page builder I’ve ever encountered.
There are plugins built to rip some builder-specific shortcodes and cruft markup out of the the content of posts and pages, but often it’s a question of editing each buildered page and ripping out the markup manually or copying and pasting from the front-facing page.
The latter task is pretty onerous but if you look at it as an opportunity to inventory your content — and assess whether that page really needs to be migrated — you can start to see it as the yang side of the crisis/opportunity equation.
And that’s what I did with this client. They were aiming for a more minimalist, welcoming site to encourage more people to join. They were simplifying the language as part of their ‘less is more’ approach to their new site. And they were looking to simplify maintenance — and indeed make more of their site self-maintainable.
So purging the page builder just made sense.