CMS Critic, a popular website covering the content management system market, has switched their website from WordPress to ProcessWire. ProcessWire is a free, PHP based, open source, four-year old, content management system maintained by Ryan Cramer. CMS Critic cites the following reasons for moving away from WordPress:
- Poor performance on their webhosting account
- Too many plugin/theme updates
- Too many plugins in general with no vetting process
- Difficult to use caching plugins
Their number one reason for leaving WordPress is bloat but their explanation of bloat is different from most I’ve read.
WordPress; like a lot of CMS platforms; relies heavily on plugins for extra functionality over and above the core services. The main issue, however, is that these plugins are not actively vetted out (or tested) by core team members to ensure they use optimized code and are safe for your site. This means that by installing a plugin, you can bring down your whole site and cause yourself mountains of headaches all because you wanted to add some extra functionality.
The bloat they speak of is not from the core of WordPress, but due to the number of plugins they installed. They are the ones responsible for the bloat, not WordPress. While they raise a good point about plugins not being vetted from a code quality stand point, they are vetted to make sure they don’t contain security vulnerabilities and follow the WordPress plugin directory guidelines.
According to CMS Critic, Cramer reviews most of the modules before they end up in the official directory. He gives developers a list of improvements and advice that helps limit the potential of modules conflicting with each other. The review process has helped keep problems stemming from modules to a minimum but I don’t see how it can scale. If the CMS ever reaches the point of receiving 20-50 modules per day, Cramer will need to find help or risk losing precious development time.
WordPress Plugin Update Fatigue Is Real
As for updates, each plugin and theme installed in WordPress increases the chance you’ll see an upgrade notice each time you login to the backend. Despite upgrades being as easy as clicking a button, having to go through the process every day can become cumbersome. CMS Critic makes a good point in that you can’t tell the difference between a critical update and a bug fix release. As far as the user is concerned, every update is critical.
While most plugins have a changelog where you can see what changes are in the latest release, themes do not. This is something that will be addressed when the WordPress theme directory receives a major overhaul. Even if a change log is available, it’s not always clear to the user if the update requires immediate.
What makes all of this a moot point is the security advice of always run the latest version of WordPress which could be extended to plugins and themes. If you follow that advice, it doesn’t matter whether an update is critical or not. There will likely never be a system in place to determine the importance of an update because it creates another layer of complexity involving a decision that shouldn’t be complex at all.
The development philosophy of “iterate and release often” works fine for services like WordPress.com, but not so much for WordPress, themes, and plugins. Coen Jacobs wrote an excellent post explaining why not all WordPress plugins should iterate quickly and release often.
Of course, it’s a great thing to be able to develop new features at a fast pace, be able to quickly deliver this to your users (or to add an extra layer of complexity: to your customers) and release a couple fix releases in the time between. But it also requires your users to deal with this number of updates, or they might be at risk of falling behind or have potential security issues in their websites.
Update fatigue is a real and should be avoided if possible. The problem is compounded as the number of installed plugins increases. I’d like more plugin developers to come up with a better release strategy instead of sending out an update as soon as they’ve fixed a bug. Beginning with WordPress 3.7, users have the ability to automatically upgrade core, plugins, and themes. However, turning on automatic updates because a plugin is updating too much is a poor reason to use the feature. It’s worth noting that automatic updates are impossible for certain sites to use such as eCommerce or those that use version control to verify updates before they go live.
My Experience Using ProcessWire
In order to see what all the fuss is about, I installed ProcessWire on my local server. Installation is easy and didn’t require me to edit a configuration file. Here is what a sites looks like after a fresh install.
The backend of ProcessWire is simple but coming from WordPress, is like being on a new planet. Everything I’m familiar with in terms of creating content is missing. I can create pages but from a background of knowing pages are more for static content, I’m not sure if that’s the optimum method of creating content. There’s no welcome screen, no signs of help if I need it, and it quickly becomes obvious this is created by developers, for developers.
After using the CMS for 30 minutes, I promptly gave up trying to do anything cool with it. ProcessWire has a modules directory to add functionality to the platform but it’s not accessible from within the CMS without the modules manager.
ProcessWire comes with a lot of bundled modules that can be turned on or off. This allows you to specifically determine how much functionality your site has. Over the years, there have been several discussions on whether WordPress should start moving its feature set into separate plugins. This is where I appreciate the decisions, not options philosophy of WordPress. I’d rather be given a strict feature set and then add-on to it with plugins. I couldn’t care less about enabling/disabling core functionality but I understand how this is a great feature for developers.
ProcessWire is based on the premise of everything being an API call away. “Underneath, ProcessWire 2 is a purely API-driven content management framework that is fully functional without any sort of admin interface.” WordPress is steadily moving in the same direction, especially once the JSON REST API makes its way into core.
ProcessWire Wouldn’t Be My First Choice
I’m happy to see another GPL licensed project gaining steam and finding a place all its own. The community is active and the main developer has over 8,000 forum posts. They also have a showcase filled with websites using the software. If you’d like to check out ProcessWire for yourself, they have a demo available which shows an already created, public facing website. You can also log in to the backend to see how it looks and functions.
If I were going to switch from WordPress to another publishing system, ProcessWire wouldn’t be my first choice. There are several reasons why. First, I’m not a user within their target market. Second, most of what I want out of a publishing system it doesn’t have out of the box. If it does, it’s not obvious. Last but not least, because of the way ProcessWire functions, it doesn’t have a way to install new themes for the frontend of the site. Great for developers, terrible for users.
Several of the reasons CMS Critic moved from WordPress I think are benefits, not detriments to the project. It’s great that they’ve found a project that is more in line with what they need but with the nature of evolving software, how long will it take before iterations and improvements have them looking for yet another CMS to switch to? In most software projects, end users far outnumber developers. I get the impression that most of the users for ProcessWire are developers. If the project doesn’t decide to cater to end users, I don’t see it ever becoming much more than an addition to a developer’s toy box.
There are plenty of things that need improvement in WordPress, but after using ProcessWire for 30 minutes, I was reminded of how many things I take for granted. More on that in a future post.
What do you think of ProcessWire? Is it something you can see yourself switching to or building client sites with? What parts of ProcessWire can be used as inspiration for future improvements in WordPress?