Jun 26 2019
Jun 26

by David Snopek on June 26, 2019 - 11:42am

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the Advanced Forum 6.x-2.x module to fix an Cross Site Scripting (XSS) vulnerability.

Advanced Forum builds on and enhances Drupal's core forum module.

The module doesn't sufficiently sanitise user input in specific circumstances relating to the module's default functionality. It is not possible to disable the vulnerable functionality.

This vulnerability is mitigated by the fact that an attacker must have a role with permission to create forum content.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch or the full release.

Note: This only affects Advanced Forum 6.x-2.x -- not 6.x-1.x.

If you have a Drupal 6 site using the Advanced Forum 6.x-2.x module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

May 21 2019
May 21

by David Snopek on May 21, 2019 - 9:17am

As you probably know, Drupal 6 reached its End-of-Life (EOL) on February 24th, 2016. However, the mantle of supporting Drupal 6 was taken up by the Drupal 6 Long-Term Support vendors - including the team here at myDropWizard!

Long-Term Support isn't glamorous or exciting.

It's making security releases. It's minor bug fixes. Sometimes it's updating a contrib module that hasn't had an official release since 2009 to work with PHP 7. :-)

In fact, a big part of Drupal 6 Long-Term Support (D6LTS) is updating Drupal 6 core and contrib to work with new technologies, especially as the older versions that it was originally designed to work with become deprecated or reach their own EOL, like when PHP 5 reached its EOL at the end of last year. (Did you know that Drupal 6 now works with PHP 7?)

Today, I'd like to announce that Drupal 6 supports MySQL 8, starting with Drupal 6.51!

This was implemented in collaboration with the community, largely the contributions of f1mishutka, but also a number of others who contributed testing and bug reports.

I know there's a lot of anxiety over how Drupal 7 Extended Support (D7ES) is going to work, however, I think that this is more evidence that the vendor-supported model used by D6LTS (and soon, D7ES) is working.

You can download the latest Drupal 6 LTS core release from GitHub.

May 17 2019
May 17

In my experience, a big part of making a Drupal 8 site usable for content editors is customizing the WYSIWYG, which usually includes adding a couple additional CKEditor plugins.

Of course, you can simply download the plugins into the 'libraries' folder, and that's fine. But these days, it's becoming best practice to pull in all of your site's dependencies using Composer.

Adding 'package' repositories to your composer.json for the CKEditor plugins (the current best practice) works fine - but only for your individual site.

It doesn't work so well if you want to install:

  • A Drupal "Feature" (like with the Features module) that configures the WYSIWYG, including adding some CKEditor plugins, or
  • A Drupal distribution (like Panopoly or Lightning)

In those cases, you can't depend on what the individual site may have in its top-level composer.json, and asking the user to manually copy-paste a bunch of 'package' repositories in there may create enough confusion or problems that potential users will just give up.

Well, I've got an possible solution to this problem: an experimental Composer repository which includes CKEditor plugins for use on a Drupal site.

It works better for Feature modules and distributions, but can also make life easier for individual sites too.

Read more to find out how it works and how to use it!

This all started with porting the Panopoly WYSIWYG (panopoly_wysiwyg) feature module to Drupal 8...

Panopoly WYSIWYG provides a highly usable (and re-usable!) WYSIWYG configuration, originally based on Wordpress's WYSIWYG. It's part of the Panopoly distribution, but can be used on vanilla Drupal sites, or in other distributions.

In order to work, it needs a number of CKEditor plugins. In the old world order, we used Drush .make files to pull in any necessary plugins, and this is how it still works for Drupal 7. However, with Drupal 8, this needs to be done via Composer.

We could put a requirement into panopoly_wysiwyg's composer.json, like:

    "require": {
        "drupal-ckeditor-plugin/colorbutton": "4.*"
    }

However, unless the user first added the necessary 'package' repository to their top-level composer.json, the installation will fail, because there isn't any package on Packagist called 'drupal-ckeditor-plugin/colorbutton'.

Adding those 'package' repositories would work, but it poses a number of problems...

For an individual site - nothing!

But there's a few issues for a reusable module:

  1. 'package' repository definitions are long and contain a lot of stuff. This may sound like a minor thing, but if you're asking your users to copy-paste something into their composer.json, the smaller and simpler the content can be, the harder it'll be to mess it up and lead to bad experiences and support requests. Panopoly WYSIWYG uses 6 plugins, and all the necessary 'package' repositories definitions amount to like 2 pages of text. :-)
  2. Different people may do them differently, either on purpose or accident. Since this would need to be defined in each and every site's composer.json, it can be made different. Maybe one site owner decides to pull in a different version of a plugin, or name it differently, or give it a different 'type' (to control where it goes in the code base). This creates inconsistency, which can, again, lead to bad experiences and support requests.
  3. We can't change them over time. If we find out that there was a better way to do the definition, well, then we have to tell everyone to go update their composer.json files in a specific way. Most people probably won't get the message, and it's another error prone step where the site owner could make a mistake.
  4. We can't add to them over time. Panopoly WYSIWYG currently uses 6 plugins - what if we want to add another? Well, 'composer update' will fail until the user adds the new 'package' repository to their composer.json.
  5. The plugin versions need to match the CKEditor version in Drupal core. Drupal core frequently updates the version of CKEditor in minor releases. For example, Drupal 8.6 uses CKEditor 4.10.1 and Drupal 8.7 uses CKeditor 4.11.3. If you're using a "core" CKEditor plugin (one that's bundled in the CKEditor source code) you should use the same version of the plugin as CKEditor. This means you need to update the versions in your 'package' repositories when updating to a new Drupal core minor, and creates challenges for a package like panopoly_wysiwyg that aims to work with either version.

So, in the context of a reusable feature or distribution, this is definitely not ideal.

A Composer repository is basically a remote collection of package definitions.

Packagist.org is the main Composer repository where package definitions are pulled from by default, but it's also possible to use additional repositories. For example, Drupal.org provides a Composer repository that includes all Drupal modules, themes, etc from Drupal.org.

Pointing your composer.json to an additional Composer repository, involves either (a) adding about 4 lines to your composer.json, or (b) running a single 'composer config' command.

It's easy to explain, simple to do, and hard to get wrong.

Also, since the the actual data is stored remotely, that means:

  1. Lots of people can share this same repository
  2. We can update it over time, adding or removing CKEditor plugins, or changing how they are defined
  3. We can add multiple versions of the same plugin with different requirements, for example, declaring which version of Drupal core they work with.

So, we created an experimental Composer repository with package definitions for CKEditor plugins, which is hosted on GitLab pages here:

https://panopoly.gitlab.io/drupal-ckeditor-plugins/

This is generated using satis, based on some simple configuration files stored in this GitLab repository:

https://gitlab.com/panopoly/drupal-ckeditor-plugins

Using GitLab CI, any time we commit a change to that repo, it'll regenerate the Composer repository. So, if you want to see any CKEditor plugins added or contribute to this project, please submit an MR to that project. :-)

So, while the idea for this came from wanting a better solution for Feature modules or distributions, it can also be used on an individual site to install CKEditor plugins, and it is easier than the old recommended way.

To add the repository, run this command:

composer config repositories.drupal-ckeditor-plugins composer https://panopoly.gitlab.io/drupal-ckeditor-plugins

And to install a CKEditor plugin - for example, the 'colorbutton' plugin - run this command:

composer require drupal-ckeditor-plugin/colorbutton:4.*

This will put the right plugin version for your version of Drupal core into your 'libraries' folder, and you didn't have to manually edit your composer.json at all.

And, if you update your Drupal core version, composer will know that you also need to update your CKEditor plugins to match.

To use with a Feature module or distribution, you need to do only two things:

  1. Add a requirement on a CKEditor plugin from the repository, like "drupal-ckeditor-plugin/colorbutton" (for the 'colorbutton' plugin, for example)
  2. Tell your users to run this command before installing your module or distribution:
composer config repositories.drupal-ckeditor-plugins composer https://panopoly.gitlab.io/drupal-ckeditor-plugins

Optionally, if you provide a Composer project template for starting new sites (like the panopoly-composer-template), you can add the repository to that composer.json, so that new users don't need to follow any steps at all!

Every time I've referred to this Composer repository above, I've called it "experimental".

This is because, while this seems to work, we haven't really used it in practice yet. After spending some weeks or months using this with real modules and sites, we may find out that there was a better solution.

So, while I really encourage you to try it out, please know that this is the early stages, and doesn't (yet) change any of the best practices.

However, I will say that I don't ever intend to take this down.

It's hosted on GitLab Pages, so as long as GitLab.com continues to exist, this Composer repository will also exist. So, if you start to depend on it, it isn't going to go away.

But, just a warning: at some point, it could become deprecated if a better solution to these problems is found.

Please let me know your thoughts in the comments below or in issues/MRs for the project on GitLab!

May 08 2019
May 08

by David Snopek on May 8, 2019 - 12:31pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for Drupal core to fix a vulnerability in the protections added in SA-CORE-2019-003. You can learn more in the security advisory:

