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!

Aug 09 2017
Aug 09

by David Snopek on August 9, 2017 - 12:34pm

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 Facebook Like Button module to fix an Cross Site Scripting (XSS) vulnerability.

The module provides a Facebook Like button on node pages and blocks.

The module doesn't sufficiently sanitize certain configuration fields.

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 Facebook Like Button module, we recommend you update immediately.

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 02 2017
Aug 02

My colleague, Elliot, recently wrote a controversial article called "Drupal sucks at non-profits," which led to some really great discussion in the comments. The general consensus is that Drupal 8 is great for big nonprofits (and big organizations in general) but has left the little guy behind.

Drupal used to be AWESOME for small nonprofits... How can we make it awesome again?

This is something we've been discussing internally for a long time, and we'd like to take a stab at a possible solution with the help of the community and some adventurous nonprofits.

In fact, we'd like to offer a FREE migration to Drupal 8 for 10 nonprofit organizations :-)

But, we'll get to that a little later! First, I'd like to dig into why the current situation kinda sucks...

Drupal 6 & 7 were awesome for nonprofits!

At myDropWizard, we provide support and maintenance for Drupal sites. We don't generally build new sites, we provide killer support for sites that are already live, including Long-Term Support for Drupal 6 sites.

A strong plurality of our customers are nonprofits, most of them on Drupal 6.

And Drupal 6 was a great choice for nonprofits, both from a technical perspective and the commercial and community eco-system built around Drupal at the time!

The TRUE power of Drupal isn't from Drupal core, but from:

  • The 38,158 contrib modules. Want to add some new functionality to your site? "There's a module for that!"
  • The community. You're only a Google search, or Meetup away from the solution to any Drupal problem.
  • The commericial eco-system. The are (or were) loads of freelancers and small Drupal shops willing to help out small nonprofits. In fact, many professional Drupalists originally came from community organizing or activism or education or other places spiritually aligned with small nonprofits.

If you were pretty tech literate (but not necessarily a programmer), it was possible to mash together a workable site (with pretty advanced features!) geared specifically to the mission of your organization, for a reasonable amount of cost and effort for a small nonprofit.

Ah, the old days :-)

Why does Drupal suck for nonprofits now?

I love Drupal 8. As a developer, I'd much rather write code for Drupal 8 than previous versions.

It fixed a number of old architectural problems and set us up for some really cool things down the road. Drupal 8 is (going to be) awesome.

Drupal 8 is the future of Drupal!

But...

There's a number of problems right now, and they have a particularly chilling effect on the use of Drupal 8 at small nonprofits.

Like I mentioned above, a strong plurality of our customers are nonprofits on Drupal 6. As they upgrade their sites, they are NOT moving to Drupal 8! They're either going to Drupal 7 or, more frequently, away from Drupal entirely.

And we're not the only ones that see this. There were some really amazing comments on our last article, and I highly recommend reading them, but I'll summarize the main points below...

Drupal 8 is released! But kind of still under development...

Our vendor is a 40+ person shop and when they were delivering the site to me we had to fight to get some of the basic stuff that D8 promises out of the box (e.g. in-place editing, simplified admin, testing, etc) because it is not as stable as you hope...

- Krugs on "Drupal Sucks at Non-profits"

Drupal 8.0.0 was finally released November 19, 2015, but in a lot of ways, it was not a finished product. There's lots of really great new ideas in core, but many of them haven't really matured yet.

Now, I'm not saying we should have kept working on it until it was more polished - someone needed to draw a line and say, "it's usable enough in some cases, let's get it out!"

But using it in production requires someone to support it who can debug hard problems, watch the issue queue, apply patches, do upgrades, etc.

Of course, this is EXACTLY the sort of thing you'd hire a support and maintenance company like myDropWizard to do, and we try to make our services as affordable as possible, but this is still outside the reach of many nonprofits.

The contrib space isn't there yet

There are some cool stuff around the paragraphs module and the contrib media is getting there, nicely... with lots of patches, spit, composer prayer and symfony meditation...

