Your Developers (probably) Hate Wordpress

In my experience, there are few engineers that really embrace and "love" Wordpress as a platform. Although it backs over 40% of all websites on the Internet (estimated), Wordpress development is generally considered low-skilled and basic. That's perhaps because most Wordpress sites aren't very complex -- it is a blogging platform at its core. As such, it is fairly common for devs to be asked to "spin up a Wordpress", and such platforms can quickly evolve if there's strong business utility.

Scaling these platforms can become more complex than many stakeholders or engineers realize, though. Working in WooCommerce, the challenges are even more pronounced. While Wordpress is "merely" a blog, powering a whole e-commerce stack off a platform that wasn't really engineered for it (and operating it at scale!) can be very frustrating.

The developer perception around Wordpress can become a source of conflict for stakeholders that need a popular CMS like Wordpress and engineers that simply do not want to touch it. Engineers can even push product owners to "pick something else", which can affect product development in a negative way.

Like it or not, Wordpress is a very, very popular CMS for a good reason.

It's Not (Just) Performance

For better or worse, software engineering does have a specific culture. When I was learning, that culture was firmly rooted in the principles of object-oriented design. Back then, the commonly accepted philosophy was to create complex class hierarchies to "better represent" objects in real life, and you weren't really allowed to question that modality. Even as component-driven design has become more popular and the perils of deep and complex hierarchies have become more apparent, some people still cling to that rigid culture.

Beyond OOP principles, modern frameworks tend to embrace an MVC (model-view-controller) approach because it is fairly intuitive and it works well in separating business logic from presentation. If you really understand the principles for how to scale code in a platform like Laravel, you can apply many of the same ideas and structural approaches to any MVC-style platform since your brain is already wired to break logic down into conceptually familiar pieces.

Wordpress, however, has its own "culture". This can be very frustrating for developers that expect a certain approach to structuring an application. Many engineers don't want to watch videos or read tutorials about how a framework works. Yes, they expect some reviewing of docs, but they don't expect to have to learn things from scratch. In Worpdress, the structure of plugins, hooks, and filters requires building up some level of WP-specific knowledge.

The conflict can become worse when stakeholders assume Wordpress is "very simple" and therefore spitting out a few customizations should be extremely easy for skilled developers. This isn't wrong, it is fairly easy...but for developers that don't have existing experience, it can take time to learn. For such devs, there's a conflict between "doing something conceptually easy" and the actual implementation, since they need to understand various facets of how WP works that aren't always obvious.

For WooCommerce sites, this is even more true, as the complexity and performance demands/impacts are higher. Not only that...developing often feels disorganized and disjointed relative to modern frameworks. That's because in many ways it is. Wordpress is not as strict as MVC-style applications, so it can be structured any number of ways. You can create classes and hierarchies in WP, of course, but it's up to the developer to structure it. The framework is not opinionated in how you create your internal code -- you could create plugins for each distinct module, but you can also drive custom functionality outside plugins using a more modern style of structure.

To review, the first reason your devs dislike Wordpress is the core nature of how its structured. It's basic. It's old. It requires specific knowledge of hooks and filters and the WP theme system instead of more generic knowledge as is common with MVC-style applications. If you do want your engineers to have success in adopting WP, give them the time and resources to learn or hire a specialist.

It's Also Performance

I say this often: Wordpress is designed to be flexible. It is not designed to scale.

This is especially obvious in a platform like WooCommerce. Consider a field like the product SKU. For anyone that's touched e-commerce, you know this field is often used as a primary key. You need the product SKU for almost anything and everything. Yet in Woo, this is stored in the infamous "wp_postmeta" table. This table underscores the reality that Wordpress is not really designed to scale, it's designed to be flexible.

This table uses strings as the key name, in a table that can easily balloon to millions and millions of entries. This is, frankly, rather dumb, and is the main bottleneck for performance in most Wordpress applications since so much data ends up being stashed in the post meta, including important fields like the SKU.

For WooCommerce, I have to say...this was just not a very intelligent design choice. This speaks to another frustration of "real" engineers in dealing with WooCommerce. Yes, it's that the performance has challenges at scale, but also that some of the underlying choices around its architecture seem to care more about adhering to Wordpress philosophy more than making sound choices based on the use case.

In case you aren't familiar, the problem is that string-based keys are not performant on a database-level. When you have a massive post meta table and you must do multiple string-based joins, that's a real annoyance to work with and a bottleneck for complex, performant queries.

All this being said, many issues around performance can be solved either by adopting a robust caching strategy or by trusting a third party like WpEngine to do it for you. It can be worth it to use a specialized host when throwing together a WP instance instead of merely tossing it onto AWS. Managed hosts should handle setting up Varnish and warn you about security flaws (or do auto-updates).