Drupal core - Moderately Critical - Third-party Libraries - SA-CORE-2019-007

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Apr 17 2019
Apr 17

by David Snopek on April 17, 2019 - 4:00pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for Drupal core to fix a vulnerability in jQuery. You can learn more in the security advisory:

Drupal core - Moderately Critical - Third-party Libraries - SA-CORE-2019-006

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

FYI, there was another Drupal core security release made today (SA-CORE-2019-005) but that one doesn't affect Drupal 6, because Drupal 6 doesn't depend on Symfony.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Apr 02 2019
Apr 02

by David Snopek on April 2, 2019 - 11:59am

When we originally announced that we'd be providing Drupal 6 Long-Term Support, we committed to supporting our customers until at least February 2017.

Each year in the spring, we've taken a look at the state of Drupal 6 and decided whether we'll extend support for another year, and if we need to make any changes to our offering. Here's the articles from 20162017, and 2018 where we announced an additional year each time and any new concerns (for example, PHP 7 support).

Today, we're announcing that we'll be extending our Drupal 6 Long-Term Support two more years until at least February 2022!

I'm sure there will come a time, when it no longer makes business sense to pour resources into Drupal 6 for the few remaining sites, however, it's already clear to us that there's enough demand for a couple more years.

Also, now that we know when Drupal 7 will reach it's End-of-Life, we've started to plan for that, and decided that we'd like D6LTS to last at least until then (which is why we're announcing an additional 2 years this time, rather than just 1).

Regarding Drupal 7: we've officially applied to be a Drupal 7 Extended Support vendor and have been accepted. :-)

Read on to find out more!

Why February 24th, 2022?

Well, we've been using the February 24th date, because Drupal 6 orginally reached it's End-of-Life on February 24th, 2016, and we've been taking it one year at a time.

We recently learned that Drupal 7's End-of-Life will be in November 2021.

We want Drupal 6 LTS to continue at least through Drupal 7's community support so... the following February 24th it is!

Since we've been able to extend so many times it's entirely possible we'll extend it again past 2022, but no promises at this point. (See the last section in this article for our reasons why...)

There's still TONS to do Drupal 6

While it can be a little hard to predict the challenges that Drupal 6 site owners will face in the future, don't worry - I'm sure there will be plenty to do. :-)

This past year included a focus on adding PHP 7.2 support. Given that 7.2 will reach it's End-of-Life in November 2020, we'll certainly be adding support for PHP 7.3 and 7.4.

Also, hosting providers and Linux distributions have started bundling MySQL 8, which also requires updates to Drupal 6 core and contrib modules. A community contributor has been leading the effort on that.

And, of course, we'll continue doing security releases and the occasional bug fix. :-)

A couple months ago, I wrote that we'd made 99 D6LTS releases up until that point - we're already up to 113.

In fact, rather than dwindling away with time, there's more to do for Drupal 6 than ever!

What are your plans for Drupal 7?

Recently, things have been coming into focus for Drupal 7's End-of-Life and the Drupal 7 Extended Support (D7ES) program.

Compared with the Drupal 6 Long-Term Support (D6LTS) program, there's a lot more information that's known further in advance, as well as quite a few more rules and requirements for vendors looking to participate in the program.

You can see the full details of the D7ES program in this PSA from the Drupal Security Team.

We still don't know the full details of our offering, but we can say this:

  • It will be very similar to our D6LTS offer
  • We'll be providing Drupal 7 support until at least November 2024, because vendors are required to participate for at least 3 years

More details will come as we get closer to Drupal 7's EOL!

Will you support Drupal 6 forever?

While some of customers would love if we'd support Drupal 6 forever, the answer is "no."

Our service is billed at a relatively low fixed monthly fee, so it depends on a certain amount of scale and overlap between our customers needs in order to be profitable.

This is great for our customers because they pay less than they'd probably pay hourly for individual services just for their site, by "sharing the load" with other customers with similar needs! But it also means that when enough of our customers quit or upgrade to being Drupal 7 or 8 maintenance and support customers, providing Drupal 6 LTS will be a loss for us.

When that happens (and it inevitably will), then we'll have to either (a) charge higher prices to make up the difference or (b) stop providing Drupal 6 LTS.

But don't worry - we'll let you know long in advance of when that is coming!

In the spring of 2021, we'll be announcing any changes to our Drupal 6 LTS offering, including:

  • Whether or not we'll be extending Drupal 6 support,
  • If there will be any changes to the price or service offered,
  • And if we have any special offers to help upgrade the remaining Drupal 6 sites

But for the time-being, you can expect our Drupal 6 LTS to last until February 24th, 2022!

Mar 20 2019
Mar 20

by David Snopek on March 20, 2019 - 4:43pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for Drupal core to fix a Cross Site Scripting (XSS) vulnerability.

Folks have been asking us, so this is just a short note to say that this issue does NOT affect Drupal 6. So, you can focus just on updating your Drupal 7 and Drupal 8 sites today. :-)

Thanks!

Mar 13 2019
Mar 13

by David Snopek on March 13, 2019 - 1:36pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Less Critical security release for the Views 6.x-3.x module to fix an Cross Site Scripting (XSS) vulnerability.

This module enables you to create customized lists of data.

The module doesn't sufficiently sanitize certain field types, leading to a Cross Site Scripting (XSS) vulnerability.

This vulnerability is mitigated by the fact that a view must display a field with the format "Full data (serialized)" and an attacker must have the ability to store malicious markup in that field.

See the security advisory for Drupal 7 for more information.

Note: There are two other security advisories that were published today for Views on Drupal 7, but they don't affect Drupal 6.

Here you can download the Drupal 6 patch or the full release.

Note: This only affects Views 6.x-3.x -- not 6.x-2.x.

If you have a Drupal 6 site using the Views 6.x-3.x module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Mar 06 2019
Mar 06

by David Snopek on March 6, 2019 - 1:56pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the EU Cookie Compliance module to fix an Cross Site Scripting (XSS) vulnerability.

The module provides a banner where you can gather consent from the user when the website stores cookies.

The module doesn't sufficiently sanitize data for some interface labels and strings shown in the cookie policy banner.

This vulnerability is mitigated by the fact that an attacker must have a role with the permission "Administer EU Cookie Compliance banner".

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch or the full release.

If you have a Drupal 6 site using the EU Cookie Compliance module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Mar 06 2019
Mar 06

by David Snopek on March 6, 2019 - 1:51pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Ubercart module to fix a CSRF vulnerability.

The Ubercart module provides a shopping cart and e-commerce features for Drupal.

The taxes module doesn't sufficiently protect the tax rate cloning feature.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch or the full release.

If you have a Drupal 6 site using the Ubercart module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Feb 27 2019
Feb 27

by David Snopek on February 27, 2019 - 12:54pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Context module to fix an Open Redirect vulnerability.

The context module enables site builders to setup conditions and reactions for different parts of the site.

The module doesn't sufficiently sanitize user output when displayed leading to a Cross Site Scripting (XSS) vulnerability.

This vulnerability is mitigated by the fact that an attacker must have the ability to store malicious markup in the site (e.g. permission to create a node with a field that accepts "filtered html").

See the security advisory for Drupal 7 for more information.

Here you can download:

If you have a Drupal 6 site using the Context module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Feb 20 2019
Feb 20

by David Snopek on February 20, 2019 - 2:21pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the Link module to fix a Remote Code Execution (RCE) vulnerability.

The Link module provides a field for storing links.

The module didn't properly validate the field data.

This is mitigated by the fact that the issue is only known to be exploitable via the Services module.

See the core security advisory for Drupal 7 & 8 for more information. Drupal 6 core is not affected, only the Link module.

Here you can download the Drupal 6 patch or the full release.

If you have a Drupal 6 site using the Link module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Feb 12 2019
Feb 12

One the most popular articles on our blog is an article I wrote a year and half ago about how to install CiviCRM on Drupal 8.

The method described there worked (and still more-or-less works), but it's... a mess.

It involves running a dozen or so commands, and is pretty easy to get wrong. All of this is just to get code assembled in such a way that you CAN install it.

I'm happy to announce that you can now do this in just a single command!

There's still some little issues and bugs with running CiviCRM on Drupal 8 that need to be manually worked around, but getting over that first hurdle of simply allowing you to install it in the first place should be significantly easier with this new method.

Read the full article to find out how!

Background: Why is this hard?

The biggest problem is that both Drupal 8 and CiviCRM depend on some of the same PHP libraries, for example, Symfony.

In PHP, you can't define the same class twice (this would be a fatal error) and you certainly can't define the same class twice at two different versions (for example, one version for Drupal and one for CiviCRM).

So, you couldn't just copy CiviCRM with all its dependencies into an instance of Drupal, because some of those dependencies would conflict with what's already in Drupal.

And, unfortunately, you couldn't just make a special CiviCRM bundle that's "optimized" for a particular version of Drupal 8, because each Drupal 8 site is potentially unique: you can update the PHP libraries used by a Drupal 8 site (for example, upgrading Symfony to a newer version) or add new PHP libraries that could conflict.

The Magic of Composer

