Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Feb 29 2024
Feb 29

Drupal 7 had been around for more than a decade, but it will have its "end of life" January 2025. During the pandemic, 7 received a handful of extensions to give folks more time to upgrade, but it will receive no more. Within less than a year from now, your Drupal 7 site will stop receiving all updates and it will become a potential security risk. But even long-term support (LTS) will only support core and some of the more popular modules.

If you're a CiviCRM site owner, or helping someone who is, you should have some kind of plan in place to get off Drupal 7, if you don't already. Soon. Like many of the CiviCRM experts, we at Freeform Solutions have experience helping site owners plan their moves off Drupal 7, whether it be to Drupal 10, WordPress, Backdrop or something novel. You can also start paying for Drupal 7 End of Life Support, but that option will only maintain the status quo.

In this post I'll be focusing on Backdrop CMS with CiviCRM, and its upgrade path from Drupal 7. Most of you are likely already familiar with either Drupal 10 or WordPress. But first, let's talk about Drupal 7 + CiviCRM numbers.

There are still a lot of CiviCRM installations using Drupal 7

Drupal 7 still runs 43% of all CiviCRM sites

Unfortunately, there are still quite a few Drupal 7 sites running CiviCRM. About 43% based on recent stats (as of March 2024)! That's a ratio of 1.9 to 1 of Drupal 7 to Drupal 8+ (8,9,10) sites. Compare that to the stats for all Drupal sites: a ratio of 0.8 to 1 of Drupal 7 to Drupal 8+. It looks like, for whatever reason, organizations on Drupal 7 and CiviCRM are not even keeping up with the already slow pace of upgrades of all Drupal sites.

Why are organizations slow to upgrade?

There are a few possible reasons. Some sites are complicated. They have complicated interactions between the CiviCRM side and the Drupal side. Maybe the site is using Drupal 7 Views, Rules and a few custom "glue" modules to work with a special workflow. This makes it hard to untangle. And the equivalent modules are not available in Drupal 10 or WordPress. In our experience this can get expensive quickly. The migrations can take a long time; especially if the nonprofit relies on their being no significant downtime. Migrating to Drupal 10 may still be their end goal, but it ends up being quite a slog.

Or, a nonprofit cannot afford a major change, like moving to Drupal 10. The original site might have been built by a volunteer who can no longer support it. Some nonprofits will stop using CiviCRM altogether. Others will wait until something like CiviCRM Standalone is mature. Even others are not sure of what they'll do.

Maybe the site has just enough integration with Drupal 7 so as to make it difficult to switch to WordPress, but they don't have the budget for moving to Drupal 10. For these clients, I've found that Backdrop CMS can be a sweet spot.

I'll go over some of the reasons why one would choose Backdrop; what's different or similar to Drupal 7; and a brief overview on how to go about upgrading.

Why choose Backdrop CMS?

Backdrop has an active community of folks who are improving Backdrop CMS with a focus on affordability. Backdrop's mission is for small to medium-sized businesses, nonprofits and individuals who would like to build highly customized websites affordably. Backdrop continues making modern improvements but ensures that are backwards-compatible so as to make sure upgrades don't consume your budget. Backdrop focuses on making it easier to upgrade from Drupal 7, and not break your site when there are updates.

Backdrop receives regular releases of new features and bug fixes. It has a modern look and feel (unlike Drupal 7, which is really beginning to show its age). Backdrop is surprisingly nimble to use as a site builder. I've found it faster than Drupal 10. Backdrop folks also ensure it meets accessibility standards; stays up to date with new PHP versions and other libraries; that it look good on mobile; and gets security fixes and bug fixes quickly.

There are hundreds of contributed modules available for Backdrop. Many of them are ported from Drupal 7, and also some new ones only available for Backdrop.

Backdrop and CiviCRM work well together. As seen in the graphic above, there are over a hundred Backdrop sites using CiviCRM currently (as of March 2024). Backdrop's integration with CiviCRM is also actively maintained. And folks are adding new features to the integration with CiviCRM.

In our experience it is often easier to upgrade a Drupal 7 site to Backdrop CMS than to Drupal 10. Even if some modules need to be ported, those ports tend to be easier. Though we recommend understanding the complexity of your site, and your goals, first to see if it's a good candidate.

