My FeedDiscussionsHeadless CMS
New
Sign in
Log inSign up
Learn more about Hashnode Headless CMSHashnode Headless CMS
Collaborate seamlessly with Hashnode Headless CMS for Enterprise.
Upgrade ✨Learn more
Why I don't use WordPress

Why I don't use WordPress

Francesco Boffa's photo
Francesco Boffa
·Jul 2, 2017

I've developed a few WordPress sites. The actual number of WordPress websites I've put online and managed for a while is probably around 20.

All the time that I had no choice but working with it, I felt that something was wrong, but I didn't really know why. I've been lucky enough that at a certain point someone hinted me at Ruby on Rails, and I felt like my career finally started.

Now, with nearly 15 years of hobbyist and professional development in a variety of languages and worlds, from Embedded Systems to Machine Learning and back to Web Development, I can finally outline why I will never use WordPress again, and I will suggest anyone on my path to do the same.

If you're learning web development and having your first website, keep playing with it. It's still a nice and extensible playground. You want to run a business? Look elsewhere.

An half-baked solution to half-baked problems

What is WordPress? A few years ago, it was pretty clear that WordPress gives you a blog. Today? WordPress is everything and WordPress is nothing. You can have a blog, an e-commerce, a learning platform, a Social Network, your own YouTube clone, a CRM, your own SaaS solution - even at the same time.

So, this is great, right? No

The problem with this approach is that today WordPress does not excel at none of these problems. Do you want an e-commerce? Check Shopify, Magento or PrestaShop. A CRM? You want SalesForce. A learning platform: Moodle.

You want to build your own Social Network or SaaS solution? **Get a development team and write your solution.**

(Sorry but I have to add this. You want a blog? Use Ghost)

Use the right tool for the right job.

A fresh install of WordPress provides you with an underpowered blog. Yes, underpowered.

You will have three CSS and two JS files in your website head, all unminified. You post permalinks will look like /?p=1, like its 1998 again.

(I am not affiliated with any of the links that I published in this article, just pure and true suggestions)

Plugins to the rescue

What is the solution to such an underpowered platform? Plugins. The only point where WordPress excels is its extensibility. No WordPress setup counts less than 15 plugins.

Some plugins have become so essential and that I'm still wondering why they haven't been incorporated yet. WP Total Cache for example. Why in the world doesn't WordPress handle asset and uploads minification? Why the management of browser cache is left to a plugin?

Plugins open the way to a whole new set of problems, but first let me talk about something even more serious.

A poor development and deployment workflow

Ask anyone serious in the Web development world today and ask them how would they feel if they had to use FTP to deploy changes.

When someone tells me they use FTP to put changes online, I am really sad.

First of all, FTP is a plain text protocol. You can install all the best security plugins in the world, and then you send your server password in clear text on the network, so that any script kiddie can login on your server and ruin your business.

Using FTP is also a strong indicator that you are probably not source-versioning your code. If you have to change something, you change it locally and upload the single changed file.

Even worse, if you work in a team, you may be using the live server as a File sharing service, where everyone collaborates and uploads changes, often overwriting each other.

In the worst scenario I've seen, there's no local copy. You install WordPress, install themes and plugins and just do all the deemed customisations LIVE, straight from the Admin panel.

So what do you do if your blog receives an attack? If you were smart enough to at least have a backup of your database, you may try to start from scratch and reinstall WP again, with all plugins and all customisations - AGAIN.

If you don't even have a copy of the DB, you can't do anything. Your blog is gone.

FTP and the possibility to install and customise plugins from the admin panel are probably the root causes of why more and more developers are running away from the platform. They are light years away from established best practices used in every other project, whether open source or enterprise.

Back to plugins

The concept of plugins in itself is not evil. All the opposite, every programming language and ecosystem has what are known as libraries, gems, packages and plugins.

The problem I see with WP plugins are multifaceted.

Absolutely no tests

It looks like the golden rule of writing tests for your code has never been received by the WP plugins community.

Here's the test coverage of some known and used plugins:

  • WP Total Cache test coverage: 0%
  • Yoast! test coverage: 0% (some libraries it uses are tested though)
  • WordFence test coverage: 0%
  • Social Warfare test coverage: 0%

I could go on forever listing other plugins, but the really sad part is:

  • WordPress core test coverage: 0%

Features that should be part of WordPress

As said before, most of WP Total Cache should just be part of WordPress, not an extension.

Some features of Yoast!, like pretty URLs, Sitemaps and robots.txt management are so essential that it's just unbelievable that they are still not part of WP itself.

Do not even get me started on security plugins like WordFence. Why do I need a security solution? Do you really need to hide the wp-login.php page? There can only be two reasons to do so, and both are unacceptable:

  • WordPress is so unsecure that leaving the login form exposed means giving access to the admin panel
  • You are too lazy to change the default admin password.

You are hiding your head under the sand here. It's like installing an Android Antivirus instead of paying attention to what the hell are you downloading on your smartphone.

Do you know what are you installing?

The fact that WordPress has grown with the plugins mindset means that most WP admins will just grab a list of "XX essential WP plugins for your blog" and install them all without paying much attention.

With every new plugin comes a more untested code, new attack surfaces, new useless features, more load on your web server and most importantly, more code that you are running on your server without knowing what you are actually running.

That code could potentially do anything, from stealing you database, to joining a botnet to conduce a massive DDOS attack, to mining Bitcoins at your expense.

This issue is of course present in any other ecosystem, with the difference that most developers would only use a library/gem/package after a few considerations like:

  • Can I do this myself or do I really need a library?
  • Is this library maintained or abandoned?
  • Is this code tested?
  • How many people watch the development?
  • How many issues and PRs does this library have?

To put it shortly, you would look for signs of code health before giving it 100% unrestricted access to your platform.

Scalability issues

If you have a small niche blog, you may not be particularly interested in this point. But if your blog starts growing to thousands of page views per hour, and you didn't learn to follow best practices, trust me, you will suffer.

The fact that WordPress allows you to extend its functionality from the Admin panel (yes, I know, again - I really want to make you see how bad it is), means that you are downloading the libraries to the single server hard disk, and that there's no other reference to that.

The most important pattern when it comes to Scalability is the possibility of increasing and decreasing the number of servers handling your traffic on demand.

Now:

Imagine you have 5 servers running WordPress, and you decide to install a new plugin. Guess what? The plugin will be downloaded only to the single instance that received your command to do so.

Congratulations, you now have 4 instances running a different website than the last one.

Conclusion

I will not dig further in the process of customising a theme, because its one of the most painful memories of my life and I don't really want to resurface that kind of sufferance.

By now, I hope to have made it clear that you should stop using WP today and move to a serious platform. Or if you are a young developer willing to learn, do not learn to customise WordPress, learn how to write a proper website instead. Learn how to work with a real web framework like Ruby on Rails or Express. And thank me later.

As a last note, I want to add: you can use WordPress safely, if you follow best practices, including using source control, deploying with git hooks, maintaining database backups, doing frequent updates and not relying on security to some third party script. The problem is, if you are professional enough to do so, you will have run away from it long time ago.