Composer is a tool that's used by PHP applications and libraries to find and download a compatible set of dependencies.

For example, CiviCRM needs Symfony 2 (version 2.8.44 or greater) or any version of Symfony 3. Drupal 8.6.9 needs Symfony 3.4 (version 3.4.14 or newer), although, soon it will be possible to use Drupal 8 with Symfony 4 as well.

Using composer, you can say, "I need Drupal 8.6.9 and CiviCRM 5.10.0" and it can pull in a version of Symfony that works for both.

If your Drupal site used Symfony 4 (because some Drupal module needed it), it would error out and say you need to either remove that module (so Symfony can be downgraded to Symfony 3) or remove CiviCRM.

That's why composer is so heavily involved in getting Drupal and CiviCRM to work together!

The peculiarities of CiviCRM

Of course, that's not the whole problem, because otherwise it would have been possible to solve this with a single composer command years ago.

CiviCRM has been around for over a decade (which is a lifetime ago in the PHP ecosystem), and still has some legacy pecularilies that need to be accounted for..

Namely, CiviCRM depends on going through a non-composer-y build process to generate a "release" that is actually usable.

Some of those things that need a build process could be reworked in a way so that they didn't need it, and others could be done in a composer-compatible way, such that CiviCRM would work like any composer library. Work is being done on that, but those are hard problems which will take time to solve.

TL;DR - What are the commands?

Heh, alright! Time for the actual actionable steps. :-)

First, you need to have the following installed:

And, make sure that you have a recent version of Composer! A couple of people have tried to use this process with older versions and have experienced issues. (In general, you shouldn't be using a composer that's older that 90 days - the Composer eco-system evolves quickly!)

Then, to create a new Drupal 8 site with CiviCRM:

# replace 'some-dir' with the directory to create
composer create-project roundearth/drupal-civicrm-project:8.x-dev some-dir --no-interaction

Or, to add to an existing Drupal 8 site (assuming you used the best practice method of starting from the drupal-project composer template):

composer require roundearth/civicrm-composer-plugin civicrm/civicrm-drupal-8

If you have a Drupal 8 site that isn't based on the drupal-project composer template, well, you're going to need to convert your site.

I'd recommend creating a new codebase (using the 'composer create-project' command above), adding all the modules/themes/libraries from the old codebase, and then switching the site to the new codebase. Assuming you didn't forget to copy anything over, that should work, but definitely keep a backup.

Installing CiviCRM

Once you have the code in place using the commands above, you'll actually need to install CiviCRM. Due to some bugs in CiviCRM for Drupal 8, there's a bunch of caveats and extra steps associated with that.

I've documented some of the steps on the project page for 'roundearth/drupal-civicrm-project':

https://gitlab.com/roundearth/drupal-civicrm-project#installing-civicrm

Hopefully, all these bugs will be fixed in time.

The good news is that the composer project template will always pull in the latest versions of CiviCRM and its Drupal 8 integration, so these steps should be able to remain the same, and will just start working better as those bugs get fixed. :-)

How does it work?

There are two parts to this:

It does the following:

  1. Run's Bower to pull in Javascript and CSS dependencies
  2. Downloads a release of CiviCRM and copies in the missing files generated by the usual build process
  3. Downloads any requested CiviCRM extensions
  4. Copies any web assets from CiviCRM (which is installed in the vendor directory, which isn't web accessible) into the web root

In case you're curious, or want to help improve it, here's where all the most interesting code lives:

https://gitlab.com/roundearth/civicrm-composer-plugin/blob/master/src/Handler.php

Conclusion

One of the main challenges in improving CiviCRM on Drupal 8, is just getting it installed for developers who might want to help.

We've been involved in the effort to port the Webform CiviCRM module to Drupal 8, which has also faced this same challenge.

That's why a small part of the development of this new method was funded via the donations that were made to that effort. The rest was just part of our efforts in maintaining Roundearth, a Drupal 8 and CiviCRM platform for non-profits.

We're hoping this will help, not only with getting CiviCRM installed on Drupal 8, but also help to accelerate development. :-)

Feb 06 2019
Feb 06

by David Snopek on February 6, 2019 - 1:04pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Less Critical security release for the Public Download Count  module to fix an Open Redirect vulnerability.

Public Download Count keeps track of file download counts, even for public files.

The module did not verify that the links provided to the intermediate page were actually present in the Drupal site content.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch or the full release.

If you have a Drupal 6 site using the Public Download Count module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Jan 16 2019
Jan 16

by David Snopek on January 16, 2019 - 12:47pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for Drupal core to fix a Remote Code Execution (RCE) vulnerability. You can learn more in the security advisory:

Drupal core - Critical - Multiple Vulnerabilities - SA-CORE-2019-002

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

FYI, there was another Drupal core security release made today (SA-CORE-2019-001) but that one doesn't affect Drupal 6, because Drupal 6 doesn't bundle the Archive_Tar library. However, that vulnerability may affect custom or contrib modules on your site.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Jan 03 2019
Jan 03

by David Snopek on January 3, 2019 - 12:34am

As you may or may not know, we've been providing Drupal 6 Long-Term Support (D6LTS) since February 24, 2016, as one of two vendors officially blessed by the Drupal Security Team to do so.

In that time, we have made 99 releases (both Drupal core and contrib) for D6LTS!

Most of those were security releases, but there were also a handful of bug fixes, and most recently, updates to support PHP 7.2. (FYI: As of a couple days ago, PHP 5 has also reached it's End-of-Life (EOL) - do you have a plan to update to PHP 7.1 or 7.2?)

When we were first talking to potential customers about D6LTS, I remember many people doubting that we'd be releasing anything at all!

They'd say something like "Drupal 6 has been around so long, aren't all the security issues shaken out by now?" Almost 100 releases later, and I'd say there was plenty to be done. There still is! :-)

In this article, I'm going to look back on Drupal 6 LTS, and also look forward to what that may mean for Drupal 7 extended support after it reaches its End-of-Life.

Lessons learned from Drupal 6 LTS

We learned many unexpected things from doing Drupal 6 Long-Term support over the last few years, which I suspect will continue to apply to Drupal 7's extended support.

The age/visibility of the code doesn't matter

This should have been obvious by looking at other Open Source projects. Many of the recent vulnerabilities found in OpenSSH (a hugely visible project, used by almost every Linux server on the planet) were introduced many years before anyone noticed (in one case, it took almost 20 years).

So, it doesn't matter that Drupal 6.0 was released almost 11 years ago - odds are, there are still some security vulnerabilities in there.

Looking at the projects we released the security updates for, the most common were also the most widely used, for example:

  • Drupal core: 4 security releases
  • views: 4 security releases
  • xmlsitemap: 2 security releases

These highly popular projects have gotten the most scrutiny, but that hasn't meant there aren't more issues to find.

This is especially true of Drupal core, which is independently audited several times a year by security companies hired by large organizations to evaluate their sites. (BTW, this is a great source of security issues reported to the Drupal Security Team.)

I suspect this will continue to be true for Drupal 6 and Drupal 7: we'll keep finding security issues for years to come.

Many issues affected Drupal 6, 7 & 8

Despite the fact that each major version of Drupal up to this point included breaking changes, and Drupal 8 could almost be considered a "rewrite", many security issues affected Drupal 6, 7 and 8, both in Drupal core and contrib.

In the case of the Highly Critical SA-CORE-2018-002, which came out in the Spring of 2018, all three versions (6, 7 & 8) - and even Drupal 5 - were affected!

The code fixes for each version of Drupal were quite different in some of these cases, but the shared history, and the test-driven of evolution of Drupal 7 into Drupal 8 has meant that many bugs (including security bugs) have been preserved.

Even as we move towards Drupal 9 (which is removing and re-organizing even more legacy code), I suspect we'll continue to see security issues in Drupal 9 or 10 that also affect Drupal 6 or 7.

Keeping up with PHP is going to be a thing

After PHP 5.3, there was a relatively long period where not that many breaking changes were introduced to PHP -- so long as you stayed with PHP 5. But now that PHP 5 has reached its End-of-Life, you can't stay on PHP 5 any longer.

PHP 7 has also entered into a regularly scheduled cycle of releases, and each release is making more aggressive deprecations and breaking changes. Many Drupal projects are just switching to PHP 7 now, but at some point PHP 8 will be released and remove all those deprecated features.

Keeping up with changes to PHP is going to be a thing that we'll have to constantly think about now -- in Drupal development in general, but especially for any Long-Term Support effort, whether that's Drupal 6 or 7.

As we've mentioned previously, we plan to offer commercial support for Drupal 7 after its End-of-Life, that will be very similar to what we've done for D6LTS.

And, as per the lessons above, we also expect that extended support will be essential for anyone who intends to remain on Drupal 7 after its End-of-Life!

The most important difference this time around is that Drupal 7's End-of-Life has been announced years in advance. This a huge change from the Drupal 6 EOL, which was "coming any day now" (along with Drupal 8) for 2-3 years, and then happened suddenly with only 3 extra months of support.

So, you have a lot more time to plan, but also, you have something concrete to plan for: Drupal 9 will be out for a year before Drupal 7's EOL, and intention is for the upgrade from Drupal 8 to 9 to much easier than previous major version upgrades - on par with upgrading from Drupal 8.5 to 8.6 (well... hopefully ;-)).

That said, if you do wish to stay on Drupal 7 for some time after its End-of-Life... I think D6LTS has shown that commercial extended support can work, and what that will probably look like.

Dec 05 2018
Dec 05

by David Snopek on December 5, 2018 - 1:59pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Less Critical security release for the Password Policy  module to fix a Denial of Service (DoS) vulnerability.

The Password Policy module makes it possible to set constraints on user passwords.

The "digit placement" constraint is vulnerable to Denial of Service attacks if an attacker submits specially crafted passwords.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Password Policy module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Oct 31 2018
Oct 31

by David Snopek on October 31, 2018 - 1:28pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the Session Limit module to fix a Insecure Session Management vulnerability.

The session limit module enables a site administrator to set a policy around the number of active sessions users of the site may have.

The module does not sufficiently tokenise the list of sessions so that the user's session keys can be found through inspection of the form.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Session Limit module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Oct 18 2018
Oct 18

by David Snopek on October 17, 2018 - 11:55pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Search Autocomplete module to fix a Cross Site Scripting (XSS) vulnerability.

This Search Autocomplete module enables you to autocomplete textfield using data from your website.

The module doesn't sufficiently filter user-entered text among the autocompletion items leading to an XSS vulnerability.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

Note: We only support the 6.x-2.x branch (we don't have any customers on the 6.x-4.x branch), so that's the only one we're going to do.

If you have a Drupal 6 site using the Search Autocomplete module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Oct 17 2018
Oct 17

by David Snopek on October 17, 2018 - 6:17pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for Drupal core to fix multiple vulnerabilities. You can learn more in the security advisory:

Drupal core - Critical - Multiple Vulnerabilities - SA-CORE-2018-006

The following vulnerabilities mentioned in the security advisory also affect Drupal 6:

The first vulnerability is in Drupal 6 core, however, the 2nd is only present in the contrib modules: htmlmail, and mimemail. If you don't use those modules, you're not affected by the 2nd vulnerability.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Oct 10 2018
Oct 10

by David Snopek on October 10, 2018 - 12:40pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the Lightbox2  module to fix a Cross Site Scripting (XSS) vulnerability.

The Lightbox2 module enables you to overlay images on the current page.

The module did not sanitize some inputs when used in combination with a custom View leading to potential XSS.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Lightbox2 module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Oct 08 2018
Oct 08

by David Snopek on October 8, 2018 - 4:45pm

If you haven't heard yet, PHP 5 will reach the end of its security support (from the upstream project) in December of this year.

During DrupalCon Baltimore we announced that we'd be updating Drupal 6 to work with PHP 7.2, and, in September, we announced that we'd be making a big push to get that live with a couple of our customers.

Finally, we have something to show for it! :-)

So far, we've only tested with a few sites, so I'm sure there's some additional issues and bugs we haven't encountered yet. But we have an initial release of Drupal core and some selected contrib modules that work with PHP 7.2 in our testing.

And all our work so far has been released back to the community!

Read more for the details :-)

Drupal core

The short version: We've released Drupal 6.45 with support for PHP 7.2

We've taken a particular approach with this:

  • We included a shim for the ereg() family of functions that were removed, rather than converting core to using preg_*() functions. This was done because contrib also uses those removed functions and this saves us from having to update many contrib modules.
  • In one or two cases, we modified Drupal core to maintain the PHP 5 behavior of its APIs if that behavior was depended on by "a lot" (subjective judgement) of contrib modules, again in order to have to update fewer contrib.
  • We made most of the updates recommended by the PHPCompatibility standard for phpcs
  • We tried to retain (and tested for) PHP 5.2+ compatibility, so that our Drupal core fork would continue to work for people who haven't updated yet. (If you're not aware of it, 3v4l.org is a great tool for trying PHP snippets in lots of versions of PHP at once, and, well, we have a bunch of different PHP versions via Docker too.)
  • But otherwise, we've based our changes on actual manual testing and confirmed bugs, and tried to make the smallest possible change to fix each problem.

