WordPress is a CMS with an astounding share of the web with over 30% of the world’s websites using it in some fashion or other. Highly adaptable, it can be used for just about any application from the blog it was originally designed to be to a static website to e-commerce and beyond.
But just because it can be used for all those purposes does not mean it should be. The further you stretch WordPress from its original design, the more likely you are to run into problems as a result.
I’ve been using and adapting WordPress since 2003 – before the idea of plugins was even a possibility – and have spent much of the last six years professionally developing and maintaining a custom e-commerce/events system in WordPress so I’m keenly aware of the pitfalls that occur from using WordPress in ways it wasn’t meant to be used.
Let’s take WooCommerce as an example. It’s one of the best ways to turn a WordPress site into an e-commerce one. It takes advantage of the ability to create custom post types to create ones for products, orders, and more. And that is where the first issue occurs.
When your posts table is being filled by orders, it makes any kind of migration a mess. It’s it course ignoring the revisions capability which already makes migrations difficult.
With custom post types come custom post statuses, and the horrors that can occur when they get cross-pollinated.
The addition of customers to the users table makes user management a much more painful experience and opens the possibility for vulnerabilities to be exposed that turn a customer into a temporary admin.
Compare this to Magento, a dedicated e-commerce platform which has clearly delineated tables for admins, customers, products, orders, and CMS content – never allowing for any cross-contamination. On the other hand, it isn’t as adaptable to any purpose as WordPress is.
Does this mean that WordPress should never be used for anything beyond the default? No, of course not. It just means you should acknowledge the weaknesses of the platform and make an informed decision about whether it is the correct choice for the application to are building.
When I was at university, we were taught Visual Basic .NET as a prototyping language. It was a system that allowed you to get basic functionality built quickly so you could demonstrate the concepts involved. The expectation was that you would then use Java or C to build your actual application. But at the first proper development company I worked for, their main product was coded entirely in Visual Basic. It worked because VB is a fully functional language, but it had also grown out of a weekend kludge-project and then continued to use VB even after a full rebuild. But it worked, so why change it?
I am growing to think of WordPress in a similar vein to how my lecturers taught Visual Basic. It’s a great platform and there are applications it is perfect for, but there are cases when it should be used as a prototyping tool rather than the final product.
