The low initial cost of commercial WordPress themes compared to the relatively high cost of developing a custom theme can be a huge benefit regardless of the purpose of your site. But, depending on how your future needs shake out, you might pay a high price later for that initial convenience.
Lost in that glow of efficiency is the risk that if for some reason you want or need to change to a different theme, you might have to pay back some of that initial savings through increased maintenance costs.
When lightweight, open-source content management systems started becoming available in the mid-2000s, web developers and webmasters bought in quickly, taking advantage of WYSIWYG editors that allowed people without coding skills to manage a website’s content and so provided clients with control over their content (and relieved developers from some maintenance drudgery). Also, and at least equally important, we appreciated the promise of a site’s content becoming portable. We could, for the first time, completely change the appearance of a website without having to duplicate the content by changing a theme or a template. All we had to do in a new template was make sure we made the right calls to the database to render the content we wanted, then we were free to style the appearance of the site however we wanted using css. These are two important advantages of a CMS: WYSIWYG and Portability, and the problem with some commercial WordPress themes is that they sacrifice portability to take fuller advantage of a WYSIWYG editor.
Consider this feature, three responsive blocks of text-links, a popular feature that can be generically called a “card”:
Here’s what it looks like in the WordPress WYSIWYG editor, which has been overridden by the Avada theme’s “Fusion Builder” view:
You can use the builder utility to do a lot more than you can with just a simple editor and this is what allows people to create unique sites without knowing any code.
But, and here is where the problem lies, if you remove the proprietary “builder” tool and look at the content stored in the database – the content that will be used by every theme you might use on the site, even those that lack the builder – this is whatyou see (click on the image for a larger version):
If you look closely (and maybe squint hard enough) you’ll see lots of stuff that looks like this:
That’s a “shortcode“, a block of text set off by brackets (“[ ]”) that is interpreted by PHP code running on the theme (combined with built-in WP code) which renders it as HTML and, almost always, some inline CSS, usually. The code above is for the start of one of the three “cards”, and the HTML created is this:
Just to be clear – those 447 characters in the top sample shortcode translates into the 137 characters in the bottom HTML. That seems like an inversion of the way programming is supposed to work, but there are good reasons for that. That shortcode describes a page module with many options and the module is very versatile. This case uses very few of those options and so renders as stripped-down HTML, but if more options were selected then the translation would be longer. The home page of this particular site has about 1,268 characters (200 words) of textual content and about 18,000 additional characters comprising 52 separate shortcodes.
Two issues arise from the presence of so many shortcodes.
First, unrelated to the issue of portability and probably less important (like everything, it depends), interpreting the shortcodes uses server CPU cycles and that additioanl use increases the time it takes for the page to load, negatively affecting what we loosely call “performance”. If you’ve ever seen the recommendation on Google’s PageSpeed Insights to “Reduce server response time” then you might have seen a case of making heavy demands on a hosting server.
This performance issue, luckily, can be mostly avoided by using a caching utility, so that the server delivers stored pages to the browser, eliminating the need to calculate everything anew. That doesn’t solve the problem completely, but it mitigates it enough that you don’t really have to worry about the shortcodes degrading your site’s performance.
The second, and worse, problem is that your content is no longer portable.
If you change you site theme to one that doesn’t recognize those shortcodes, the features of the site defined by the shortcodes will disappear, replaced by the uninterpreted textual content of the shortcode. You can extract the actual page content from the shortcodes by simply deleting the shortcodes and you can also use regular expressions to search and replace (or delete) them if you have a good text editor and you know how to use it, so extracting the page content from the mass of shortcode content is a reasonable (if tedious) task. But the functionality created by those shortcodes, galleries, “cards”, sliders, pull-quotes, testimonials, and so on, will lave to be re-created. In a moderately complex site that is a far from trivial task.
From a long-term maintenance standpoint you’ll be far better off if you’ve avoided putting site modules and widgets in the WYSIWYG editor by using a custom theme or one created specifically for your type of business. This approach will place secondary content, modules and widgets, in separate, custom post types and WordPress categories that can be re-used in your new theme. The re-use will probably require custom programming to display the module/widget, but won’t require that the content be re-created because the content is held securely in the WordPres database.
In the simple case sketched above, we could (for instance) create a custom post type called “Features”, enabling a user to add, delete, and edit the content of each of the cards as individual content items, then write php code that uses the many hooks and filters built in to WordPress to display the three cards below the page’s textual content, making sure the cards look the way we want by using CSS. If you decide you want to move those “Features” to a position above rather than below the main page content you can do that by making a change to the templete. You don’t have to touch the content.
I’m not advocating avoid framework-based commercial themes. I still recommend them when a budget requires a lot of DIY effort because it remains true that the low initial outlay can be a overwhelming deciding factor in choosing a commercial WordPress theme over a custom theme. Just be aware that with that decision you are taking on some technological debt and that the total cost of ownership of that theme could be a large multiple of the initial cost.
I’m simplifying things considerably.