Important security note!

Drupal adds a .htaccess file to the public (ie. sites/default/files/) and temporary files directory to prevent PHP files that somehow end up there from being executable when using Apache.

However, this .htaccess file won't work with PHP 7 unless modified!

One way to do this, is to delete the .htaccess files and then visit the "Status report" on your site, which will re-create the file with the changes necessary for PHP 7.

We've considered adding an update hook to do this, but we're worried about wiping out any added changes - see the issue on GitHub and leave your thoughts.

Drush

You need a patched Drush 8 in order to work with PHP 7. See drush-ops/drush#3706 and you can grab the patch here.

The Drush maintainers seem open to committing this patch, so hopefully, this will make it into a Drush 8 release at some point. :-)

Selected contrib modules

Of course, the true power of Drupal is in it's contributed modules!

We're committed to updating the contrib modules used by our D6LTS customer to work with PHP 7.2.

That said, updating contrib (especially complex contrib) is a lot harder than Drupal core, so we expect this process to take us all the way to the end of the year.

Here's the contrib releases we've made so far:

There's also a number of contrib modules (generally the simpler ones) that work fine without any changes.

How to get involved!

If you're also working on getting your Drupal 6 site working on PHP 7, and you find any issues or bugs, you can write an issue on the project on GitHub or in the D6LTS queue on Drupal.org. We appreciate the help and a number of people have contributed already - thanks! :-)

Or if you're interested in us doing this for you...

Sign up for Drupal 6 Long-Term Support!

Have you updated your Drupal site to PHP 7 already? How'd that go? Please leave a comment below!

Oct 03 2018
Oct 03

by David Snopek on October 3, 2018 - 4:30pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the Print module to fix a Remote Code Execution (RCE) vulnerability.

The Print module provides printer-friendly versions of content, including send by e-mail and PDF versions.

The module doesn't sufficiently sanitize the arguments passed to the wkhtmltopdf executable, or HTML passed to dompdf or other PDF generation tools.

See the security advisory for Drupal 7 for more information.

