At our sister site Answer Guy Central, things have just been converted to Ultra, a brand-new WordPress theme from the folks at Themify. Themify sells themes based on a home-grown page builder, and it was dealing with a Themify theme that spurred us being in touch with the client who pushed us into starting The WordPress Helpers.
And during the conversion to Ultra we saw something we’d never seen before. And something else, too.
About midway through the project we were having some minor problems and in the course of addressing them contacted the Themify support team. Our issue was odd enough that they asked to try and address it for us, and … proceeded to completely break the entire WordPress installation, bringing it down to the dreaded WordPress White Screen of Death. You never want to see WordPress’ White Screen of Death; it means something is so broken that unless you have more skills than most people you have a real problem on your hands.
Fixing it was relatively easy; we employed a simple edit-the-WordPress-database-manually trick and we were back in business. But we soon discovered that every time we switched themes—not something you should be doing often, but a great testing trick when things are odd—the white screen of death would return.
Not OK; it suggested something was wrong enough that we couldn’t safely deploy the new website until we’d figured out what.
To their credit, the support team at Themify figured out the problem. But it was a sloppy mistake on their part; there’s a plug-in bundled with Ultra that’s “required” (not, not really), and the activation of that plug-in upon being prompted and guided by Ultra is what caused this very uncomfortable new form of the WordPress White Screen of Death. You read that right:
A Themify plug-in that claims to be but isn’t really required to use a Themify theme broke WordPress
Wait, it gets better:
The reason this problem cropped up is that we had the wrong version of the plug-in—and it was the version that came with Ultra.
But in the course of diagnosing this problem we did a bunch of research into the way the Themify Builder works, and that concerns us even more.
A couple of months ago we ran this piece on Theme and Page Builders, and explained the differences in how they work. Two of the builders we described then use the questionable technique of storing all their data in the OPTIONS table of the WordPress database. Themify’s builder does something equally strange: it stores its data in the POSTMETA table.
Except, not consistently. Themify builder stores all of its data in POSTMETA; if you use the builder to create the entirety of a WordPress post the post will appear to be empty. But if you use a combination of the builder and WordPress’ own page composition tools, part of the post will be in one place (marginally editable in the WordPress database), but part will be encoded using the WordPress postmeta API, rendering it all but inaccessible and raising serious data safety and integrity issues unless you’re extremely vigilant about such things.
Despite how it sounds, this is less an indictment of the Themify Builder than a cautionary tale. As we said above, Themify’s support is top-notch and responsive and if you’re careful about back-ups there’s not a whole lot more to worry about using the Themify Builder than any other method for laying out WordPress posts. But it was about the strongest illustration of why that’s important we’ve ever seen.
And also of the reality that managing WordPress well requires knowledge of a lot of things. Which is why we’re here.