For some time now there has been a slowly growing movement amongst particular designers and developers against WordPress. We’ve seen light CMS’s, decoupled PHP frameworks, open source alternatives and the big one: static site generators, but no matter the alternative, it seems it’s for the wrong intentions.
What WordPress Is
Firstly, WordPress is a content management system that started out as a blogging platform. I’d actually argue WordPress is a framework of sorts in that it provides you with; user authentication, plugins sytem, themes system, helper classes and a loose structure which it expects you to follow (but isn’t overly strict on).
Over the years WordPress has grown in size and scope (like most projects of WordPress’ age do), but there have been more concentrated efforts for some time now to make it faster, lighter and eliminate legacy code (one release at a time). Having said that, WordPress is quite large and could be considered a heavy application.
What WordPress Isn’t
WordPress is not some magic cure-all, bulletproof solution for every purpose.
You can build absolutely anything in WordPress, however that doesn’t mean you should. You can build portfolios, CRM’s, project management applications, video streaming sites, community based sites, blogs, online stores and even fully-blown web applications on-top of it (thanks to its generous selection of plugins and free/commercial themes).
WordPress isn’t a magical bullet that is meant to replace existing PHP frameworks or other CMS’s like Drupal. It can be overkill for many purposes and sometimes it is better to use something built for the task at hand instead of WordPress (a large online store for example should not use WordPress).
Argument #1 – Wordpress is too slow and doesn’t scale that well
Like any PHP application, performance isn’t limited to a code level. There are things like server resources, configuration and database query optimisation to consider. Under the hood the WordPress query system is actually quite good with support for caching and query optimisation out-of-the-box.
There are quite a lot of decent caching plugins for WordPress, my favourite is W3 Total Cache. Not only do they cache pages to static HTML files, they also cache DB queries, images and enforce good habits like setting expiry periods for your static resources (images, HTML, CSS).
Most instances I’ve encountered with slow performing WordPress installations were mostly due to horrible hosting environments (shared hosting like Hostgator, Dreamhost, Bluehost) and poorly written 3rd party plugins.
WordPress is only as fast as you allow it to be. Install NGINX, PHP-FPM, Varnish and APC, then install a caching plugin and marvel at how fast your site runs. Tweaking your NGINX configuration file can squeeze out additional performance.
This article explains all you need to know to install the above aforementioned items on your server.
Look at sites like Techcrunch (running WordPress), they’re being hosted on properly configured servers running NGINX, using a combination of caching plugins and server-side caching solutions like Varnish and APC. Considering the traffic they get, I’d say they scaled WordPress quite fine.
Argument #2 – Wordpress is bloated
This is true, but a somewhat misguided argument. WordPress is quite a big web application, and there is a good chance a lot of the functionality bundled with WordPress out-of-the-box is not being used most of the time.
Given its age, there are pieces of legacy code and functionality which aren’t so easy to decouple and change. As anyone who has worked with a large-scale legacy code-base will tell you: it’s not that simple.
However, WordPress is getting less bloated with each and every release. The core team are aware of this and things like application size are not going unnoticed.
The size of WordPress itself is by no means a barrier to building something with it. It’s really a non-issue considering you’ll spend your time working in the “wp-content/themes” and “wp-content/plugins folders” and shouldn’t ever need to edit core files.
Argument 3 – Upgrades break 3rd party plugins
This is a very valid argument. With most things that rely upon 3rd party dependencies you take the risk with each and every upgrade that an existing dependency/plugin might stop working, which obviously on a client website is a bad thing.
It’s really a catch 22 here: upgrade and risk a breakage, or don’t upgrade and risk having your site hacked because of an exploit in an older version of WordPress.
For quite a while now, WordPress has been relatively stable. There have been minimal changes in the API and the core team are very careful to not deliberately remove something or risk changing things to the point existing plugins completely break.
If a plugin is built to proper coding standards, adheres to WordPress’ way of doing things as much as possible, the chances of a plugin breaking are quite low.
I can’t recall a situation in the last 3 or so years where a change to WordPress broke a plugin. Where possible and time permits, you should be trying to not use plugins (unless you have to).
Most instances of plugin breaks are due to reliance on API’s (social networking plugins especially) and bad practices (I’ve seen plugins with hard-coded table prefixes expecting your installation to use “wp_” before).
Argument #4 – WordPress is unsafe because it is a target of hackers
Before WordPress even existed hackers were attacking other popular applications, Windows used to be the frequent target of hackers in the 90’s, 00’s and still today. Why? Because it’s popular. The larger the user-base is of something, the higher chances of finding a victim to attack. WordPress is used by millions of people, if you were a hacker, you’d attack WordPress too, right?
Recent improvements to WordPress with minor version auto-updating are good steps in the right direction to secure your site. The WordPress team can only do so much, ensuring your server is secured is also another proactive step (proper file/folder permissions, user separation) to not being hacked.
There is no such thing as being 100% hacker-proof, an application of WordPress’ stature and size, as well as list of 3rd party dependencies and libraries means potentially many points of entry for an attacker. This is a problem many applications like WordPress face on a daily basis.
To the credit of the WordPress team, I can’t recall an incident with a client or personal site being hacked in at least a year, maybe longer. A couple of years ago my WordPress sites were being targeted a lot, but things have since changed.
The Wordfence Security plugin for WordPress is a must-have and if you’re not already using it, install it now.
Be informed when deciding to choose WordPress for your next project, but don’t write it off as a bloated insecure mess, because you might be pleasantly surprised of all the things WordPress offers you that you are taking for granted.
There are situations where it makes more sense to use a static site generator and there are situations where using Magento for that online store makes more sense. Use whatever works for you and not because it’s cool to hate on something else.