I’ve been working and developing with WordPress since its inception. The content management system’s simplicity is phenomenal, and its mass adoption has no surprise. There are haters out there, but I often remind people that the issues with WordPress are usually centered around the themes and plugins implemented, not the core platform.
The analogy I often use with people is aftermarket automotive parts… some are incredible, and some can destroy your car. WordPress is no different. A case in point that I wish to share is this site, Martech Zone. A few years ago, I found a fantastic theme with all the features and functionality I wanted to share my content in a usable, beautiful, and elegant user interface. Over the years, I continued to enhance a child theme that I built and was happy the developers of the original parent theme continued to support each version of WordPress.
A few weeks ago, I was having an issue on the site and couldn’t find how the code was developed so I went over to the developer’s forum… and their site was down. So, I went over to Themeforest where I purchased the theme… and it was gone. I then looked for the developers of the theme… and they were gone.
I was on my own!
Decades ago, when you bought a product you expected to use it for life. In today’s fast-paced, low-cost technology world, we’ve grown accustomed to tossing our technology when it breaks or becomes obsolete. That’s fine… I don’t mind buying a new toaster. But when it’s the software running your website, it’s quite the headache. To return to my analogy, it’s less like an aftermarket set of rims and more like your transmission breaking. It’s a significant expense, and a huge challenge in the WordPress ecosystem.
WordPress Is Still Great
My goal with this article isn’t to complain about WordPress, it’s a flexible platform that can be updated, transitioned, or customized with very little effort. As well, the ecosystem of developers, themes, and plugins is beyond the imagination. I’ve helped companies do some incredibly innovative integrations and automation with the WordPress API, and I continue to be optimistic about its future.
My goal with this article is to share, what I believe, are some significant shortcomings of the platform so that people are aware of some of the core platform’s inherent challenges. Notice I said core… I realize that there are themes, plugins, and headless architectures that can overcome these. I’d just like to see WordPress architects innovate on some of these shortcomings.
Specific to Martech Zone
I don’t have time to develop for a month, so I had to transition the site to a new theme and then iron out the issues.
- Author Archive – One issue that I have right now is that I have hundreds of authors so building an author page requires quite a bit of development so I can limit the list to anyone who has shared an article in the last month. That’s not too difficult… I can develop a custom template, query the latest posts, pull the unique authors, then build an array of them, order them alphabetically, and display their profile information.
- Custom Post Type – I built a collection of acronyms for the site that was really doing quite well. On each of the acronym pages, I even included the latest posts using the acronym. And… it worked well, people really liked moving from the definition to some articles about the topic. However, I had to build a custom archive, taxonomy archive, and single post template for the custom post type to display it properly. Now, with a new theme, I have to redevelop those.
For both, I have the core code. I just have to build out the templates in my new child theme to get them operational. It’s not difficult but it is time-consuming. WordPress has the features to develop these but it’s not that easy. If you’re a business – this is quite an expense. It seems that there’s an opportunity for WordPress to build accompanying (core) user interface options to custom post types for customizing how they’re queried and displayed. Again, I know there are plugins that help… I just think this is an opportunity for the core platform.
The new theme I purchased and the child theme I have has this limitation as well. All custom post type archives, taxonomy pages, and single custom post type posts use the default theme options. Again, I know that could be a nice feature in the theme… but I really wish this was a core feature. I’d love to be able to click on a custom post type setting, select how it’s queried, and select a layout option… rather than coding it all.
Ten Additional WordPress Challenges
Here are some other issues that I’ve run into that continue to challenge and cost time and resources with my clients:
- Search Engine Optimization – If you’re publishing content for acquisition efforts for your brand, product, or service, organic search optimization isn’t an option – it’s a must. The capabilities of WordPress are woefully inadequate here… even if you’re paying for Jetpack for your site. Tag optimization, rich snippets, sitemaps, and other features are critical to optimizing your site for search engine users. It’s why we won’t implement a site without Rankmath.
- AMP – While it’s not WordPress’ fault, AMP support is terrible. Jetpack has AMP capabilities but, inexplicably, they disable shortcodes support from your parent theme to your AMP display. Just as a child theme assumes features and functionality from a parent theme, it seems that AMP should be a child-type theme. One of the reasons that I selected the new theme I did was inherent AMP support.
- Performance – WordPress is still a dog when it comes to speed as you continue to customize it with additional plugins and theme features. When we work on our client’s sites, the most complex issue we tackle is site speed. If we do a deep dive, we often find hundreds of queries and requests made for even a single page to be displayed. I’m not an expert in this area, but I’m surprised there are no inherent database query caches and native caching on the core platform at this point. I’ve worked with other platforms that published pages by physically creating cached files rather than dynamically generating them with every request.
- WooCommerce – WooCommerce was originally developed to utilize the WordPress API, so it uses the core posts table to store product information and treats the products and categories like a custom post type. Products aren’t posts or pages, though. Products are a collection of features, pricing, and versions. If you’re coming out with a new version of a product and you’re going to release it on a certain day, it’s quite difficult to draft and publish the new version release. The workaround is to create a new product, unpublish the old product, update the new product’s permalink, etc… and then, of course, you have a different product ID between the two.
- Forms and Data – It really takes a form plugin or integrated third-party platform to manage forms and data on your site. I’m surprised that WordPress hasn’t incorporated forms and data as a core feature – especially since WooCommerce basically utilizes both as well. Elementor, for instance, does an amazing job and even has webhook capabilities that make it simple to integrate.
- Spam – I was paying for Akismet but it was useless against form spam and doesn’t seem to have evolved at all over the years. I still received a ton of spam, especially through forms on my site. The WordPress team should just kill it and buy and integrate CleanTalk which is a far better solution with native form plugin integrations.
- Staging – Virtually every managed WordPress hosting now has staging versus production environments where you can develop and test, then push your changes to production. We use Flywheel for this and absolutely love it. But staging to production has awful limitations because of the architecture of WordPress. As we develop on staging, our clients are typically still producing content in production. Theme development often results in database edits. As a result, we can’t just push staging to production… we have to manually push changes to production. If WordPress did a better job of discreetly separating ALL content from Themes & Plugins, it could be possible to simply have the ability to push one or the other rather than just selecting theme vs. database.
- Workflows – The majority of companies require the ability to have content workflows with people who write, edit, then approve content before it’s scheduled to go live. While WordPress has great roles built-in, there’s no workflow management to assign and notify those roles. As a result, companies look externally to develop, edit, and approve the content and then only use WordPress to publish it.
- Content Journeys – Newer content experience platforms aren’t organized by the type of content, they’re organized by the type of user. These systems have dynamic capabilities with rules-based or intelligence-based flows that walk a visitor through an experience. That’s a dramatic change and something that WordPress may never be able to accommodate.
- WordPress Widgets – I’m a fan of the Gutenberg editor and really appreciate the flexibility it provides while supporting previous content architectures. However, when WordPress decided to try and adapt the user interface for widgets to look and act like Gutenberg, it was a disaster. The user interface is awful… and if you have a ton of widgets, it’s slowww. One of the features of my new theme was an option to disable this interface and I was ecstatic. If you want to disable the block editor for widgets, there’s code you can add to your child theme or an official plugin you can install.
I know I’m going to get a ton of pushback on third-party applications, integrations, plugins, and themes. We continue to maintain and promote our own list of recommended plugins for WordPress. Again, my point is that the features above are becoming core to a content strategy, not a feature or functionality outside of them.
Disclosure: Martech Zone is using affiliate links throughout this article.