NOTE: This vulnerability has a lower risk in Drupal 6 than in Drupal 7 (where it's Highly Critical). This is because you can't pass shell commands to execute using the HTTP basic auth user/pass, like you can in Drupal 7.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Print module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Jul 18 2018
Jul 18

by David Snopek on July 18, 2018 - 2:42pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the XML sitemap module (version 6.x-2.x only) to fix an Information Disclosure vulnerability.

The XML sitemap module enables you to generate XML sitemaps and it helps search engines to more intelligently crawl a website and keep their results up to date.

The module doesn't sufficiently handle access rights under the scenario of updating contents from cron execution.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the XML sitemap module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Jun 27 2018
Jun 27

by David Snopek on June 27, 2018 - 2:06pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Less Critical security release for the Generate Password module to fix an Insecure Randomness vulnerability.

The Generate Password modules allows administrators to create a new user account without setting a password, allowing the system to automatically generate one. The module doesn't use a strong source of randomness, creating weak and predictable passwords.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Generate Password module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Apr 25 2018
Apr 25

by David Snopek on April 25, 2018 - 11:53am

Today, there is a Critical security release for Drupal core to fix a Remote Code Execution (RCE) vulnerability. You can learn more in the security advisory:

Drupal core - Critical - Remote Code Execution - SA-CORE-2018-004

This issue also affects Drupal 6 (although, less severely than Drupal 7 or 8). So, we're also making a Drupal 6 Long-Term Support (D6LTS) release of Drupal core and the Filefield module.

Drupal 6 core security update

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

This fix is both for Drupal 6 core and the Filefield module. This is because the Drupal 7 & 8 fixes include changes to the core 'file' module, which isn't in Drupal 6 core, but an equivalent fix applies to the Filefield module.

Here you can download:

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install security updates for contrib modules (even though they won't necessarily have a release on Drupal.org).

Mar 29 2018
Mar 29

by David Snopek on March 29, 2018 - 12:02am

Drupal 6 reached End-of-Life over 2 years ago, so you might be forgiven for thinking that Drupal 6 and its Long-Term Support (D6LTS) no longer matter.

However, yesterday (March 28th, 2018), there was a HIGHLY CRITICAL security vulnerability announced that affected Drupal 6, 7 & 8 (and even Backdrop).

This wasn't the first Drupal 6 LTS core release (did anyone notice that one?) and it probably won't be the last. And there are still ~65,000 sites running Drupal 6 according to Drupal.org, which were affected by this issue, and could be affected by future issues.

Luckily, the Drupal 6 LTS program is still going, and we got a patch and release out immediately!

But the D6LTS program won't go on forever... at least without users of Drupal 6 continuing to buy support from the D6LTS vendors.

I think this is a good time to remind everyone what the D6LTS program is and why it's still important to the Drupal community...

Just how critical was yesterday's release?

Yesterday's release fixed a Remote Code Execution (RCE) vulnerability. That means an attacker could execute arbitrary PHP code on a vulnerable site. This includes the ability to execute shell commands or run arbitrary SQL.

While it's not as easy to exploit as Drupalgeddon - that one was listed as TD:All, or "All module configurations are exploitable", where as this vulnerabliity is listed as TD:Default, or "Default or common module configurations are exploitable" - it's likely that many or most sites are vulnerable.

(BTW, see our article on how to understand the risk calculator!)

So, like Drupalgeddon, this is the sort of vulnerability that needs to be patched IMMEDIATELY in order to beat the attackers that are trying to weaponize it, and start crawling the internet for vulnerable Drupal sites.

This is EXACTLY the sort of vulnerability that we were all worried about when the D6LTS program was first concieved of!

What is the D6LTS program?

Back in 2015, the Drupal Security Team announced the D6LTS program and asked vendors to apply to participate.

Participation means getting access to the private Drupal Security Team tracker, in order to watch for security issues that could also affect Drupal 6, and develop patches for them before the security issues are made public.

In exchange, the D6LTS vendors had to agree to:

  • Make all security patches/releases publicly available (ie. we can't keep them only for our customers)
  • Refrain from making security patches/releases public before the related D7 or D8 releases are published (ie. we can't share them with our customers early)

So, this means that we were able to work on getting a fix ready for this big security release BEFORE it was public. This is good because you want to release a fix fast, but you don't want to rush it: it could cause regressions or fail to fully address the vulnerability or even introduce new security isssues.

But it also means the whole Drupal community (not just D6LTS customers) gets to benefit from the patches the D6LTS vendors create!

Why not just wait for the patches, like, for free?

While the D6LTS vendors release the patches to everyone, we're creating them for our customers, who have specifically signed for a D6LTS plan.

So, we'll only release D6LTS patches for modules that our customers use! If you have a Drupal 6 site which uses other modules, you could end up being vulnerable.

To make things easier for our customers AND the community, we created the myDropWizard module, which will tell you if your modules are supported and if there's any D6LTS security releases for them. This available to everyone, even folks who aren't our customers.

So, you can just wait for the patches for free - we even make it easy for you with the myDropWizard module - but...

The D6LTS program won't go on forever!

While we love the Drupal community, and want to make things easier for people who are stuck on Drupal 6, it takes significant resources to provide D6LTS.

We can only do this so long as it is financially viable for us to do it!

There were 3 vendors originally accepted into the D6LTS program: us (myDropWizard), Tag1 and Acquia.

Acquia was already stopped its participation in the Drupal 6 LTS program. And they have many more resources than us, and several of the original Drupal 6 core maintainers on staff. :-)

At our height, we were providing D6LTS for over 400 sites. We're currently only supporting a small fraction of that!

People are quitting every month as they migrate their sites. Once enough people quit, we won't be able to do it anymore, or will need to dramatically increase our prices.

So, if you have a Drupal 6 site that you depend on, and want to continue getting security updates for it, please sign up for a D6LTS plan!

D6LTS until 2020?

We've currently committed to doing Drupal 6 LTS until at least February 24th, 2019.

Usually, around Drupalcon we announce whether or not we're going to continue doing it for another year, and if there's going to be any price changes. We're in the middle of making that decision right now!

Remember: all the patches we make don't just go to our customers, they are shared with the whole Drupal community.

If you want to continue see these Drupal 6 security releases, please consider signing up for a D6LTS plan!

Mar 28 2018
Mar 28

by David Snopek on March 28, 2018 - 2:25pm

Today, there is a Highly Critical security release for Drupal core to fix a Remote Code Execution (RCE) vulnerability. You can learn more in the security advisory:

Drupal core - Critical - Remote Code Execution - SA-CORE-2018-002

As we noted last week, this issue also affects Drupal 6! So, we're also making a Drupal 6 Long-Term Support (D6LTS) release of Drupal core.

Drupal 6 core security update

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install security updates for contrib modules (even though they won't necessarily have a release on Drupal.org).

Feb 21 2018
Feb 21

by David Snopek on February 21, 2018 - 12:37pm

Today, there is a Critical security release for Drupal core to fix multiple vulnerabilities. You can learn more in the security advisory:

Drupal core - Critical - Multiple Vulnerabilities - SA-CORE-2018-001

What makes this release special, is that some of these issues also affect Drupal 6! So, we're also making a Drupal 6 Long-Term Support (D6LTS) release of Drupal core.

Drupal 6 core security update

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

The following vulnerabilities mentioned in the security advisory affect Drupal 6:

  • JavaScript cross-site scripting prevention is incomplete - Critical

  • jQuery vulnerability with untrusted domains - Moderately Critical

  • External link injection on 404 pages when linking to the current page - Less Critical

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Feb 14 2018
Feb 14

by David Snopek on February 14, 2018 - 4:57pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Custom Permissions module to fix an Access Bypass vulnerability.

This module enables the user to set custom permissions per path.

The module doesn't perform sufficient checks on paths with dynamic arguments (like "node/1" or "user/2"), thereby allowing the site administrator to save custom permissions for paths that won't be protected. This could lead to an access bypass vulnerability if the site is relying on the Custom Permissions module to protect those paths.

After applying this patch, go to the "Site Configuration Permissions" page and click "Save". If the form saves without errors, your site isn't vulnerable. If you get an error, delete the permission or correct the patch per the information in the error.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Custom Permissions module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Feb 07 2018
Feb 07

by David Snopek on February 7, 2018 - 2:23pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the FileField Sources module to fix an Access Bypass vulnerability.

This module enables you to upload files to fields via several sources.

The module doesn't sufficiently handle access control on the autocomplete for reference sources.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the FileField Sources module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Jan 24 2018
Jan 24

by David Snopek on January 24, 2018 - 1:20pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, a security update for the Backup and Migrate module for Drupal 7 was released for a Critical issue that could allow arbitrary PHP execution - see the security advisory.

While arbitrary PHP execution is scary, this issue is actually about the permissions provided by the Backup and Migrate module not being marked as potentially dangerous. The new release simply marks those permissions appropriately.

There won't be a security release for this issue for Drupal 6!

This is because Drupal 6 doesn't provide a way to mark permissions as dangerous. It doesn't even allow a separate description for the permissions, which we could use to call out the danger (the machine name used in code is the same as the name shown to users - this is no longer the case in Drupal 7 and newer).

However, marking the permissions as dangerous isn't the real fix! The real fix is auditing your permissions to "verify only trusted users are granted permissions defined by the module."

This is something you can do with Drupal 6, even without a new release. :-)

So, in summary: no security release for Drupal 6 - go audit your permissions.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Jan 17 2018
Jan 17

by David Snopek on January 17, 2018 - 10:21am

One of the great things about Drupal, is that it's possible to build a pretty advanced site just by pointing and clicking and configuring things - what we call "site building" in the Drupal universe.

But with all that power, you can also make your Drupal site less secure - and possible to hack! - just by changing configuration settings! We covered other examples of this in a previous article.

Today we're going to talk about one of the most common... and most DANGEROUS: exposing your Drupal private files on the internet.

In this article we're going to discuss how to determine if your private files have been exposed, and also how to fix it.

Read more to find out!

What are Drupal "private files"?

On all Drupal sites, there are at least two different types of files: public and private.

Public files are served directly by the web server, which is nice because it's fast. Private files have to pass through Drupal, which is slower, but allows Drupal to define the rules to access them.

Private files are usually used for either:

  1. User uploaded content you want to control access to (ex. a newsletter than only site members should be able to see), or
  2. Files created by Drupal modules which they intend to keep private, usually for security reasons

You probably know if you have #1, but you might not know if you have #2 if you don't know how all the modules on your site work.

So, even if you're not using private files to power a feature of your site, a module that you use may be using them unbeknownst to you! Because of that, it's always important to make sure your private files aren't being exposed to the internet.

How does Drupal keep private files private?

Public files have to be placed in your public "web root" along with the other files that make up your Drupal site, so that the web server can serve them.

Private files should either:

  1. Be placed outside the web root, where the web server can't get to them, or
  2. If they are in the web root, you need to configure your webserver not to serve them

#1 will always be safe!

It's #2 where things can go wrong. Frequently, private files are placed within the web root (ex. under "sites/default/files/private") but without changing the web server configuration to prevent directly accessing them, and skipping Drupal altogether.

How to find out if they are exposed?

This is pretty easy to check manually, but does require a little bit of Drupal and technical know how:

  1. Login to your Drupal site as an admin user
  2. Go to Configuration -> Media -> File system
  3. Check the "Private file system path"
  4. If you it might be in the web root, then place a file at the given path (probably will require using FTP or SSH to transfer a file to the live server) and then try to access it with your web browser. For example, if your "Private file system path" is "sites/default/files/private" then upload a "test.txt" file and try to access it at http://example.com/sites/default/files/private/test.txt
  5. If you can access the file directly - then your private files are exposed to the internet!

Since that involves messing around with FTP or SSH, an easier way may be installing the Security Review module and running its report. It'll find exposed private files as well as a number of other potential security issues with your site!

How to fix it?

The safest thing you can do is to move your private files directory outside the web root. If your site is at the top-level of your domain, an easy option can be putting the private files at a directory above the web root.

For example, if you login to Drupal by going to http://example.com/user/login as opposed to some prefix directory like http://example.com/drupal/user/login, then you know that your site is at the top-level of your domain, so there shouldn't be any way to access files in the directory above it.

Here's the process:

  1. Use FTP or SSH to move the private files directory to a "sibling" directory to your Drupal root, for example, called "private"
  2. Login to your Drupal site as an admin user
  3. Go to Configuration -> Media -> File system
  4. Change the "Private file system path" to a path relative to the Drupal root, starting with "..", for example, "../private"
  5. Click "Save configuration"

An alternative to this is changing the configuration of your web server to block access to files in the private files directory, but that can be tricky - it depends on your specific web server (Apache, nginx, IIS) and configuration. So, we're not going to go into that today - that could be the topic for a whole new post. :-)

Conclusion

If you have a Drupal site, you need to make sure that your private files are secure - even if you think you don't have any private data on your site, you could be surprised!

Hopefully, the steps above will be helpful, even for users who aren't very technical. Unfortunately, though, maintaining a website will always be at least a little technical, so you may need to call on an expert!

If you have any questions or feedback or tips, please leave them in the comments below!

Or, if you're interested in paid support: Our whole business is support and maintenance for Drupal sites, so if you need help, please feel free to contact us. Good luck!

Dec 20 2017
Dec 20

by David Snopek on December 20, 2017 - 1:31pm

Today, there was a Highly Critical security advisory for a Remote Code Execution (RCE) vulnerability in the me aliases module for Drupal 7:

me aliases - Highly critical - Arbitrary code execution - SA-CONTRIB-2017-097

This module provides shortcut paths to current user's pages, eg user/me, blog/me, user/me/edit, tracker/me etc.

It was incorrectly handling URL arguments that could allow an attacker to execute arbitrary PHP code.

However, the way the Drupal 6 version of the module handles URL arguments isn't vulnerable in the same way. So, Drupal 6 users can rest easy - your site isn't affected by this issue.

But if you do use it on Drupal 7, given the criticality of this issue, please update right away!

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Dec 06 2017
Dec 06

by David Snopek on December 6, 2017 - 2:37pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for the Mailhandler module to fix a Remote Code Execution (RCE) vulnerability.

Remote Code Execution vulnerabilities are scary - it basically means that an attacker can run arbitrary code on your site. However, there a number of mitigating factors in this case, so, it's recommended to read the security advisory for Drupal 7.

With the help of the D6LTS vendors, a new version was released for Drupal 6 as well.

You can also download the patch the patch.

If you have a Drupal 6 site using the Mailhandler module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Oct 17 2017
Oct 17

In about a month, it'll be 2 years since Drupal 8.0.0 was released. Drupal 8 has come a long way since then, especially with Drupal 8.4.0 released two weeks ago, which is the most feature-packed release yet.

Drupal 8 is the future of Drupal. It's awesome.

However, looking at all the blogs and articles and podcasts in the Drupalsphere, we're sending a message that you should only build new sites on Drupal 8.

The common wisdom is that starting a new project on Drupal 7 is dumb idea.

While I'm sure there's lots of people who are OK with that or even think that's the right message...

I strongly believe that we are hurting the Drupal project by sending that message.

Read more to find out why!

Drupal 8 isn't ready for everyone... and might not be for a while

The root of the problem is that, while Drupal 8 can do so much, it isn't a complete replacement for Drupal 7 yet.

I'm not just talking about features, and what modules are available, and community knowledge/ability, and tooling... Well, actually, I'm talking about all those things together. :-)

What made Drupal 7 (and earlier versions) great, wasn't that core was awesome. In fact, while core was always made of well-written code, it was decidedly UNawesame all on its own.

The magic of Drupal was being able to quickly build an application with loads of features, without needing to write much code.

In fact, with Drupal 7, a site bulider — even one who is incapable of writing code — could create a pretty advanced website (say, a Facebook clone?) just by combining modules (with an FTP client) and clicking their way through the admin screens in Drupal.

In Drupal 8, the bar is currently much higher. Working on a Drupal 8 site today, you'll need to write custom code or help port modules, because the contrib ecosystem is less mature.

But even if all the contrib modules were ported and had stable versions, you're now forced to do things that are good ideas, but previously were totally optional, for example: use composer, maintain a staging site, probably use Git and specialized hosting.

Don't force out the "non-techies"

Should the Drupal community "level up" and learn how to use composer, git, etc? Yeah, that'd be good. :-) But does it really make sense to require that?

Many very successful Drupal users are not developers or even technologists. They're librarians, or volunteers, or scientists, or government employees, etc, who do need the power of Drupal (ie. Wix wouldn't work for them), but don't have the time or incentive to become "real techies."

Traditionally, Drupal democratized the ability to create advanced websites by empowering non-techies.

And they are valuable members of our community! They make many non-code contributions, not the least of which is making sure we create software usable by non-developers. And some do eventually make the leap to being developers, but they probably wouldn't have if the initial bar was too high and they couldn't make the transition gradually.

Let's not force these people out of our community.

There are some issues on Drupal.org looking at ways to eliminate or reduce these barriers. For example, looking at ways for site builders to use composer without having to learn composer. But I don't see those problems being fixed particularly soon.

The software adoption curve

Software goes through a predictable cycle where different groups of people adopt it at different times. At first, it's only picked up by innovators and early adoptors, but eventually it's ready for mainstream usage. A lot happens in the process, and not all of it is related to code or the core product.

Many of the tools and processes that we use day-to-day as Drupalists didn't come from Drupal core, but the ecosystem around it (drush, Features, etc) and shared knowledge and best practices (tens of thousands of hours of experience gained by many different people and groups, and remixed via meetups, Drupalcamps, Drupalcons, blog posts).

Drupal went through this process as it was figuring out what it was, and as the community learned how to build sites with it. I'd say the transition to mainstream happened somewhere between Drupal 4.7 to Drupal 6, and continued to mature with Drupal 7.

While all major Drupal releases up until now made big changes, they were more iterative and much about the way that Drupal worked and how our community used it to build sites remained the same.

Since Drupal 8 is nearly a complete rewrite which shook up much of what we know about developing Drupal sites, I'd argue that Drupal 8 is starting the software adoption curve all over again.

While there are some things that have remained the same, there is a huge amount of new stuff, much of it untested over the long-term. Drupal 8 is ready for innovators and early adoptors, and maybe some people in the middle, but it's not ready for all the same groups of people that can successfully adopt Drupal 7.

We're creating a false choice

By pushing Drupal 8 so hard, we're creating a false choice:

  1. Use Drupal 8 for your new site, or
  2. Wait for when Drupal 8 is capable of supporting you (... and while you're waiting, consider moving to other platforms!)

We do Drupal 6 Long-Term Support, and we've seen many people who loved their Drupal 6 sites move to non-Drupal platforms because they didn't see themselves capable of building a new Drupal 8 site, or paying for someone else to do it, or both.

But Drupal 7 is still awesome and isn't going anywhere any time soon!

Since Drupal 7 is still used by nearly a million or so sites (the majority of Drupal sites) we're going to need to continue to support Drupal 7 for a long time, whether that's in the form of official support from the Drupal project or as a Drupal 7 Long-Term Support effort.

Drupal 6 continues to be with us (via Drupal 6 Long-Term Support) almost 10 years after its initial release!

Honestly, I think Drupal 7 is going to be with us in a real way for another 8-10 years.

So, why not say it's OK to build new sites on Drupal 7?

By not saying it, we're pushing people to other platforms

I mentioned this in the last section, but it's worth reiterating:

When people see Drupal 8 as the only way they should be build new sites, and it doesn't seem to work for them, they begin to consider other platforms.

I really, honestly believe that Drupal 8 will get to a point where it can support the same groups of people (including the non-techies) that Drupal 7 supported.

But to keep those people in our community until we get there, we need to be saying, as a community: "It's OK to build new sites on Drupal 7!"

Ok, I've said my piece. :-)

I'm sure this will be a controversial opinion and that many people will disagree. I look forward to discussing further in the comments below!

Do you agree with my argument? Or think I'm totally wrong? Please leave a comment below!

Oct 11 2017
Oct 11

by David Snopek on October 11, 2017 - 1:37pm

Today, there was a Moderately Critical security advisory for an Access Bypass vulnerability in the netFORUM Authentication module for Drupal 7:

netFORUM Authentication - Moderately critical - Access Bypass - SA-CONTRIB-2017-077

The module was bypassing protections on the Drupal 7 user login form, to deter brute force attempts to login to the site, and so was an Access Bypass vulnerability by making login less secure when using this module.

However, Drupal 6 (including Pressflow 6) don't have these same protections for the user login form, and so, using this module is no less secure than using vanilla Drupal 6. Of course, these protections could be added to this module, and while this would be great security hardening, this doesn't represent a vulnerability - only a weakness which is also present (and widely known) in Drupal 6 core.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Sep 06 2017
Sep 06

by David Snopek on September 6, 2017 - 3:24pm

Today, there were two security advisories posted for modules that have Drupal 6 versions:

Happily, neither issue affects the Drupal 6 version of the modules!

I think this is particularly important for the Critical issue in Clientside Validation. Anyone who uses the Drupal 7 version of that module should update immediately! But, this time, Drupal 6 users can rest easy. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Aug 16 2017
Aug 16

Migrating your site to Drupal 8 isn't simple or cheap. Nor is maintaining it or getting support once your new Drupal 8 site is live!

This is a problem that affects all organizations using Drupal, but it's particularly hard on smaller nonprofits.

A couple weeks ago, I wrote a super long article detailing how Drupal 8 has left many small nonprofits behind. It also proposes a possible path for fixing it!

We're building an Open Source platform for nonprofit websites built on Drupal 8 and CiviCRM, available as a SaaS with hosting and support included.

That article was primarily about why - in this article I'd like to talk about the details of how!

There's a lot to discuss, but I'll try to make this article shorter. :-)

Oh, and we're looking for 10 adventurous nonprofits to join the BETA and help build it.

If you join the BETA, we'll migrate your existing site to the new Drupal 8 & CiviCRM platform for FREE!

Read more to learn about all the details we've got worked out so far...

WARNING: All is in flux!

In response to our recent articles, we received dozens of comments, emails and submissions to our call for nonprofits to join the BETA. As a result, we've scheduled numerous calls with interested folks and already had about a dozen.

We started this process with a painful problem and a rough sketch of a plan to solve it.

But we want the rest of the plan to be finished in collaboration with the nonprofits in the BETA.

We did this on purpose, because we knew any first draft of any plan would be wrong, and we didn't want to get too attached to it. Too much existing software is a "solution looking for problem" and we want to actually solve problems.

Anyway, all of that to say: whatever I write here is subject to change based on further discussions with real nonprofits and what happens during the BETA.

The BETA process

So, with that said, here's how we envision the BETA process going:

  1. Find 10 adventurous nonprofits to join the BETA
  2. Gather use cases from them to cover the critical features of all sites
  3. Build, migrate and launch each site
  4. Iterate for 12-ish months until we have something solid and generally usable
  5. Launch the first version of the SaaS "self-service plan", ending the BETA period, and moving to general availability

Throughout the BETA and beyond, all of the code for the platform will be Open Source and publicly available, or contributed back to Drupal, CiviCRM or to the other 3rd party libraries and modules used.

So, even folks who don't want to work with us commercially can use the fruits of our labor or contribute on the Open Source side, and there's no "vendor lock-in."

Our main business is support and maintenance, which I think we're pretty awesome at, but I'm biased. ;-) We're going to treat members of the BETA like we treat any support and maintenance customer, as if they were on our "Standard" plan, so, we'll answer support questions and perform an UNLIMITED number of maintenance requests.

