Choosing Between Drupal and WordPress from a Non-Developer Perspective
As an entrepreneur, you need a website for your business. Don’t worry, it’s not necessary for you to write your website by hand. You can pick a content management system that does the heavy lifting with minimal coding.
There was a time when I would have adamantly recommended Drupal. Drupal is robust and therefore vastly flexible. It’s also the CMS where I got my start. Naturally, I will always have a certain affinity for the platform, but over the years I found it harder to justify the amount of time I was spending on maintaining the site. This afternoon I decided to let go of Drupal for my personal projects.
To start, it’s worth noting I am not a web developer. This post is not intended for power users who feel completely at ease using CSS and PHP to manipulate themes and modules to get the CMS to do what they need. Rather, I am targeting the person who understands the value of a well-designed website, wants to become familiar with its core features, but ultimately wants to focus more on content creation than coding.
Here are a few reasons why I made the switch from Drupal to WordPress.
Updating Drupal was Unnecessarily Difficult
Upgrading to the next major version of Drupal was a daunting process. Despite modules designed to help you migrate your content, it was often easier to scrap the old files and build a fresh installation. Even minor updates could be a squeamish process. I never did it the correct way. I simply took my site offline, updated my core files using an FTP client, and ran the update script. A seasoned Drupal developer would get heartburn over such a blasphemy.
After Drupal 8, the upgrade process should have been easier. It wasn’t. Despite following all the instructions in upgrading to Drupal 9, the latest version, I still encountered a generic 500 error message that told me absolutely nothing about what I had done wrong. It’s not as if I was coming off a site with a ton of customizations.
On WordPress, your next major update is a click away.
Drupal Became a Resource Hog
Until Drupal 8, you could run Drupal on a shared hosting environment without issue. I am not opposed to paying for virtual private servers to accommodate larger projects, but most of us will start with a slim website. The cost for a VPS is $30 a month at the low end. When you’re just getting started, that is entirely too much money for space and resources you will not fully utilize.
Drupal 8 signaled the beginning for something better than a shared hosting environment. It asked for OPcache to be enabled, which is a performance enhancement feature typically reserved for VPS or dedicated servers. You can still run Drupal 8 without enabling this feature. Its greatest benefit is for high traffic websites, but it felt like the start of things to come.
And things came.
Drupal 9 requires PHP V7.3 and MariaDB V10.3. These are back end components that help process all the moving pieces on your Drupal installation. My shared hosting plan offered the former but not the latter. It is likely why my Drupal 9 installation never got off the ground. Acquia offers a driver for backward compatibility, but first, the driver should have been included in the core files for a more seamless installation experience for all users. Second, the driver is only good for the first iteration of Drupal 9 but not for the next revision. This means when Drupal 9.1 comes out, I would find myself in the same boat.
By contrast, WordPress will operate comfortably in a shared hosting environment and will transition with you when it is time to upgrade to something larger. InMotion Hosting, of which I am a very satisfied affiliate, features a set of WordPress hosting plans that will give you the resources you need without requiring an immediate jump to a VPS. InMotion hosting is not the least expensive, but cheap is not always better.
The Drupal Community was Too Advanced
Jeff Geerling, in an article outlining the success and failure of Drupal 8, wrote the following:
“Sure, there are use cases where someone would consider either Drupal or a hip trendy decoupled web framework backend. But Drupal 8 is actually a really good choice for those who build decoupled architectures using JSON:API, or GraphQL, or whatever other fancy decoupled framework and need a reliable content backend. To be honest, though, it seems that those who do ‘decoupled’ with Drupal are often people who started with Drupal (or something like it), and then get into the decoupled game. And that’s a pretty small slice of the market. Drupal is a hard sell if you have a team of non-PHP developers (whether they do Node, Ruby, Python, Go, or whatever) and are looking into decoupled or otherwise buzzwordy architectures.”
If you are not a developer and got lost reading the paragraph above, you would likely get frustrated reading the Drupal forums. The typical Drupal user is an intermediate to advanced web developer. They understand Drupalese, but more important, they have a firm handle of their craft and don’t need to dumb down their interactions to communicate. Nor should they.
The Drush command line tool used to be the method for accomplishing things like installing and updating your Drupal site. Now the method has switched to Composer, and if your only desire is to hit the ground running with a decent website, this is one more key indicator that Drupal is not the CMS for you. Both Drush and Composer add another learning layer to making things happen on your site. Despite the thousands of modules available to extend your Drupal site, you will inevitably need to tinker with the back end code to get things just right when things unexpectedly go wrong.
There are Drupal distributions that provide a neatly preconfigured package for specific use cases such as professional publishing, education, social networks, etc. Thunder and Lightning are two such examples, and at a glance it would seem like they provide a solid middle ground for the beginner who wants to take advantage of Drupal’s breadth but does not know enough about the modules to make certain tasks achievable. Unfortunately, using such distributions put you at the mercy of the creators. They might choose to stop supporting certain features you’d grown accustomed to relying.
This last points to a larger problem of finding good and affordable Drupal developers to resolve major issues that may crop up. I won’t say the support community is useless to a novice Drupal user, especially if you are willing to take chances with fixing errors yourself, but should you need paid support to help fix your site, you are going to shell out more cash because there are significantly less people familiar with the Drupal environment. It is not enough to be familiar with PHP. The developer needs to understand Drupal nuances. The introduction of Symphony on Drupal 8 should have helped. To this novice user, however, it has not.
Final Thoughts
Sometimes the comments are just as, if not more, insightful than the main article. Consider the comment left on this thought-provoking piece:
“Drupal is just still hard as fuck to learn and use, but it becomes better with every release. Anyway Drupal stands for an overly complex system that nobody should learn if he does not have to.”
WordPress starts as a blogging platform that can evolve into a fully featured content management system. On the other hand, Drupal is a content management system that starts with no predefined purpose. There is beauty in that level of flexibility, but that level of flexibility comes with a certain complexity that makes caring for a Drupal site a time-consuming chore.
I hate change. At the time of this writing my experience with WordPress is very basic. I am happy to see certain tasks like scheduling posts is baked right into the content creation process. On Drupal I would have needed to download a module to accomplish the same thing. I have no idea how I am going to manipulate blocks of content around the various regions of my chosen theme the way I could have easily done on Drupal, but if there is one thing WordPress has going for it, it is the thousands of pages of documentation explaining how things work to a simpleton like me.
In the end, as a hopeful entrepreneur, my desire is to make money. Becoming great at Drupal would have looked compelling on my résumé, but unless my ambition was to become a Drupal developer, spending too much time on figuring out the latest kink on my website would have been more of a distraction than a step closer to my goal.
What CMS are you using? What’s motivated you to stick with it? I look forward to reading your comments!
And, if this article was helpful, sign up for my newsletter!