- Davy Jones on "Drupal Sucks at Non-profits"

Building a Drupal site used to be like putting some lego blocks (modules) together, configuring and sprinkling just a smidge of custom code.

While there has been loads of progress on porting modules to Drupal 8, or creating completely new and interesting ones, it isn't yet like the old days.

Even a year and half after release, to build a Drupal 8 site, you'll find yourself helping to port modules, applying several patches from the issue queue and writing far more custom code than you used to.

Many small nonprofits don't have the additional resources or expertise to do this.

The knowledge base isn't there yet

What used to be a helpful, supportive place is becoming more and more commercialized, with more and more essential information being withheld unless people are paid to divulge it.

- Chris Brown on "Drupal Sucks at Non-profits"

When I need to do something I've never done in Drupal 8, first, I'll "google" it. Not infrequently, a great series of tutorials will come up... unfortunately, they were written in 2013 (before 8.0.0 was released) and totally irrelevent on current Drupal 8. :-(

While this situation is improving and there's some great material out there, the core of the problem is that most of our community (even those who used to be the most knowledgable) haven't gotten totally up-to-speed on Drupal 8 yet.

It's a bootstrapping problem. How can Drupalistas help at meetups, answer questions on Stack Exchange or write awesome blog articles on how to use Drupal 8 when most are still learning it themselves?

This will fix itself in time, but for now, it's very hard for small nonprofits with limited resources to learn how to do things on their own.

Drupal was never the easiest or cheapest, but Drupal 8 is worse

Composer may be technically superior and future proof but unless they can pull off some magic software tricks it's not going to work for shared web hosting environments that most local non-profits (and individual users such as myself) use.

- Frank Kelly on "Drupal Sucks at Non-profits"

What will get you a toy castle easier and faster? A complete plastic castle with a couple moving parts (but is mostly fixed in place)? Or a sack of legos that can be made completely dynamic?

That analogy may be the result of spending all my free time playing with my daughters, but I think it pretty accurately describes what makes Drupal so hard to use.

If you haven't guessed: Drupal is the sack of legos. :-)

Drupal has a steep learning curve, it has special hosting requirements (I'd argue even Drupal 6 & 7 shouldn't be hosted on cheap shared hosting that isn't optimized for Drupal), and needs special care with long-term support and maintenance.

And Drupal 8 pushes further in that direction.

It's more complex. You may have been able to get away without using Varnish and Redis and SOLR and Drupal-optimized hosting in Drupal 6 or 7, but certainly not with Drupal 8. With Drupal 8, support and maintenance needs to be a lot more proactive (we know - that's what we do!).

Nonprofits have been successful with Drupal 6 & 7 in the past in spite of these challenges, but the increased challenge with Drupal 8 may have raised the barrier too high.

The commercial eco-system has moved up market

Who was that famous guy who said, "Drupal 8 is for AMBITIOUS SITES?" It was none other than Dries Buytaert the founder of Drupal. Just google "Ambitious Drupal Sites" and see everyone competing for the keywords and trying to prove that THEY can build your next ambitious project.

- Doug Vann on "Drupal Sucks at Non-profits"

At DrupalCon New Orleans, Dries, the Drupal project lead, chose a very diplomatic way to describe how Drupal's commercial ecosystem has moved upmarket. Rather than saying "Drupal is for the enterprise", he said "Drupal is for AMBITIOUS digital experiences."

I disagree with Dries, but I'll address that in full in a future article.

It's definitely true that Drupal's commercial ecosystem has moved up market. You used to be able to find lots of freelancers and small shops, who were interested in working with smaller organizations on smaller projects. However, many of the freelancers I know have gone on to work at big shops and many of the small shops have grown or merged with other shops. And they are looking for big projects.

This doesn't just affect Drupal 8 - it's harder for smaller organizations to find help with Drupal 7 too. But certainly makes it much harder for any small nonprofit who was successful with Drupal 6 to move to Drupal 8.

The world is changing!

Meanwhile very small non-profits with mostly volunteer labor simply do not have the resources to maintain a Drupal site or to pay someone market rate to do so. They may be better served with Wordpress and/or a turnkey SaaS solution. [emphasis added]

- Dave Rudderman on "Drupal Sucks at Nonprofits"

It used to be that the expectation -- not just in nonprofits -- was that you'd buy some server or hosting somewhere that would handle your e-mail, your website, some other tech services, and hire somebody to build you a custom website.

In this day and age, there are organizations that only have a Facebook page. Or put their blog on Medium. Or, built their site themselves with a SaaS site building tool like Wix or Squarespace.

Your organization has a specific mission. That's really what you care about.

Why would you want to maintain a server, or install software? Especially software as complex to maintain as Drupal?

Some small nonprofits may look at the cost/benefit and decide that they don't need something like Drupal for their web presense.

So, what do nonprofits really want?

As I mentioned above, a good portion of our customers are nonprofits. I've also done Drupal projects for nonprofits as a consultant and Elliot has served on the boards of several nonprofits.

We've learned a few things about what they want:

  • They want their web presense to reflect the nature of their organization and their mission. I think this is why Drupal has been so successful with nonprofits in the past: it can be customized so extensively. Apps like Wix or Squarespace that can sometimes work pretty well for small businesses, don't quite fit for nonprofits.
  • They want as few "tech things" as possible. Some organizations are happy to have seperate tools for everything, for example: Drupal for a website, Mailchimp for e-mail marketing, external CRM, etc. But there is a strong tendency among nonprofits to want it all in one.
  • Their CRM is hugely important. Many of our customers use CiviCRM, and while its integrations with the website are super important, the CRM itself is frequently more critical to them than their website. This was driven home by Kevin Reynen on "Drupal Sucks at Nonprofits"
  • They don't really want to deal with hosting/servers. We've discovered that it's super difficult to get customers off of their hosting or custom server setup, even when we offer to do the migration for free (which we do :-)). But that's just inertia - they don't really want to deal all that mess.
  • The most critical needs of most charitible nonprofits are very similar. Elliot talked about this on "Drupal Sucks at Nonprofits" but this includes things like: volunteer coordination, accepting donations, events, news, mapping, communicating with their constituents, etc. Many of the customizations that our customers have developed for their sites are the same fundimental features, even if they are implemented in different ways.
  • They want to predictably budget how their tech dollars are spent. Most nonprofits do have funding, but they need to be very careful with budgeting the money they have. They must focus the majority of it on their mission. Working with a Drupal shop is traditionally difficult to budget for because building certain features or fixing certain bugs may end up costing more to develop than expected -- the dark side of agile development.

How to make Drupal 8 awesome for nonprofits?

The only way to make Drupal 8 great for small nonprofits, is to start using it for small nonprofits.

Drupal is a "do-ocracy", and we have to start doing it :-)