We'll do whatever amount of initial training is necessary to get you and your team productive on the platform. (Eventually, we'll have some sort of standard training, but in the beginning we need to figure out what should be included in that!) The training will need to be done virtually.

Feature ideas

Like I said above, we're going to work with the nonprofits in the BETA to decide on the final feature set, but here's roughly what we've got in mind for the first version so far:

  • Selling memberships (where members can login and update their profile)
  • Accepting donations
  • Events (created in CiviCRM but exposed on the Drupal site) with all the usual features from CiviCRM, like: online RSVP, optional fees, event reminders/follow-ups, attendee limits, etc
  • "Page" content type
  • "News" (ie. blog) content type
  • Modern front page that can be edited in-place
  • Clean, modern, mobile-friendly theme that can be re-colored and configured for brand identity
  • Contact page with messages recorded in CiviCRM
  • Volunteer management (via CiviCRM)
  • Mass emailing (via CiviCRM)
  • ...the rest of the default feature set of CiviCRM 4.7+ on the backend. If you're curious why we've chosen CiviCRM and not a pure Drupal solution, check out the article I wrote about CiviCRM last week.

Of course, after launching the first BETA sites on the initial feature set (whatever that ends up being) we'll continue to iterate and expand the feature set based on the needs of the BETA participants.