Varnish is really key for Wordpress at scale because it "skips" the PHP-layer of the code entirely. This is different than various plugin-based caches that are offered, which can not work as efficiently. Managed hosts are more expensive, but for a Wordpress or WooCommerce site at scale? It's very likely worth it.

Almost Every Plugin Sucks

The final frustrating that many engineers working in Wordpress face is the landscape of plugins. First, the way Wordpress/WooCommerce handle plugins is really crude. It's usually an honor system, even. You pay for the code and the nature of WP means you have the source code for that plugin. Fail to pay and that code will still work. Pirate the plugin and that code will still work. This is great because you can easily see the quality of a given plugin and even modify how it works via hooks or filters.

It also means that most plugins aren't very good. They can punch holes in your security, be horribly inefficient, or cost way more than they should for basic things the platform should already do. Yet the WP ecosystem, intentionally or not, does not really incentive "good" plugin development.

For example, if you were going to develop an e-commerce plugin...why would you do it with WooCommerce, where a client can buy the plugin once, have your source code, and never pay again with no real consequences? Wouldn't it make 100x more sense to focus on Shopify, where the ecosystem is far more developer-friendly?

Wordpress and WooCommerce have an advantage because the ecosystem is older and there's a billion plugins that can do a billion things...but again, that's because WP and Woo are focused on flexibility, not scale.

Some firms decide they don't really need a developer and just use plugins instead, then wonder why their system doesn't work very well at scale. For WooCommerce, they wonder why their hosting bills are so high, and it is because the platform is not designed to scale.

It might not be practical, but the general advice is to avoid plugins. If you must use one, open the code and actually look at how well it is written.

Wordpress is not Secure

Wordpress has a really bad track record when it comes to security. Not only do you need to ensure that your core WP version remains up-to-date, you have to regularly update plugins. Auto-updating plugins is not an option for mature organizations that require 24/7 uptime.

The challenge is that for many organizations, they don't want to take the time to keep things up-to-date. When working in WP, it's very important that stakeholders understand that regular maintenance is part of the price of the platform. It is not optional.

Often, business realities will defer regular maintenance tasks...when stakeholders insist on strict deadlines and only want new features, this can become a huge liability. Spammers can infect your blog and post articles that ruin your SEO or reputation, or exfiltrate sensitive user data, or install malware. This can become a serious legal liability that will hurt you far more than missing a deadline on a new feature.

Do not underestimate this aspect of WP development. I have personally seen how easily this can happen when firms do not prioritize updates and are not cognizant of security flaws; by the time your engineers notice something wrong, it could very well be too late.

Not only should you make sure your devs have the time they need to do maintenance, you should be sure that they do this on a regular schedule. Further, updates must be QA'ed; you have no idea if a random plugin author (or changes to WP core) might break something critical.

Wordpress is Still a Good Product

As an engineer, I'm not a fan of various choices made by WooCommerce or Wordpress, but I do understand why those choices were made. For some businesses, there are no better options, as the flexibility and relatively low cost are massive advantages. Yes, Wordpress is designed for flexibility more than scale...and that's why it's a good product. Many businesses need flexibility more than they need scale.

Many businesses see great value in prototyping, iterating, and being flexible -- finding the "best most robust" platform is not always important until the business idea is more refined. A platform where you can iterate rapidly is perfect for that.

Yes, even more than Shopify. You can spin up a Shopify store even faster than Woo, but it isn't a great platform for prototyping because it's so cookie-cutter. It has a very specific use-case and you either fit with it or don't, and for many organizations their use-case too niche for Shopify.

Sometimes, engineers can't see the bigger picture. The best choice for engineering is not always the best choice for the product.

Conclusion

When your engineers complain about Wordpress or WooCommerce, there's a good reason. Yes, it has a history of security flaws. Yes, it has a history of really bad performance if your engineers don't implement work-arounds. Yes, it's annoying to learn "the WP way" when more modern modalities like MVC are battle-proven and robust.

Knowing a bit more about why engineers tend to have (at best) a "love/hate" relationship with Wordpress will help make development more effective for everyone.

If you're one of the many engineers that dislikes working with Wordpress, try to see the bigger picture in how platforms like WP can be so effective for prototyping or refining business logic -- accept the many weaknesses of Wordpress and try to focus on its versatility. Give stakeholders flexible tools so they can "own" the management of the CMS. Articulate your specific concerns and be sure that stakeholders understand why maintenance is a part of the cost of having a Wordpress stack.

Of course, if you'd rather not deal with Wordpress or WooCommerce, you can always hire me! ;)