Drupal 8 can provide the things that nonprofits need -- we just need to figure out a way to deliver them in a way that's accessible to nonprofits.

So, here is what we propose:

  • We'll work with 10 adventurous nonprofits to create a Drupal 8 + CiviCRM distribution for charitable nonprofits (information on how to get involved below)
  • The Drupal 8 + CiviCRM distribution will be Open Source and available to anyone who wants to set it up themselves
  • We'll create a SaaS version which includes hosting and support so small nonprofits don't have to deal with setting up or installing or maintaining their site
  • We'll migrate the 10 nonprofits in the BETA group from Drupal 6 and their old CRM to Drupal 8 + CiviCRM for FREE! We'll be talking about all the details of the BETA process later, but very quickly: the BETA itself won't be free (we'll be charging a monthly fee for the service), however, as an incentive to join the BETA we won't be asking for anything additional to do the migration. This is significant: migrations to Drupal 8 can be super expensive - a cost of thousands to tens of thousands of dollars for a migration is not uncommon.

There's a community side to this: we'll be improving Drupal 8 and CiviCRM and various contrib and making all of it available as Open Source. Other vendors and Drupalista's and individual nonprofit organizations who have technical resources are welcome to take advantage of what we create and contribute if they like.

And there's also a commercial side: we hope to provide a path for our customers to stay with Drupal rather than switching to something else. And, we want to be able to offer the SaaS version to smaller organizations that otherwise wouldn't have been able to afford our services.