Pricing ideas (for the future)

Like I decscribed above, we're hoping the BETA process will last about a year.

At the end of that, we're going to make our SaaS platform for nonprofit websites (built on Drupal 8 and CiviCRM) available to anyone (what I'm calling "general availability").

We're imagining two plans:

  • A self-service plan for around $50/mo. You get a Drupal 8 & CiviCRM site, pre-setup with the basic things a nonprofit membership organization needs, and the ability to customize it yourself, with some detailed documentation on how to do so. Hosting is included and you'll get updates automatically as they come out.
  • A full-service plan for around $250/mo. You get the same as above, but additionally full support & maintenance service from our staff, similar to the Standard plan we currently provide for any Drupal site, which includes UNLIMITED requests to answer questions and make simple changes to the site. (Our Standard plan is normally $499/mo, so this is a reduced price for nonprofits.)

And, of course, since the whole platform is Open Source, you'll be able to quit at any time and take an exported version of your site with you, which you could setup in another hosting environment.

The goal is to have something that even small nonprofits could affort (like the ~$50/mo), while still giving them the full power of Drupal 8 and CiviCRM.

But, in order to get there, we need to first do the BETA which will have different pricing...

BETA pricing

Joining the BETA is a little risky (the product could flop!) but we're doing everything we can to mitigate that risk for you, and offer some incentives to make it worthwhile.

One thing we are NOT doing, though, is making the BETA completely free - after re-launching your site on Drupal 8 & CiviCRM, BETA participants will be charged $250/mo.

We feel strongly that charging for the BETA will lead to a better product: we want to make something that provides enough value that it's worth paying for. With money invested, participants are likely to be more engaged in the process and demand the things they need (rather than figuring, "eh, it's free, we can deal with it being crappy.")

However, we think this is a pretty good deal, because:

  • The monthly charges won't start until after your site is migrated and live on Drupal 8 & CiviCRM. You shouldn't have to pay until we're providing your organization with value. We will ask for a down payment on the first month to make sure your organization is serious, but if for some reason we don't re-launch your site on the new platform we're happy to refund that.
  • We'll include the same level of support & maintenance as on our Standard plan. Our main business is support & maintenance of Drupal sites, and our customers (many of whom are nonprofits) find value in our Standard plan for $499/mo - you'll get that same value for half the cost.
  • We'll migrate from your current site and CRM to Drupal 8 & CiviCRM for FREE. While there is a fixed, monthly cost, there isn't any additional charge for doing the migration. Drupal migrations are usually billed hourly and can cost tens thousands of dollars. Even if you don't continue your relationship with us past the end of the BETA, you'll now have a site that's upgraded to Drupal 8!
  • You can quit at any time - there will be NO term minimum. We've debated this internally over the last several weeks. On the one hand, we don't want to force anyone to be our customer. But on the other hand, there's a risk that an organization will join for a month just to get their site migrated and then quit. We've decided to trust the BETA participants to act in good faith. We want participants to stay in the BETA for a year, so, if you know up front that you won't or can't - please don't join the BETA. But if later on it's not working out or something comes up and you have to quit - that's absolutely fine, you can quit at any time and we'll give you a full copy of your site. :-)
  • You'll have a lot of influence over what the product becomes. All of the initial features and the features added over the first year will be based on the needs of the BETA participants.

Of course, we understand that there are plenty of small nonprofits that can't afford $250/mo!

The ultimate goal is to have a lower priced self-service plan (around $50/mo) that smaller organizations can afford. However, we need to go through the BETA process to get there, and while we're investing a lot of our own resources to build this, this is a way to partially share the cost of initial development with our customers.

If your organization can't afford to participate in the BETA, but might be interested after the BETA period is over, please stay in touch!

What makes a good BETA participant?

Certainly, if you're interested, let us know! We're actively changing our plans based on the conversations we're having, and so even if your organization doesn't match our current criteria, we could change our criteria based on talking to you. :-)

In any case, we think that a good BETA candidate is an organization that:

  • Uses a CRM or desperately needs to start using one. CiviCRM will play a big role and so we want to work with organizations that will actively use it and get something out of it. Signs that you desperately need a CRM include using some imperfect and painful system to track your members or constituents (like spreadsheets, Microsoft Access, paper, etc) but you do it anyway because it's important to your operations.
  • Has users (volunteer or staff) with the time to use it and give feedback. Of course, no one has an abundance of time, but we need to actively engage with the BETA participants in order to build a good product. If you spend some amount of time updating your site or doing outreach to constituents on a regular basis (say, weekly or monthly), and are excited about this idea enough to complain when things could be improved, then that's exactly what we're looking for. :-)

If that sounds like your organization, please get in touch!

But if we can't find 10 nonprofits for the BETA, we're not doing it

Basically, we don't want to build something that people don't really want.

If we can't find 10 nonprofits who will take the leap with us... well, either the need must not be that great, or our plan is seriously flawed in some way.

But if there's atleast 10 nonprofits willing to join despite the risks this early, there's probably many more who'd be interested later. And if we build something that works for at least 10 customers AND it's good enough to pay for, well, we probably made something pretty good.

