Wordpress For Business: An Awful Idea
Recently my design partner and partner in life wrote an excellent article concerning why you shouldn’t use wordpress for websites that aren't primarily blogs from a designer, client, and editors view. This lead to more than one complaint the argument was strictly from a designer/client point of view - go figure! Today we will be discussing why using Wordpress for anything but a blog is silly from a developer's point of view. Some of this is covered in her article as well.
Design Purpose - A screwdriver for nails
From the ground up Wordpress is designed architecturally for blogs. Files are stored by date. The back-end is organized for blog creation. The front end api is designed for accessing blogs. There is no versioning. Permissions for groups of users leave much to be desired. Just about every single decision made in the architectural design process for Wordpress was made with blogs in mind. This means that while it’s great for blogs, for any other type of site it’s essentially using a screwdriver to put nails into wood.
Use a hammer dummy!
Die hard enthusiasts might argue - Yes! But Wordpress has thousands and thousands of plugins that extend this capability for use towards any type of website! However, when you look at the reality of these plugins you end up with an admin interface that is clunky, hard to use, and confusing. Why is this the case?
Obviously, it’s because WP is meant for blogs. Not for eCommerce. Not for a web portal. Not for a business site. Blogs. This also leads us into our next point concerning the quality of said plugins. First though, I unfortunately must state the following: If you want an eCom site use eCom software. Don’t bolt WooCommerce on top of a blog. Choose an eCommerce engine. Magento is an enterprise level MVC platform based off Zend and is free.
Otherwise, you might as well be duct taping half a hammer to a screwdriver. You end up with two dwarfed versions of each. Likewise for a business site (i.e. Concrete5), or web application (i.e. Yii/Laravel and Angular).
Community Code Quality - The Lowest Common Denominator
Wordpress has the lowest common denominator of coders across the board for any cms except perhaps joomla. Anybody that can google a few php tutorials thinks they are an amazing developer and invariably those users tend towards WP due to its popularity - not because it’s the correct tool for the job.
This also leads to developers that should know better frankensteining their existing framework on top of wordpress to increase their visibility and sales. This is like building a skyscraper on top of another skyscraper. Not only are you doubling your concerns, and multiplying your costs, you just have to ask yourself: why?!
A Wordpress Developer Making Design Documents
What does all this mean? One downside is lack of cross version support for many of these community generated features. This means updating your wordpress to handle its multiple security issues each version can destroy functionality to your site.
What else can you expect? Variable quality code of plugins, variable quality of support for said plugins and security risks. And since we know it’s built up to be a blog, likely you will be using plugins to gain the functionality it was never meant to provide. Like mentioned above, this also leads to a confusing back-end interface, especially when compared to CMSs like Concrete5.
Security - Too important to ignore
Security sucks on wordpress. Its infamously bad - almost on par with Joomla. Security is paramount for any web portal, eCommerce engine, blog or really anything. End of story. Unless you want your client to look unprofessional dolts when it inevitably gets attacked; worse they will suffer loss of profit or degradation of trust in their brand.
Is it inevitable? Its breadth of use and popularity almost ensures that your site will be hit by broad stroke attacks. So many insecure sites are out there using Wordpress you can count on Chinese or Russian hackers spamming your site, scraping it or taking advantage of various methods to crash it. Worse than that, they'll piggy back off your site which will cause Google and Facebook to flag it as a bad neighborhood, destroying your SEO and social reach. Do you know how Google ranks sites? Yeah. Security matters.
SEO - A Secondary Constraint
So we know it’s dangerous from an SEO perspective already due to its security weaknesses. The rabbit hole goes a bit deeper unfortunately.
SEO was never a primary design concern during its implementation.
While it does offer some basic functionality, likely for anything advanced you are going to have to look elsewhere. This of course leads you back to our sections on security and code quality. One notable historical example is SEO byYoast which had more than 14 million users and allowed blind SQL injection. And guess what? Plugins are going to complicate your front-end markup, making your site harder to be crawled. But there’s more.
Speed is one factor that google takes into account when calculating its ranking. Wordpress ranks among the slowest in benchmarks - slower even than Joomla with its far more extensive framework. It’s TTFB is abysmal in comparison to competitive options. Given that you’ll likely be using plugins, this matter is multiplied due to aforementioned poor code quality standards.
Additionally, in the increasingly mobile world, responsiveness is a factor in Google rankings. Just the other day we had a site jump up from rank 4 on google to above a wikipedia article and into the number one spot partly due to implementing responsiveness. Where other CMS systems deliver built in responsiveness right into the engine, this functionality is left up solely to the theme developer in Wordpress. So if you want to develop responsive sites, in wordpress it’s going to obfuscate and complicate your workflow requiring more iterations of development between the content creator and the developer.
Lack of proper modularity - Let’s make development more difficult
Speaking on workflow, we must touch on exactly how your interface with wordpress as a developer. The API is almost completely procedural.
This also makes programming in a modular fashion very difficult. The end result of this is that for each project you do you will have less reusable code for the next project, and a longer development cycle. Compare this again to Concrete where you can develop easy to use blocks for use across multiple sites as distinct packages with low overhead. On wordpress, each of these blocks will instead require its own plugin if you wish to reuse it, complicating design concerns.
This leads to many of the plugins also being procedural. The Gang of Four's Design Patterns came out in 1994. What's your excuse WP developers?
To get into the nitty gritty of this, Wordpress uses three main design patterns of note: the subscriber/publisher, singleton, and factory. None of these patterns lend themselves particularly to extensibility by the third-party developer. Compare this to the many MVC based CMSs which base their third party code capabilities and extensibility off of the Model-Viewer-Controller paradigm and allow for easy overriding with low overhead through smart auto-includes. Many of these other systems solve a number of issues, including the aforementioned update problem.
Conclusion - Round Block, Round Hole
If you want a blog, then wordpress is for you. If not, you are going to find yourself fighting constantly against the design constraints, the security, and the reality that is Wordpress.
You might as well be shoving a square block into a round hole - it may work if the square is small enough, but it’s still not an educated decision. -John Davis