Doug Vann wrote, "D8 was not built with Nonprofits in mind".

We're hoping that we can change that :-)

We want to create an Open Source "Wix for nonprofits"

In this article I sought to cover the the why of this project. The specific implementations of our proposed solution will be addressed in greater detail in another article. :-)

But, in short, the end goal is to create a hosted SaaS solution (based on Drupal 8 + CiviCRM), to allow nonprofits to build their own sites, for a low monthly fee.

So, in the end, it'll be as easy to use as other well known hosted solutions (like Wix) but with the additional features nonprofits need (like CRM, volunteer management, etc) with a price accessible to small nonprofits.

However, to be super clear:

  • At launch, we won't have something as simple and easy to use as our end goal - much development needs to be done
  • The members of the BETA group will be paying more than the eventual super low price point. While the sites won't be completely custom they will be built to their needs, fully supported (the way we support and maintain our customer sites currently) and allow for adding things outside our standard platform

So, while the ultimate goal is to have something that even very small nonprofits could use, it's going to take us a little while to get there.

We'll need the help of some adventurous nonprofits - and not necessarily the smallest - in order to make that a reality!

Join the BETA and help us build it!

It's going to be a monthly paid BETA, and for a product that doesn't really exist yet, and so participating is a little risky. But here's what you get for taking that risk:

  • We'll be building the platform to meet your most critical needs and you'll have a large influence in what it becomes
  • We'll migrate the content from your old site and CRM to Drupal 8 and CiviCRM for FREE!
  • You won't have to start making monthly payments until we launch your new site with all your data migrated over
  • Even if the SaaS service flops, you can still export your site and take it somewhere else because it's all Open Source

So, if you're interested in your organization being part of the BETA or just want to stay in the loop, please fill out this simple form!

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

We've launched new products before and seen them both succeed and fail.

One of the biggest product building mistakes is spending loads of time building something and THEN trying to get people to use it. You end up finding out that you built all the wrong features and that no one would use it, let alone pay for it. :-)

So, we're only going to build it if we can find 10 nonprofits who will use it, help decide what goes in it, and pay for it. If it 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 digging deeper into the details in future articles, but please leave any comments or questions below!

Think it's a great idea? Or, even better - think it's a terrible idea? Leave a comment!

Jun 28 2017
Jun 28

by David Snopek on June 28, 2017 - 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 Moderately Critical security release for the SMTP module to fix an Information Disclosure vulnerability.

This SMTP module enables you to send mail using a third party (non-system) mail service instead of the local system mailer included with Drupal.

When this module is in debugging mode, it would log privileged information.

With the help of the D6LTS vendors, a new version was released.

If you have a Drupal 6 site using the SMTP module, we recommend you update immediately.

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 21 2017
Jun 21

by David Snopek on June 21, 2017 - 5:50pm

Today, there were Critical security releases for Drupal 7 & 8:

https://www.drupal.org/SA-CORE-2017-003

We received a couple e-mails asking if it affected Drupal 6, so I decided to post this short article to say:

Happily, Drupal 6 is not affected! :-)

Of the 3 vulnerabilities in that SA, the two Drupal 8 ones don't apply to Drupal 6: it doesn't have REST or YAML support.

We did extensive testing to see if the Drupal 7 one applied to Drupal 6, including, testing the 'upload' module (in Drupal 6 core) and with the contrib 'filefield' and 'webform' modules and couldn't reproduce the vulnerability.

(FYI, since we access to the private Drupal security queue, we did our testing several months ago :-))

So, if you still use Drupal 6, you don't need to worry about a core update today!

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