If you're interested, please click the big green button below to...

Join the BETA or get progress updates

We'll be posting more as the project progresses, so please stay tuned!

Think this a great idea? Or, even better - think we got something terribly wrong? Leave a comment below! We're listening :-)

Aug 10 2017
Aug 10

Last week, I published a super long article called Drupal 8 has left small non-profits behind... How can we fix that? which details the many issues Drupal 8 is having and their chilling affect on usage among nonprofit organizations.

It also proposes a possible path for fixing it: building an Open Source platform for nonprofit websites built on Drupal 8 and CiviCRM, available as a SaaS with hosting and support included.

We're looking for 10 nonprofits who are willing to participate in the BETA and help build it (in exchange for a FREE migration to Drupal 8 & CiviCRM).

Next week, we're planning to talk more details about how that BETA process will work!

However, this week, I wanted to take a little break from that, and talk more about CiviCRM in Drupal 8.

So, in this article, we're goning to:

  1. Walk through how to install CiviCRM on Drupal 8. It's quite complicated now, but we're helping to improve that.
  2. Talk about why we're betting on CiviCRM and not a CRM built in Drupal. There's a couple of great, pure Drupal solutions to CRM, like RedHen or CRM Core - but we've chosen to go with CiviCRM. Why?

Read more to find out!

CiviCRM works on Drupal 8!

Contrary to popular belief, CiviCRM mostly just works on Drupal 8 :-)

The CiviCRM team did a push (with the help of some fundraising) to do most of the big work needed. However, there are a couple of small (but very hard) problems remaining around installation. But once you get it installed, you're golden!

The main problematic piece of this is handling composer.

Composer is tool for installing PHP code into applications, like Drupal. It handles the difficult problem of getting all the dependencies (and their dependencies) at a mix of versions that will work together. It's becoming adopted pretty widely in the PHP world, but is still relatively new. Drupal 8 is built on it.

Both Drupal 8 and CiviCRM use Symfony and a couple other shared dependencies. So, the core CiviCRM code needs to be installed into your Drupal 8 site with composer, in order to combine everything together in a way that works. CiviCRM does use composer, but it's pretty early days.

Over the last several weeks, we've been helping to improve CiviCRM's composer support so it could be correctly installed into a Drupal 8.3 or 8.4 site.

Not much of this work has been merged yet, but we have a reproducible set of steps for getting CiviCRM installed that you can use today!

Getting started the easy way

In the next section, we're going to describe the manual process to add CiviCRM to an existing CiviCRM site.

However, if you just want to launch a new site with all the CiviCRM stuff already there, we have a "easy way" for you!

We made a project on GitLab with all the composer stuff already done and the Drupal module included and patched! Here's the process:

  1. Download the ZIP or TAR.BZ2 file (linked version is Drupal 8.3.6 + CiviCRM 4.7.22)
  2. Install just like vanilla Drupal 8
  3. Go to the "Extend" page (at /admin/modules) and install the CiviCRM module
  4. Log out and log back in again per CRM-19878

I don't know how long we'll maintain this specific repo, but I'll try to keep it up-to-date until we have some code publicly available from the BETA of our Drupal 8 & CiviCRM platform which will replace this.

The full, manual process

If you want to add CiviCRM to an existing Drupal 8 site, you'll have to follow the manual process.

Once all these little (but very hard!) problems are fixed, and the fixes are merged into CiviCRM and related libraries, it'll be a single composer command to get CiviCRM added to your existing Drupal 8 site.

However, right now, the manual process is not so easy.

But if you wanted to do it, we have a reproducible process that you can follow!

  1. Download and install Drupal 8.3.6 (or the latest dev of Drupal 8.4.x!)
  2. Go into the root directory in the shell and run these commands to install CiviCRM via composer (one day this will just be composer require civicrm/civicrm-core). Assuming you have composer, bower, git and wget, you should be able to just copy-and-paste those commands into the command-line.
  3. If you use Apache, remove the 'vendor/.htacess' file. This is a security measure from Drupal, which prevents resources like CSS/JS being loaded. This will need some collaboration with the Drupal project to figure out a proper solution for because removing this file altogether is a bad idea on production. See: https://www.drupal.org/node/2896308
  4. Go into the /modules directory and do: git clone https://github.com/dsnopek/civicrm-drupal.git --branch composer-library
  5. Go to the "Extend" page (at /admin/modules) and install the CiviCRM module
  6. Log out and log back in again per CRM-19878
  7. CiviCRM works!

As we've been making progress on the changes for CiviCRM to better support composer, I've been removing commands from the Gist with the special process in step #2, which I plan to continue doing until it's not necessary.

If you have problems (or succeed), I'd really appreciate the feedback!

(And if you post those problems or successes on the PR on GitHub, it'll help move forward the process of committing those changes!)

Why CiviCRM and not RedHen (or other pure Drupal solution)

So, with all that trouble to get CiviCRM working, why even use it?

Drupal is a powerful framework for building awesome things. Why not make some new entity types for CRM-y things like Contacts and Activities, throw some fields on there and make a pure Drupal CRM? There's even some great pre-existing Drupal modules like RedHen and CRM Core to build on.

Drupal can do anything, why not a do a CRM? ;-)

We fell into CiviCRM sort of by accident. A strong plurality of our customers are nonprofits and many of them use CiviCRM, so, we had to start supporting it!

We found that, for many of them, their CiviCRM was actually more important to their daily lives and the operation of their organization than the website.

After spending some time with CiviCRM, we're doubling down on it for our new nonprofit Drupal 8 platform. Here's why...

CiviCRM community is larger than any Drupal CRM module

The CiviCRM community is much smaller than the Drupal community, but much larger than the community around any of the Drupal CRM modules.

The core CiviCRM team is only 4 people, but they work on CiviCRM full-time. (And they don't do CiviCRM installations or paid support or anything like that - they only work on core issues that benefit the whole community.)

There are regional CiviCon's and CiviCamps and monthly meetups - all over the world.

There are multiple books written about CiviCRM.

There are 67 partner/contributor organizations listed on civicrm.org, who provide any number of services: setting up CiviCRM installations, doing trainings, providing support & maintenance, SaaS hosted versions of CiviCRM, etc. And there's probably even more commercial companies out there!

While it would be really cool, I can't really imagine there being four RedHenCon's held in the UK, US, Australia and Germany in a single year, like the 4 CiviCon's scheduled in 2017. :-)

CiviCRM is a complete product

Most Drupal modules are legos, not complete products.

Of course, there are exceptions, but usually you're expected to assemble a set of modules into a thing, rather than a module being a thing.

CRM Core and RedHen are a set of tools in order to build a CRM. They are not complete CRM's on their own.

We could certainly make a CRM as complete as CiviCRM by combining Drupal modules. But none that are out there are quite as complete as CiviCRM, especially, with regard to nonprofits...

CiviCRM is really well suited to nonprofits

The best CRM is one built specifcally to the needs of your organization. For this reason, all CRM's are customizable to some degree, but most CRM's are closer to the needs of certain organizations.

For example, at myDropWizard, we use HubSpot for our CRM. We're a commercial support & maintenance company, so the most useful feature in HubSpot for us is configurable "deal workflows" and seeing all active deals in a workflow-specific kanban board.

We wouldn't be able to use CiviCRM because it's completely missing this feature. But nonprofits don't miss it because their businesses don't depend on deal flow. By the same token, a nonprofit would be missing the pledge, fundraising, grant and volunteer management features that are present in CiviCRM if they tried to use HubSpot.

By focusing only on the needs of nonprofits, CiviCRM has been able to grow into a really killer piece of software for nonprofits.

RedHen and CRM Core are also slanted to towards nonprofits, but seem to leave the door open to being more general, and haven't grown to support as many use cases that are important to nonprofits.

CiviCRM has less "vendor lock-in"

Since Drupal is Open Source, there really isn't true "vendor lock-in" - there are loads of Drupal shops who can help you and you're free to switch.

But we've seen how hard it can be to move from Drupal 6 or 7 to Drupal 8, where people can get stranded in an old version.

The same version of CiviCRM can work in Wordpress, Joomla, Backdrop or Drupal 6, 7 & 8.

If you have a Drupal 6 site using the latest CiviCRM, you can move the core CRM piece to either Wordpress or Drupal 8, basically unchanged. CiviCRM has it's own extension system, which allows the same extension to be used in any supported CMS.

Of course, if you're using Drupal modules that interact with CiviCRM, those would need to be ported just like any Drupal module.

But I think just knowing there is this extra freedom to migrate is good for users who may be concerned about the long-term prospects of Drupal 8.

Join our BETA!

Like I said in the intro we're building an Open Source platform for nonprofit websites built on Drupal 8 and CiviCRM, and looking for nonprofits to be a part of the BETA.

If you're interested, please click the big green button below to...

Join the BETA or get progress updates

We're going to be announcing more details about the BETA next week, but you can read what we're already said about it in last week's article.

Have any experience with CiviCRM? Good or bad? Tried installing it in Drupal 8? Please leave a comment below!

Pages

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