What's different?

One of the biggest differences of Backdrop to Drupal 7 is Layouts, though the new functionality is worth it. In Backdrop, Layouts help divide up the entire page into columns and regions. There is a drag and drop GUI that allows site builders to make flexible layouts for one or more types of pages. Layouts are agnostic to themes. And the Drupal 7 to Backdrop upgrade will convert most of the old regions and blocks to the equivalent layouts.

The default CiviCRM admin layout

Drupal, on the other hand, depends on themes for defining regions. It is not nearly as flexible, nor is it possible to create unique layouts from the web interface. People who used Drupal 7 may recognize some of Layouts from the Panels module. It is, in fact, related to Panels, but it has been integrated deeply into Backdrop whereas Panels was never able to completely replace Drupal's theme-based templates.

The Backdrop module for CiviCRM supports Layouts--it includes a CiviCRM administration layout--and provides some special blocks and CiviCRM contexts to check for access and visibility, such as URLs, and the checksum of the logged-in user (or if the checksum is passed via the URL).

A visibility condition on a layout block, displaying if a valid contact views the page.

What's the same?

Quite a bit! Views is in core but it is almost identical to the Drupal version. Your CiviCRM Views should probably just work. Likewise the link between users and contacts is the same. CiviCRM profiles and links to the contact dashboard can be displayed on user profiles.

Using Backdrop Views to display a list of members.

Webform CiviCRM is available in Backdrop and is equivalent to the Drupal 7 module. They both integrate with Backdrop's Webform module.

CiviCRM processing with Backdrop Webform.The CiviCRM processing options for Backdrop Webform.

Like Drupal 7, rules can be set up in Backdrop to sync CiviCRM groups and CiviCRM membership types with user roles (for the contact that matches with the user). And there is a CiviCRM integration with the Rules module for Backdrop to provide even more actions and conditions.

CiviCRM Afform Block can be used to display forms created with CiviCRM FormBuilder in a Backdrop block in a layout.

Selecting a Form Builder form to display in a layout.

And there are more modules that help you integrate your CiviCRM data, such as integrating with Ubercart, or syncing CiviCRM groups with a Backdrop content type. And, finally, your custom modules may require only small tweaks to keep working, as most of the API is quite similar to Drupal 7.

How to upgrade to Backdrop

I recommend that the first thing you do is create a spreadsheet to map out the functionality and structure of your site; what functionality can be removed; what functionality is necessary; the modules; content types; Views; custom code; and the possible upgrade paths. You could use our starting example or create your own. Not every site is the same. This can help you decide if Backdrop would be a good candidate, or if something else would work better. Also check out the Drupal 7 Migration Resource Center for more help in making your decision.

If you'd like to try an upgrade to Backdrop, the following steps may prove to be useful:

Step 1: Read the Backdrop upgrade guide. The guide goes into much more detail on the upgrade process, though it doesn't cover CiviCRM integration.

Step 2: On your Drupal 7 site make sure all your modules have their latest updates.

Step 3: Uninstall and remove any modules which you no longer need. Don't make things harder for you than you need to; so don't try to upgrade those.

Step 4: Check to see which modules have Backdrop versions. Install the Backdrop Upgrade Status module on your Drupal 7 site to get a report. Even if there are modules with no current Backdrop version, don't despair. Often it is not too much work to port the module to Backdrop.

Step 5: Backup your database, files and code. It pays have that around so you can test the upgrade a few times with a fresh installation of your backups. Even better, use a development tool like Lando or DDEV on your local computer to make the upgrade process faster.

Step 6: Replace the old code base with Backdrop code base and the Backdrop modules you want to keep.

Step 7: Replace the CiviCRM module with the equivalent version packaged for Backdrop. The modules can be placed under /modules; they no longer have to be under sites/all/modules.

Step 8: Run the update script, either by going to the URL for your site (or development environment): https://MYSITE.org/updatedb.php or by using the command line tool: bee (equivalent to drush). This will run a lot of updates on the old Drupal 7 database.

If you're lucky they'll all go smoothly and you'll be able to log in and start configuring things the Backdrop way. If they don't you may need to figure out what is breaking. It can help to take away the offending module code and rerun the update (you may need to reimport the backup Drupal 7 database).

