CiviCRM and Drupal7: upgrade to Drupal8, Backdrop or WordPress?

Usual disclaimer: the following are mostly my personal (strong) opinions and rants. I express myself as "we" being Coop Symbiotic, because it's teamwork, but this is not our official policy and any rants or errors or anything that might make you angry are purely my fault :-)

First, bear with me, let's put things in context:

For the past 14 years, I have been working mostly Drupal sites with CiviCRM. In time, my focus has changed to mostly CiviCRM. We still leverage a content management system (CMS) heavily, such as Drupal or WordPress, but the focus of our work is on CiviCRM, because that's what we're good at.

Having gone through upgrades cycles from Drupal 5, 6, 7 and now Drupal 8 and 9, and working with non-profits on a small budget, we have long adopted the following strategy. I mention them now, because I recommend them as part of your post-Drupal7 strategy:

  • Saying "no" to certain features and keeping things intentionally simple. If a new feature is adopted, evaluate how it would survive an upgrade to Drupal8. This also meant keeping views simple, and avoiding the use of Webform. Both do not have an upgrade path in Drupal8, must be rebuild and may not have feature parity.
  • Our themes are often based on the same Bootstrap theme, with only a custom CSS file for a few tweaks (which can still be quite powerful, but it's important to remind clients that no, not every page needs to be custom-designed and have its own CSS). Theming is often a huge factor in Drupal upgrades, and this is something we can avoid when using Bootstrap.
  • Avoid Drupal Webform. It was groundbreaking at the time, but it was never very stable, does not have test coverage (hence regressions), required a lot of clicking around for bilingual forms, and basically re-invents half of CiviCRM. I would rather focus that energy on having good "core" forms instead, or formbuilder. CiviCRM is a rather small community, we can't allow ourselves to divide ourselves into different sub-communities. As a service provider, it was a huge liability. Sorry folks, I know this will make some people really angry.
  • Use the CiviCRM User Dashboard. It can be improved, and we are slowly publishing extensions to improve it, but it provides a pretty good out-of-the-box experience. Stop creating custom Drupal dashboards (which often means: panels and a lot of views).
  • Avoid custom programming as much as possible.
  • If we must customize, do it with CiviCRM as much as possible, because CiviCRM upgrades are much more predictable and provide better backwards compatibility.

Few organizations can regularly spend a huge chunk of money on something that is an instant technical debt (with high maintenance fees). People expect solutions that "just work". It shouldn't take 4 months to create a website. Anyone can create a site on WordPress.com or SquareSpace and have something working within a day or two of work, without a designer or a programmer. It's often what we are competing against, or at least, the expectation.

So that's my starting point.

We started using Drupal8 (and WordPress!) since October 2018, but we still manage over 100 CiviCRM sites on Drupal7. As Drupal7 will be "End of Life" (EOL) in November 2021, it's important to start planning the next steps.

Why now?

  • Drupal7 developers are difficult to find. Who wants to work with a CMS that is 9 years old?
  • Many Drupal7 modules are not actively maintained, if not abandoned. Many do not support PHP 7.3 (old-stable at this point), which means that it will be more and more difficult to find a place to host the website, and eventually being stuck on an old version of PHP will have security risks. When that happens, good luck finding a sysadmin who will want to work with that old version of PHP.
  • Drupal7 features are not competitive. It was great back then, but today there are more intuitive, efficient tools out there. Your client might be "OK" using something that works (they already paid for it), but whenever they have to train a new staff member, or have a new director, they will be reminded that it's old tech, increasing your training and support costs. You might lose them completely.

Where do we go from there?

  • Migrating to Backdrop: Backdrop is a fork of Drupal7 which provides a few usability improvements, is actively maintained and also supports CiviCRM. This can be a good option if you liked Drupal7 and don't like Drupal8. There is still an upgrade path, but it's relatively minor compared to Drupal8.
  • Migrating to WordPress: Start a new website from scratch, then re-attach CiviCRM. WordPress is obviously well-known, easy to host (always supports the latest PHP version), easy to find agencies/developers that support WordPress.
  • Migrating to Drupal8: it's still Drupal, but the migration path is quite difficult.

At Coop Symbiotic, we decided to support both Drupal8 and WordPress.

Drupal8 is still Drupal. There is no upgrade path for Views and Webform from Drupal7 to Drupal8, but upgrading the theme is fairly easy (if using a common theme, such as Bootstrap). Hopefully you don't need a million different views, or you can simplify them, and rebuild them fairly quickly. Get rid of all the duct tape (custom views for random tweaks or workarounds). The Drupal8 migration module does work pretty well for migrating the basic content and users. Unfortunately it's also difficult to find Drupal8 developers, and I have to admit that Drupal "core" code can be very cryptic at times. I really appreciate that it's "standard" PHP (with Symfony and Composer), but Drupal folks strongly insists on making everything an Entity which really just complicates things. That said, since we don't use Drupal very much, the core features are well tested and most hurdles were easy to overcome. I just can't say I'm a "Drupal developer" anymore.

If you do use Drupal8, I recommend using Gutenberg. It's the basic WordPress content editor for Drupal8. Yes, that sounds a bit crazy, but it works well. It also avoid ending up with crazy-complicated sites in Drupal that have 50 fields for a simple node, or using the Drupal8 layout builders which are overly complex. CiviCRM users who enjoy Mosaico will probably enjoy Gutenberg.

What about WordPress? Well, WordPress is great. Lots of plugins, well-known, well-supported. I'm not a fan of paid plugins or annoying adverts from free plugins, but we can often do without them if we use the same philosophy for WordPress as we did for Drupal, i.e. avoid plugins as much as possible. WordPress does lack a good Views equivalent. Some people are working on it (content-views), your mileage may vary. It's still a major reason why we sometimes prefer Drupal. Another inconvenient: migrating users, passwords, content, is still much more work. Many organizations want to start from scratch anyway, so it might not be a problem. It's still a much bigger endeavour than if just upgrading to Drupal8.

Backdrop: as mentioned above, if you like Drupal7 then you may like Backdrop. To be honest, I am not very familiar with it. However, it does share some of the disadvantages of Drupal7: there are few developers, and the underlying technology is old. It might be a lower barrier for organisations, but how do you convince a developer that this is a good time investment? For Symbiotic, we would also have to make sure that our automation tools support Backdrop. Since we are a small company, supporting Drupal8 and WordPress is already a lot of work.

Finally, another solution could be to detach the CMS and the CRM. CiviCRM does lose one of its key advantages when detached. However, we increasingly have situations where the website is managed by another company. We do a bit of theming on the CiviCRM site to match the branding of the main the site, and users are bounced back and forth between the main website and the CRM forms or views, combined with single sign-on. This will be the main topic of a future blog post. Stay tuned!

Archives