Soon it’s going to be 10 years since I first started working with WordPress.
If I remember correctly, v2.31 was the first version I installed on our server as a possible (better) alternative to our b2evolution 2 blog platform; and we finally transitioned our blog to WordPress in early 2008 – after months of learning, coding, experimenting and yes, countless re-installs.
At that time, we didn’t yet think about using WordPress for anything else than its original purpose – as a blogging environment.
But soon thereafter, more and more sites we saw began to use WordPress as a framework. More and more themes and templates appeared. The community grew exponentially. And for what WordPress couldn’t do “out-of-the-box” – there’s a plugin for that, too.
The “templating” or “skinning” idea wasn’t new.
We had been using data from a database, Server-Side-Includes, (php) includes and external style sheets for a long time.
But we always had to write some kind of admin interface that allowed our clients to make changes (without breaking everything). And of course someone had to pay for it.
The WordPress core system does all that – and more. In fact it does way more than most people will probably ever need.
Adhering to WordPress’ own Theme Development Codex, we started from the ground up, with a blank file every time.
The theme folder quickly grew to 10 and then 14 files, as we were getting more acquainted with using built-in and custom functions, hooks and filters.
In the version we released into the wild in 2008 our theme folder contained 25 files and 2 extra folders.
As of this writing, our custom theme uses 194 files (from 34 folders).
The last custom theme we deployed for a client contains a total 498 files in 98 folders (including sub-folders). Not counting child theme files or recommended plugins.
* We never bundle (or integrate) plugins.
** 2016, the current default WP theme3 as of this writing, contains 45 files (in 5 folders)
While we’ve seen themes with many more files, currently around 500 files seems to be pretty normal.
How did we go from 25 files to almost 500 files?
- Theme customization options/admin options
- Custom post & page (layout) templates
- Custom taxonomies and their templates (e.g. portfolios, events, testimonials)
- Custom shortcodes
- Custom functions
- Custom widgets
- Language files
- jQuery plugins and other JS files
- Custom fonts & icons (incl. icon fonts)
- CSS files for predefined styles and responsive options
- Extra files for plugin customization (e.g. Visual Composer)
As WordPress became more and more main-stream, themes were getting more and more feature-rich, complex and – heavy.
Simplicity was quickly becoming a thing of the past, as theme developers began packing more and more “trendy”
functionality into every new theme.
Don’t get me wrong, I like the idea of being able to change my theme’s colors for any particular part of the template via an integrated admin interface.
Same goes for fonts, font sizes and font weights (I am NOT saying you should be using more than 2 different fonts on one page).
Want your header layout changed and move the logo to the center? You should be able to do so easily.
Want to turn a particular part of the template off on this particular page? Sure thing.
Unfortunately, most of so-called theme developers (with a few exceptions) don’t have a clue about how code works and/or what a particular section of code does.
They copy and paste parts of other themes and plugins and hope it all works. And this is how the end user ends up with bloated, confusing and vulnerable code on their servers – waiting to be exploited at any time.
Resulting Problems
1) Security Issues
The more complex and bloated these themes get, the easier it is to include malicious code – knowingly or unknowingly.
Remember the Revolution Slider exploit that affected hundreds of thousands of sites in 2014?
Not only was the core of the plugin vulnerable, many (most) themes had this plugin code pre-packaged as part of the theme (sometimes buried deep within the theme files), making it almost impossible for the regular web-client to remedy the situation on their own.
Although the plugin developers reacted quickly and even made the updates available for free download, many (most?) website owners didn’t even know their sites were affected, until Google showed the dreaded “Unsafe Website” warning to their website visitors.
However, most of the time reality looks a lot different. By the time the website owner finally becomes aware of the fact that his website has been hacked, the original web/theme/plugin developer is long gone and he – as the consumer – is left holding the bag.
2) Compatibility Problems I – WP core
Another problem with copy-and-paste mass-produced themes is compatibility (or lack thereof) with WordPress core updates.
We recently worked a WordPress website developed by another company when the website owner came to find out one day that they couldn’t edit a single existing page.
Reason: a WordPress core update was incompatible with the bundled (and customized!) integration of Visual Composer.
3) Compatibility Problems II – Content
Switching themes? Good luck with that. Especially when your current theme has one of those custom page builders, as they are guaranteed to only work within that particular theme.
Gone are the days where you could simply export your current data and import it into a new theme or, better yet, simply activate a different theme.
You might end up with something like this:
4) Compatibility Problems III – Plugins
You’ve paid for this overhyped theme and the build-out of your website only to find out that you cannot use your favorite plugin with it? The plugin that you either purchased or had developed for your particular business needs? That’s too bad.
“But it used to work on my old website!”
And it probably still works with the default theme.
*** Ever noticed that most theme/plugin developers on theme market sites do not offer custom work?
5) The theme is slowing your site down to a crawl.
This is one of the most common complaints we hear. Your cool new theme is loading hundreds of (external) files to create this completely irrelevant effect, or makes hundreds of unnecessary database queries and now Google has downgraded your site because it takes forever to load.
Tough luck.
Conclusion
Bigger is not always better.
I like to know what’s in a theme’s code. While nobody’s code is immune to future exploits, at least I know where to look and how to fix a problem.
Users want content fast, and their attention spans are short. Don’t make them wait for the relevant content while your animation has to finish loading (Hint: They won’t).
Most theme demos look impressive because they contain loads of demo (or dummy) content: videos, images, articles, product pages and shopping carts, testimonials, portfolios – and the list goes on and on.
Most website owners have difficulties coming up with very basic content for their sites.
Carefully weigh your options and make an informed decision.
1 WP history: https://codex.wordpress.org/History
2 b2evolution: http://b2evolution.net/
3 WP default theme history: https://www.elegantthemes.com/blog/editorial/from-kubrick-to-twenty-sixteen-a-history-of-wordpress-default-themes