Reach out to an expert in Backdrop and CiviCRM if you get stuck! There is a Backdrop channel on the CiviCRM chat. Or you can ask in the main Backdrop chat. I loiter in both chats. And don't forget to consult the Backdrop guide for more specific Backdrop guidance.

In the end, regardless of the platform that someone is moving to, it's important to move off of Drupal 7. So reach out to a CiviCRM expert to learn more about your options.

Filed under

Jan 21 2022
Jan 21

Using Drush with Drupal is standard practice for most developers, but since CiviCRM support was removed, many find themselves having to switch between separate command-line tools for each environment.

Seeing a need for continued Drush support in CiviCRM, Skvare’s developers released the CiviCRM Drush module for Drupal 8 and Drupal 9. Just as with Drupal, this module allows developers to support CiviCRM through a single command-line tool and continue previously established workflows. Edit media Image

Once installed and configured, the CiviCRM Drush module supports many commonly used commands:

civicrm:api (cvapi)CLI access to CiviCRM APIs.civicrm:db-validateValid CiviCRM Database.civicrm:disable-debugDisable CiviCRM Debugging.civicrm:enable-debugEnable CiviCRM Debugging.civicrm:ext-disable (ced)Disable a CiviCRM extension.civicrm:ext-install (cei)Install a CiviCRM extension.civicrm:ext-list (celList of CiviCRM extensions enabled.civicrm:ext-uninstall (ceui)Uninstall a CiviCRM extension.civicrm:member-recordsRun the CiviMember UpdateMembershipRecord cron (civicrm-member-records).civicrm:process-mail-queueProcess pending CiviMail mailing jobs.civicrm:rest (cvrRest interface for accessing CiviCRM APIs.civicrm:restoreRestore CiviCRM codebase and database back from the specified backup dir.civicrm:route-rebuildAdds a route rebuild option for CiviCRM.civicrm:sql-cli (cvsqlc)Open a SQL command-line interface using CiviCRM's credentials.civicrm:sql-confPrint CiviCRM database connection details.civicrm:sql-connectA string for connecting to the CiviCRM DB.civicrm:sql-dumpExports the CiviCRM DB as SQL using mysqldump.civicrm:sql-queryExecute a query against the CiviCRM database.civicrm:update-cfg (cvupcfg)Update config_backend to correct config settings.civicrm:upgrade (cvup)Replace CiviCRM codebase with new specified tarfile and upgrade database.civicrm:upgrade-db (cvupdb)Execute the civicrm/upgrade?reset=1 process from the command line.

With Drush for Drupal and CiviCRM Drush, developers can continue to use the same command-line interface for both environments.

Learn more about how Skvare’s team of Drupal and CiviCRM experts help organizations better deliver on their missions when their technology does more. ​

Filed under

Dec 30 2021
Dec 30

Combining the power of Drupal Commerce with the flexibility of CiviEvent, Skvare’s team of experts developed the Commerce CiviCRM Event Registration module allowing website managers to build a storefront that includes both events and merchandise.

Drupal Commerce storefront.

In the example above, a website offers classes and books through its commerce store. With Drupal Commerce, website managers can easily sell products and, through CiviEvent, users can register and pay to attend events. With the Commerce CiviCRM Event Registration module, both can be done through one interface, simplifying the build and making the entire process better for end-users.

Following installation and setup instructions for using Drupal Commerce for CiviCRM event registration provided by Skvare’s developers, customers can add any event listed in the commerce store to their cart. Customers also can add other products from the store such as class materials, custom shirts, or parking passes — anything commerce — to their cart. 

Drupal Commerce product page

This allows end-users to see everything in a single cart and follow one checkout process to purchase products, pay event fees and register for events. The best part for website managers is because this uses CiviEvent, the end-user is registered for the event in CiviCRM where scheduled jobs can send email reminders, be added to groups for future fundraising efforts, or be granted access to special web pages just for attendees. 

Drupal Commerce Cart.

The Commerce CiviCRM Event Registration Drupal module developed by the team of experts at Skvare brings two great tools together making website management easier and improving user experience.

Learn more about how Skvare’s team of Drupal and CiviCRM experts help organizations better deliver on their missions when their technology does more.

Filed under

Dec 20 2021
Dec 20

People are at the heart of any organization, whether it’s volunteers, students, or clients, and getting the most out of your technology can help organize them to better accomplish your goals.

Drupal websites have leveraged the power of webforms through the CiviCRM Webform module to gather user information, for scheduling and other automated jobs. The one thing missing — user account creating.

Seeing this, Skvare developers created a new CiviCRM extension that allows new users to create a Drupal user account through a CiviCRM Webform, automatically assign Drupal user roles based on configurations and create a CiviCRM contact records with tags or groups assign.

The CiviCRM CMS User Extension works seamlessly with Drupal webforms, bulk import of CiviCRM contacts, or creating new contacts in CiviCRM to create Drupal user accounts when they do not already exist. This allows site administrators to create new Drupal users and CiviCRM contacts through CiviCRM or new volunteers to complete a single webform and create a Drupal user account at the same time.

HOW IT WORKS

Once installed, the CiviCRM CMS User Extension is configured under Administer - System Settings - CMS User Settings. The configuration window lets site builders user tokens to automatically generate Drupal Usernames based on information collected through CiviCRM Webforms, provides options to notify the user of the new Drupal Account through the Drupal People Settings, assigns roles to the new user based on configured Drupal roles and use groups or tags to determine which new users get new Drupal accounts.

The Drupal User Fields portion of the CMS User Settings also lets site builder configure any required fields in the Drupal User settings. For example, if a new user's address is a required Drupal User field, tokens can be used to collect the address in the CiviCRM webform and passed to the Drupal account. In this way, new users can be created with any unique field combination.

Using Tags or Groups is a good way to sort CiviCRM contact records and, when assigned a tag or group through a CiviCRM webform, can be used to determine which users get Drupal User accounts. For websites with multiple webforms for different users, only the users completing the webform and assigned to the configured tag or group will have a Drupal account created while not created accounts for users completing webforms and not assigned to that tag or group.

A second field for tags or groups also allows site builders to remove the tag or group assigned by the webform and assign a new tag or group to the new user. This can allow for new users to be easily found via search in CiviCRM so additional actions can be taken or communications sent.

Learn more about how Skvare’s team of Drupal and CiviCRM experts help organizations better deliver on their missions when their technology can do more.

Filed under

Apr 14 2021
Apr 14

Watch part 2 of Skvare's training series on the CiviCRM Entity Drupal module.

[embedded content]

CiviCRM Entity is a Drupal module that provides enhanced integration with Drupal, allowing developers, site builders, and content creators to utilize powerful Drupal modules including Views, Layout Builder, Media, and Rules. Drupal fields can be added to CiviCRM entity types. It provides Drupal pages and edit forms for all CiviCRM data such as contacts, allowing usage of familiar Drupal content creation tools and workflows.

During this training we cover:

  • Entity view modes
  • Using Drupal fields and form displays
  • Drupal-based view & edit pages for CiviCRM data
  • Entity Reference and Inline Entity Form
  • Entity browser
  • Layout Builder

Filed under

Mar 25 2021
Mar 25

Find out what's possible with CiviCRM and Drupal 8 and 9. Watch Part 1 of Skvare's training series on getting the most out of the Drupal CiviCRM Entity module.

[embedded content]

CiviCRM Entity is the module that provides enhanced integration with Drupal, allowing developers, site builders, and content creators to utilize powerful Drupal modules including Views, Layout Builder, Media, and Rules. Drupal fields can be added to CiviCRM entity types. It provides Drupal pages and edit forms for all CiviCRM data such as contacts, allowing usage of familiar Drupal content creation tools and workflows.

During this training we cover:

  • What is a Drupal entity
  • CE = CiviCRM + Entity
  • How to install CiviCRM Entity
  • The why and the what of integration possibilities
  • Overview of CiviCRM Entity features
  • Introduction to CiviCRM Entity and Views
  • Introduction to CiviCRM Entity and Rule

Presentation Resources

Additional Resources:

Filed under

May 06 2020
bgm
May 06

As of CiviCRM 5.25, the minimum required PHP version is version 7.1, with PHP 7.3 being the recommended version. Since Drupal 6 does not support PHP 7.1 (except LTS vendors, such as myDropWizard), and since there are very few active CiviCRM sites on Drupal 6, we have decided to officially stop supporting Drupal 6.

We strongly encourage Drupal 6 users to upgrade to a supported content management system (CMS), such as Drupal 7, Drupal 8, Backdrop or WordPress. Depending on how much of the content management integration is used, it can be as simple as installing a new CMS, then re-importing the CiviCRM database in that site. For more information, see the switching CMS platform documentation.

If you need a hand, you can find a CiviCRM expert on our partner and contributor listing.

Are you still on Drupal 6? Have you upgraded recently? We would love to hear from you. Please leave a comment!

Filed under

Nov 18 2019
Nov 18

In 1992, there was a little known new thing called the world wide web. By 1995, it was a "thing". Now, what exactly do those quotes do to the word "thing"? And what does this have to do with "entities"?  Cue my favorite programming joke.

Q: What are the two hardest problems in computer programming?

A: Naming things, garbage collection, and off-by-one calculations.

All of that joke is true, but it's the first problem that is the point of this blog post. Because "entity" is just a fancy word for "thing", i.e. coders have the same problem naming some "things" as everyone else does.

What is an Entity?

Just as in our vernacular usage, an "entity" is a "thing with something extra", and it's the "extra" that makes it an entity. To make it more concrete: lots of things can be entities, and in CiviCRM, all contacts, contributions, and events are entities. It's not to hard to think of a contact as a "thing", but in fact, a lot more things in CiviCRM are entities: even such abstract notions as relationships, memberships, and participants to an event. You might get carried away and guess that everything is an entity, and it's a reasonable guess, but not quite. For example, an option in a list of options is usually not an entity. You might also be getting confused at this stage about whether a specific contact is an entity or whether "Individuals" is an entity: the answer is that we use "Entity type" for "Individual", whereas a specific contact is an "entity" (of type "Individual").

Who Cares?

And here's why you should care, even if you're not a programmer. In CiviCRM, entities are a core part of the codebase, and that means that what you can do with one entity, you can often do with other entities. So understanding what is an entity, and what you can do with any entity, makes you a better user of CiviCRM.

Again, what is an entity?

If you look up the definition of entity on Wikipedia, there's a good chance you will be no further ahead than I was after reading it. Because "entities" aren't a specific thing, they are an abstraction. Just like our vernacular use of "thing", a thing becomse a "thing" when it acquires special properties, and those special properties allow us to treat them with a very useful level of abstraction that doesn't need to worry about other details. And now you know why parents often haven't a clue what their children are talking about.

For example, when the web became a "thing", we no longer had to explain what it was, it was a self-explanatory word. Analogously, an entity is a "thing" with certain properties that allows us write code about it without knowing the specifics of the entity - the entity is self-explanatory enough that we can handle it in an abstract manner.

Again, why should I care?

The best I can do is to provide some examples. Here are three that illustrate the power of the entity in civicrm.

1. Custom Fields

You probably know that you can add custom fields to contacts via the web interface in CiviCRM. But that same code works for any entity. So you can add custom fields to things like Relationships, or Recurring Contributions, or ... a surprising number of things you might not even be able to imagine uses for. Go ahead and look at the form where you add a new custom fieldset, and you'll see a long list of things that you can apply it to: those are CiviCRM's entities.

2. CSV entity importer 

Eileen's excellent extension allows you to import data into your civicrm for anything that is an entity. So for your highly customized CiviCRM for which you had to add all kinds of custom fields, you can import that content from your old CRM without even writing any custom code. My example of this, and why I'm such a big fan of this extension, was when our clients needed to import recurring contribution data from their old CRM.

3. The API and browser

CiviCRM has an API that leverages the properties of underlying entities. That means if your site has some kind of custom entity, it's automatically exposed via the API and the API browser, even if you didn't know about it, and even though that code was written before you invented your entity.

3. CiviCRM Entity in Drupal

The Drupal module "CiviCRM Entity" exposes CiviCRM's entities as Drupal entities. Drupal has it's own concept of entity, and it's compatible in concept to a CiviCRM entity. So this module provides some magic glue function allowing all of CiviCRM's entities to also be Drupal entities. And that means you get (for example), Drupal Views of any CiviCRM entity.

But we're still stuck with the hardest problems, including naming things. And off-by-one calculations.

Filed under

Jul 29 2019
Jul 29

In the coming weeks, you can expect a series of changes going into the development pipeline to support the CiviCRM-Drupal 8 integration. Individually, these will seem unrelated and disjoint - they may not explicitly reference “D8”. I wanted to spend a moment to discuss the concept which ties them together: the clean install process, which will make Civi-D8 an equal member of the Civi CMS club and a good base for continued development and maintenance.

This work on D8 stabilization has been made possible by the generous funders of the Civi-D8 Official Release MIH. If you’d like to see more topics addressed, please consider contributing to the MIH.

What do you mean by "clean" install process?

A "clean" install process is a set of steps for building a site in which CiviCRM comes in a direct fashion from source-code with a bare minimum of intermediate steps.

To see this concept in action, we can compare CiviCRM's integrations with Drupal 7 and Joomla:

  • CiviCRM-D7 is amenable to a (comparatively) clean install process. There are three Github projects (“civicrm-core”, “civicrm-packages”, and “civicrm-drupal”) which correspond directly to folders in the web-site. If you copy these projects to the right locations, then you have an (almost) valid source-tree.

  • CiviCRM-Joomla is not amenable to a clean install process. You might think it's similar -- it uses a comparable list of three projects (“civicrm-core”, “civicrm-packages”, “civicrm-joomla”). The problem is that “civicrm-joomla” does not correspond to a singular folder -- the install process requires a diasporadic distribution of files. The install script which handles this is tuned to work from the “civicrm-X.Y.Z-joomla.zip” file, and producing that file requires a tool called ”distmaker”. “distmaker” is fairly heavy - it requires more upfront configuration, is brittle about your git status, runs slower, and produces 200+mb worth of zipfiles. In short, building a CiviCRM-Joomla site from clean source is more difficult.

Why does a "clean" process matter?

It's easier to develop and maintain software when the build is clean and intuitive. Specifically:

  • It's easier to climb the ladder of engagement from user/administrator to contributor/developer.

  • It's easier to lend a hand - when someone submits a proposed patch, it's easier to try it out and leave a friendly review.

  • It's easier to setup automated QA processes for evaluating proposals and upcoming releases.

  • It's easier to setup sites for RC testing, issue triage, pre-release demos, and so on.

  • It's easier to pre-deploy a bugfix that hasn't been officially released yet.

Anecdotally, more experts with stronger collaborations have grown-up and stayed around in the Civi-D7 and Civi-WP realms than the Civi-Joomla realm. And that does not feel like a coincidence: as a developer who watches the queue, I'm generally intimidated by a Civi-Joomla patch -- even if it looks simple -- purely on account of the difficult workflow. I believe that a reasonably clean/intuitive build process is prerequisite to a healthy application and ecosystem.

Moreover, a clean build of Civi-D8 is important for Civi's future. Civi-D7 cannot be the reference platform forever - if we expect Civi-D8 to take that mantle, then it needs to be on good footing.

What kind of changes should we expect?

From a civicrm.org infrastructure perspective: Expect automatic setup of D8 test/demo sites - in the same fashion as D7, WordPress, and Backdrop. This means PR testing for "civicrm-drupal-8". For bug triage, it means normalized and current test builds. For release-planning and QA, the test matrices will provide test-coverage for D8 (similar to the other CMS integration tests). These services are blocked on the need for a clean process.

From a site-builder perspective: Expect the recommended template for `composer.json` to be revised. This should improve support for backports and extended security releases. Early adopters may eventually want to update their `composer.json` after this settles down; however, the details are not set in stone yet.

From a developer perspective: Expect the process for setting up `git` repos to become simpler. Instead of using the bespoke `gitify`, you'll be able to use the more common `composer install --prefer-source`.

From a code perspective: Expect changes to code/use-cases which (directly or indirectly) require auto-generated files. For example, when initializing Civi's database, the current Civi-D8 installer relies on “.mysql” files (which have been pre-generated via ”distmaker”); we can replace this with newer function calls which don't require pre-generated files -- and therefore don't depend on ”distmaker” or “setup.sh”.

Filed under

Jul 20 2019
Jul 20

For starters, over 200 Drupal 8 sites already run CiviCRM!  This post is based on my own research and conversations with those involved, and is intended to be informative and encouraging.  As you may know, CiviCRM works with no less than four CMS at the moment, including three versions of Drupal, two 'officially'.   Understandably with Drupal 7 end-of-support scheduled for Nov 2021, there has been recent discussion amongst those using or considering Drupal about which to use for your website.

  • Many Drupal shops already support and recommend Drupal 8 with CiviCRM
  • Preferred installation techniques for Drupal 8 have coalesced around the use of the Composer tool
  • Tutorials and how-tos for installation by leading experts are available

Let's back up a step...what is different about Drupal 8?  Well, Drupal 7 to Drupal 8 represents a major leap and upgrade.  Whereas Drupal 8 to 9 (and beyond) should be significantly less laborious, according to the Drupal head honcho.  The investment to jump to Drupal 8 will be offset by easier Drupal updates planned in the future.  Compatibility with CiviCRM should be similarly less laborious to maintain.

The Make it Happen fundraising campaign for Drupal 8 & Civi is currently halfway there.  But what's it for?

  • Improvements to the CiviCRM core installer for use with Composer and a clean build process
  • Funding the CiviCRM Core Team, who are already carefully considering and coordinating the sustainable architecture they will implement
  • An officially supported Drupal 8 release listed for download
  • Future maintenance

But what about other Drupal integration modules we know and love, such as Webform CiviCRM and CiviCRM Entity?  Again, great question...

  • Efforts to port these modules to Drupal 8 are already well underway, and nearing completion!
  • These modules have little to no dependency on the Drupal 8 & core CiviCRM Make it Happen effort
  • There are issue queues and sponsors for Entity and Webform. Code and financial contributions are welcome

Ok but "What do I do?" you may ask.  First off, that's a deeply individual question, depending on what your website already does and what you need it to do with CiviCRM.  But regardless it's a good idea to start this conversation right now.  Here's some food for thought:

  • Discuss with your CiviCRM consulting partner that supports Drupal.  If you are a consultant, consider a proactive chat with your clients
  • You don't need to wait for an official release, you can get started today building Drupal 8 with Civi using these tips and installation guides
  • Get involved technically and financially by supporting individual module efforts and/or the Make it Happen
  • Talk to others, ask their opinion, and get them involved.  You can find support on CiviCRM's Stack Exchange or the 'dev' and 'drupal' channels of Civi's MatterMost chat
  • You might consider another CMS for your new website that already has official CiviCRM support.  WordPress and Joomla! come to mind of course.  But it's worth mentioning Backdrop specifically in this category, due to it being a Drupal offshoot with a supposedly clean upgrade path from Drupal 7
  • Or you could wait a little bit longer...and see what happens.  Drupal 7 isn't going away at end of 2021, it's just no longer officially supported.  Third-party providers are already gearing up for long term support of Drupal 7 into 2022 and beyond.  So if you've built a behemoth with Drupal 7, you may be able to keep it active for quite some time

Hope this helps people get their heads wrapped around what's going on...comments welcome!

Filed under

May 07 2019
May 07

If your organisation uses CiviCRM with Drupal, and would like to do in the future, we need your help!

 

Over the past few years lots of amazing work has been done on the unofficial Drupal 8 CiviCRM release.
The CiviCRM core team have looked at this and are now in a position to complete the work to make this an official CiviCRM release. This means they will make changes so

  • CiviCRM can easily be installed with Drupal 8
  • They will ensure CiviCRM works with Views in Drupal 8
  • Going forward future CiviCRM releases will be tested with Drupal 8

 

What about Drupal 9? Isn't that being released soon?

Both Drupal 7 and 8 are officially supported until November 2021. But the move from Drupal 8 to Drupal 9 will not be the same as previous Drupal major updates. It will be much easier to migrate existing sites between Drupal 8 to 9. For more information see https://dri.es/drupal-7-8-and-9.

The CiviCRM core team has looked at this and the code changes required to ensure CiviCRM works with Drupal 9 should be minimal.

So very importantly this Make It Happen work is also preparation for Drupal 9.

 

If your organisation uses CiviCRM with Drupal then please contribute to this Make It Happen.

Filed under

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web