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 take 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!

Jun 21 2017
Jun 21

by David Snopek on June 21, 2017 - 3:35pm

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

From the security advisory for Drupal 7:

The Search 404 module enables you to redirect 404 pages to a search page on the site for the keywords in the url that was not found.

The module did not filter administrator-provided text before displaying it to the user on the 404 page creating a Cross Site Scripting (XSS) vulnerability.

This vulnerability is mitigated by the fact that an attacker must have a role with the permission "administer search".

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Site Verify 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).

May 24 2017
May 24

by David Snopek on May 24, 2017 - 3: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 Moderately Critical security release for the Site Verify module to fix an Cross Site Scripting (XSS) vulnerability.

The Site Verify module enables privilege users to verify a site with services like Google Webmaster Tools using meta tags or file uploads.

The module doesn't sufficiently sanitize input or restrict uploads.

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 Site Verify 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).

May 24 2017
May 24

by David Snopek on May 24, 2017 - 9:30am

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 AES encryption module.

The AES module provides an API for encrypting and decrypting data via AES. It also allows storing Drupal passwords encrypted in the database (rather than hashed) which can allow site administrators with high enough permissions to view user passwords.

Previously, the module implemented AES poorly, such that the encryption was weakened and could have potentially made it easier for an attacker to decrypt given enough examples of the encrypted data.

(A note about the timing of this release: the AES module was unsupported on March 1st, and we started working on a fix right away in the D6LTS queue. We usually release D6LTS patches the same day the D7/D8 patches are posted or two weeks after a module is unsupported, however, in this case we had only a single Enterprise customer using AES and so we worked on it according to a timeline dictated by them, which involved testing their custom modules using the AES API with their team. So, we're releasing this after it's been fully tested and deployed for our one affected customer - if more customers had been affect it would have been released same-day, as usual.)

Here you can download the Drupal 6 patch.

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

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

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

May 24 2017
May 24

by David Snopek on May 23, 2017 - 10:23pm

Last week, I presented on "Docker & Drupal for local development" at Drupal414, the local Drupal meetup in Milwaukee, WI.

It included:

  • a basic introduction to the why's and how's of Docker,
  • a couple live demos, and
  • the the details of how we use Docker as our local development environment to support & maintain hundreds of Drupal sites here at myDropWizard

The presentation wasn't recorded at the time, but it was so well received that I decided to record it again at my desk so I could share it with a wider audience. :-)

Here's the video:

Video of Docker & Drupal for Local Development

(Sorry, for the poor audio! This was recorded sort of spontaneously...)

And here are the slides.

Please leave any questions or comments in the comments section below!

May 17 2017
May 17

by David Snopek on May 17, 2017 - 9:29am

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 an Access Bypass vulnerability the Legal module.

The Legal module displays your Terms & Conditions to users who want to register, and requires that they accept the T&C before their registration is accepted.

It had a bug where a specially crafted URL could allow anyone to login to a user account that hadn't yet accepted the terms and conditions. This is mitigated by the fact that an attacker must have a way to obtain the URL, possibly by snooping on web traffic that isn't protected via HTTPS or a man-in-the-middle attack.

(A note about the timing of this release: per our agreement with the Drupal Security Team, we were unable to release this patch until the same vulnerability was fixed for the Drupal 7 Legal module, or two weeks went by after that module was unsupported, if it appeared it wasn't going to be fixed. The fix for Drupal 7 was released today.)

Here you can download the Drupal 6 patch.

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

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

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

May 10 2017
May 10

by David Snopek on May 10, 2017 - 12:05pm

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 Webform Multifile module to fix an Access Bypass vulnerability.

This module enables you to upload multiple files at once in a Webform, but it didn't sufficiently check access to file deletion URLs.

This vulnerability is mitigated by the fact that an attacker must have a role with the permission to edit all or their own webform submissions.

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 Webform Multifile 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).

May 03 2017
May 03

by David Snopek on May 3, 2017 - 3:10pm

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 Remember Me module.

Remember Me adds a "Remember me" checkbox to the login form.

It had a bug where it would override the session cookie lifetime, regardless of whether the user checked "Remember me" or not. This could affect applications that set the session cookie lifetime to a very short value, like banking websites.

(A note about the timing of this release: The Drupal 7 fix was released on April 23rd, however, we don't have any customers who depend on this module. So, it falls outside of the set of modules that we usually release security patches for on the same day they are released. But this is a module we like, so we decided to port the fix! :-))

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Remember Me 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).

Apr 18 2017
Apr 18

by David Snopek on April 18, 2017 - 1:05pm

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 CCK module to fix an Access Bypass vulnerability.

CCK allows you to add custom fields to any content type.

The Node Reference sub-module had a bug where it could list the node titles of nodes that the user doesn't have access to.

(A note about the timing of this release: per our agreement with the Drupal Security Team, we were unable to release this patch until the same vulnerability was fixed for the Drupal 7 References module, or two weeks went by after that module was unsupported. The fix for References was released today.)

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the CCK 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 28 2017
Mar 28

This is the third in a series of articles, in which I'd like to share the most common pitfalls we've seen, so that you can avoid making the same mistakes when building your sites!

myDropWizard offers support and maintenance for Drupal sites that we didn't build initially. We've learned the hard way which site building mistakes have the greatest potential for creating issues later.

And we've seen a lot of sites! Besides our clients, we also do a FREE in-depth site audit as the first step when talking to a potential client, so we've seen loads of additional sites that didn't become customers.

In the first article, we looked at security updates, badly installed module code and challenges ith "patching" modules and themes, as well as specific strategies for addressing each of those problems. In the second article, we looked at how to do the most common Drupal customizations without patching.

In this article, we're going to look at some common misconfigurations that make a site less secure, and how to avoid them!

NOTE: even though they might take a slightly different form depending on the version, most of these same pitfalls apply equally to Drupal 6, 7 and 8! It turns out that bad practices are quite compatible with multiple Drupal versions ;-)

5. Insufficient filtering on text format

Security is more than just updating modules when security releases come out.

It's possible to inadvertently create security vulnerabilities in your site, just through bad configuration!

One of the most common examples is creating a cross-site scripting (XSS) vulnerability by not putting sufficient filtering on text formats that can be used by untrusted users.

Let's unpack that...

What is Cross Site Scripting (XSS)?

This is the most common security vulnerability in Drupal. Most of the security advisories that you see come out on Wednesdays are to fix XSS vulnerabilities.

Basically, if an attacker can put <script> tags into content that will be viewed by other users, they can perform actions on your site as those other users. So, if they manage to get an admin user to view the <script> tag they added, they can do anything the admin user can do!

There's developer APIs for module authors to filter user input so that XSS isn't possible, but if the developer doesn't use it or uses it incorrectly, it can open up a vulnerability.

What is a text format?

At many of the places in Drupal where a user is creating content, they get a text box where they can choose the "Text format", for example:

Screenshot showing the Body field and pointing out the Text format selector

This controls how the text you entered is turned into HTML that's displayed by the web browser.

The text format could allow entering raw HTML, use a WYSIWYG editor, or use some other type of text markup format (ex. Markdown). The text format configuration allows you restrict which resulting HTML tags (like <script>) the user is capable of creating.

When building a site, you can create multiple text formats for use in different situations or by different user roles. So, Comments could allow users to enter Markdown but when creating content get a WYSIWYG editor. Or, administrators could use "Full HTML" and normal users only get "Restricted HTML".

What is an untrusted user?

When raising this issue with our customers, many of them believe that all of their staff members' accounts should be "trusted users" because they trust each of their staff as people. And so, they give them access to potentially dangerous text formats.

However, trusting a user also means that you trust their choice of password (and that they didn't reuse the same password on another service!) and that they use their computer in a secure way. You may trust someone personally, but they might have a virus on their computer that's watching their keystrokes and stealing all their logins and passwords.

Unless you have a stringent security policy that applies to all of your staff (and it's actively enforced!), you probably shouldn't consider all your staff's accounts to be trusted users.

What should I be careful about?

The two most important HTML tags that you need to worry about are <script> (allows XSS) and <img> (allows CSRF), but there's also several HTML attributes that allow Javascript (like onclick="...").

Those should all be filtered out on any text formats that can be used by untrusted users!

Screenshot of text format edit screen where you can choose the allowed HTML tags

You should also be sure to review which user roles have permission to use any text formats that don't filter them out, and evaluate which users have those user roles. You might have to split some roles into two roles to seperate "normal administrative activities" from the ability to use dangerous text formats.

6. Unsafe file extensions

In Drupal, you can add a File field to any content type. Each field can have a different set of allowed file extensions.

Similar to the last point, allowing untrusted users to upload files with certain extensions can open an XSS vulnerability!

Screenshot showing the allowed extensions configuration for a File field

The unsafe extensions include: HTM, HTML, JS or SVG. Basically, any file extension where the web browser would execute Javascript would allow XSS!

7. PHP in the database

To the more experienced Drupal site builders that may be reading this article: this is waaaaay more wide-spread than you think it is!

In short... If you're thinking about typing some PHP code into the Drupal admin interface somewhere: DON'T DO THAT! :-)

Even having modules installed that allow admin users to enter PHP code can allow attackers to exploit lesser vulnerabilities and escalate to a Remote Code Execution (RCE) vulnerability. Remember, XSS vulnerabilities are the most common, and they allow an attacker to perform the same actions as another user. If your admin user can execute PHP, than an attacker can do it too via XSS!

But beyond the security issues, PHP code that is saved in the Drupal database is hard to maintain and easy to break. It can also lead to site "magic" which is difficult to even find in order to fix or change it later.

Recommendations?

  • On Drupal 6 & 7, disable and remove the PHP module (doesn't exist on Drupal 8!) or any other module that allows PHP in the database. Or you could use the Paranoia module that prevents any such modules from being enabled, or disables the features in modules that allow entering PHP as part (but not all) of what they do.
  • Find a module to do what you want - there's lots (~20k)! Many beginning site builders might be using PHP code simply because they don't know that there's a module for what they want. This is a big part of the Drupal learning curve: just learning what's out there! Take a look at some of the big, mainstays of site building like: Panels, Views, or Rules
  • If there's no module and you really need PHP to do something in PHP... Guess what? You're a developer now! ;-) It's time to learn how to write proper Drupal modules.

How to become a Drupal developer?

This is an enormous topic! It'd take several more multi-part articles to cover, so I'll just give a couple resources here to get you started:

  • Check out the official docs for Drupal 7 and Drupal 8
  • See the Examples project. There's example modules for using the most common Drupal APIs
  • Check out the video course on Drupalize.me
  • Buy a book!

Conclusion

If you haven't already, please check out part 1 and part 2 of this series! This concludes the 7 most common pitfalls that we've seen when looking back over the site audit reports we sent out in 2016.

Have you encoutered Drupal sites that include any of the pitfalls discussed above? Are there any other important examples that you've encountered when building a Drupal site or reviewing a site built by someone else? Please write a comment below!

Or, if you'd like us to audit your Drupal site, please contact us about a FREE site audit!

Mar 21 2017
Mar 21

This is the second in a series of articles, in which I'd like to share the most common pitfalls we've seen, so that you can avoid making the same mistakes when building your sites!

myDropWizard offers support and maintenance for Drupal sites that we didn't build initially. We've learned the hard way which site building mistakes have the greatest potential for creating issues later.

And we've seen a lot of sites! Besides our clients, we also do a FREE in-depth site audit as the first step when talking to a potential client, so we've seen loads of additional sites that didn't become customers.

In the last article, we looked at security updates, badly installed module code and challenges ith "patching" modules and themes, as well as specific strategies for addressing each of those problems. In this article, we'll look at how to do the most common Drupal customizations without patching!

NOTE: even though they might take a slightly different form depending on the version, most of these same pitfalls apply equally to Drupal 6, 7 and 8! It turns out that bad practices are quite compatible with multiple Drupal versions ;-)

4. Patching when it's not necessary

In the last article, we talked about the potential problems with depending on patches and the extra work required to organize them to avoid those problems.

If you want to avoid doing all that extra work, it's best to avoid "patching" (ie. modifying) contrib modules and themes whenever possible!

However, most of the patched modules we see on the sites we audit, are patched to customize things that could easily be customized WITHOUT patching the module!

Here are the most common patches we see:

  • CSS changes
  • HTML template changes
  • Form alterations

All of those things could be done in custom theme or module - patching is totally unnecessary!

Since 99% of Drupal sites include a custom theme, we highly recommend putting those type of customizations in the theme. You could also put them in a custom module, however, we find that people who don't consider themselves "developers" are more comfortable working in the theme than a custom module.

Here's how...

4a. CSS changes

If you only want to make a minor change, you can just add some new CSS rules to your theme's CSS styles which override the CSS from the module. The theme's CSS will always come after the module's CSS, so it'll override it (assuming it's not "less specific" than the module CSS).

But if you want to totally change the CSS from the module, you can copy the CSS file into your theme, "register" it and your theme's version will totally replace the version from the module.

In order to "register" a CSS file in Drupal 6 or 7, you simply add a line like "stylesheets[all][] = MODULE.css" to your themes .info file and clear caches. See this documentation page for a more detailed explanation.

Replacing a CSS file in Drupal 8

Unfortunately, the process for completely replacing a CSS file in Drupal 8 is ... overly complicated. I sincerely hope that this is simplified in later versions or that tools appear to help make this easier. Going from adding a single line to this complex process is a clear loss for Drupal 8, where usually working in Drupal 8 is all wins. :-/

This documentation page covers it in detail, but I'm going to attempt to briefly explain here in order to get you started!

CSS files are registered in "libraries" in the MODULE.libraries.yml file. So, first we need to find the library entry for the CSS file we want to replace. If we wanted to replace "node.preview.css", we'd look in "node.libraries.yml" in the "node" module and see:

drupal.node.preview: # The library name
  version: VERSION
  css:
    theme: # The type of the CSS file - take note of this!
      css/node.preview.css: {} # Here you can see the CSS file we want!
  js:
    node.preview.js: {}
  dependencies:
    - core/jquery
    - core/jquery.once
    - core/drupal
    - core/drupal.form

So, we need to edit our THEME.info.yml and add the following:

libraries-override:
  node/drupal.node.preview: # MODULE/LIBRARY_NAME
    css:
      theme: # this has to come from the MODULE.libraries.yml
        # The original CSS file name mapped to the file in the theme
        css/node.preview.css: css/node.preview.css

Notice that some information from the MODULE.libraries.yml needs to be transferred into the THEME.info.yml (which is what makes this such a pain):

  • The module and library name
  • The CSS file type - 'theme' in this case
  • The path to the original CSS file in the theme (mapped to the path to the new CSS file in the theme)

Then you just clear the Drupal caches and Drupal will use your CSS file instead of the module CSS file everywhere it was originally used!

4b. HTML template changes

All of the HTML that Drupal generates comes from templates in Drupal 8 (*.html.twig files), and most of it in Drupal 6 and 7 too (*.tpl.php files).

To customize one of these templates, simply copy it from the module into your theme, modify if it, and clear the Drupal cache. The next time you load the page, Drupal will use your version instead!

4c. Form alterations

In Drupal, you create forms in PHP by making special arrays that represent the form elements. While a module will create the original form array, there is a mechanism for other modules and the theme to alter forms before they are shown to the user!

Unfortunately, doing this requires understanding a little PHP and referring to lots of docs on the Form API. However, if you were able to patch a module to alter the form, it's only a little more work to alter one in your theme!

Of all the topics discussed so far this is the most "developer-y" and I don't want to overwhelm you, so we're going to cover the "cheaters" process for making form alterations! ;-)

  1. Find the form ID of the form you want to alter. You can view the form in the web browser and then look at the HTML source for a hidden "form_id" input. For example, the login form's id is "user_login": The user login form and the source code showing the form id
  2. Install the Devel module. Never leave this installed on live sites! It's not a security vulnerability, but an attacker could potentially use it to escalate their access after exploiting another vulnerability.
  3. Edit (or create) template.php (D6 & 7) or THEME.theme (D8). If you're creating a new file, be sure to put '<?php' as the first line!
  4. Add a function named like THEME_form_FORM_ID_alter. So, if your theme is "mytheme" and you're altering "user_login", then it'd be:
    <?php
    function mytheme_form_user_login_alter(&$form, &$form_state) {
      dsm($form);
    }
    ?>
    
  5. Clear caches and reload the form. You'll see a cool, interactive array explorer which allows you to drill down into the form array and see what's in there. You can use this to find the thing you want to change:Screenshot showing exploring the form array of the login form via the Devel module
  6. Add PHP code to make our alteration. For example, let's say we want to change the "Username" field to "Nick name":
    <?php
    function mytheme_form_user_login_alter(&$form, &$form_state) {
      $form['name']['#title'] = t('Nick name');
    }
    ?>
    
  7. Reload the page and see your change:Screenshot of an alteration to the user login form without any patches

Note: In the code above, it wraps the "Nick name" in a t() function -- this is to enable translation. If you're site doesn't serve pages in multiple languages, you don't need to use that, but it's considered best practice. Who knows if you'll need to support multiple languages later?

Note 2: The code above WILL work with Drupal 6, 7 & 8, but it technically doesn't follow coding standards for Drupal 8, which should declare the function like this instead:

<?php
use \Drupal\Core\Form\FormStateInterface;
 
function mytheme_form_user_login_alter(&$form, FormStateInterface $form_state) {
  $form['name']['#title'] = t('Nick name');
}
?>

In this article, we covered the 4th pitfall among the 7 we're going to cover in this 3-part series. If you haven't already, please check out the first article!

Have you encoutered Drupal sites that include unnecessary patching? Are there any other important examples that you've encountered when building a Drupal site or reviewing a site built by someone else? Please write a comment below!

Or, if you'd like us to audit your Drupal site, please contact us about a FREE site audit!

Mar 14 2017
Mar 14

myDropWizard offers support and maintenance for Drupal sites that we didn't build initially. We've learned the hard way which site building mistakes have the greatest potential for creating issues later.

Before taking on a new client, we do an in-depth site audit looking for security issues and checking if the site follows best practices or has any problems that would make it harder to maintain the site going forward.

In 2016 alone, we did 64 site audits!

Looking at that many sites has taught us A TON about the most common mistakes that people make when building Drupal sites. Some of them were very surprising to us as experienced Drupal site builders!

This is the first in a series of articles, in which I'd like to share the most common pitfalls we've seen, so that you can avoid making the same mistakes when building your sites!

NOTE: even though they might take a slightly different form depending on the version, most of these same pitfalls apply equally to Drupal 6, 7 and 8! There's bad practices enough to go around that you'll have something to learn regardless of which Drupal you use ;-)

1. Unapplied security updates

I almost feel bad including this because everyone knows you should apply all security updates as soon as possible.

But you'd be surprised! We’ve audited maybe 4 sites where all the security updates were applied. :-)

Here's some pointers for staying on top of security updates:

  • Updates always come out on Wedensday after noon Eastern time
  • You can find all security advisories for core and contrib, as well as security PSAs, on Drupal.org
  • To receive e-mails when new security advisories are posted: edit your account on Drupal.org, click "My newsletters", check the "Security announcements" checkbox and click "Save"
  • Install the "Update manager" module, and see the "Available updates" report to see if there are any unapplied security updates on your site!

We apply all security updates to our customer sites the same day they are released.

Depending on your site and the particular security advisory, you might not need to be so aggressive, but we highly recommend applying any security updates as soon as possible! See our series on Understanding Security Advisories for advice on evaluating security advisories.

2. Multiple copies of the same module at the same "layer"

Let's say you downloaded and installed the Google Analytics module at 'sites/all/modules/google_analytics'. Some time goes by and there's several new releases, and you want to test the latest version on your site. Rather than deleting the old google_analytics directory, you rename it to google_analytics-old -- you know, just in case -- and put the new version at in a new google_analytics directory. You do some testing and everything seems to work, so you're done, right?

Unfortunately, Drupal doesn't use the name of the module directory to decide which copy of the module to use -- it's only looking for .info (Drupal 6 or 7) or .info.yml (Drupal 8) files.

So, if you have both of these files:

  • sites/all/modules/google_analytics-old/google_analytics.info
  • sites/all/modules/google_analytics/google_analytics.info

... Drupal will choose to use one copy of the module as the 'google_analytics' module, but it's impossible to know which one it'll use AND it could change its mind later!

While Drupal is unlikely to flip-flop back and forth constantly, seemingly unrelated changes like server updates, filesystem changes, or PHP version upgrades could cause Drupal to switch to using the other copy.

Also, having the two copies around makes security updates problematic: You might replace the module at 'sites/all/modules/google_analytics' but Drupal is really using 'sites/all/modules/google_analytics-old' so your update had no effect!

We highly recommend making sure there is only ever one copy of a module at the same "layer"! We have an internal script to detect this for Drupal 6, 7 and 8, and it's something we fix for all our clients during the on-boarding process.

(Note: Drupal DOES allow having multiple copies of the same module in different "layers" which override each other in a particular order. For example, if you have the same module in 'sites/all/modules' and 'sites/example.com/modules' the latter will override the former. This is a Drupal feature and isn't necessarily a problem! We're talking about multiple copies in the same "layer".)

3. Unorganized module patches

Drupal is Open Source, and that's great, because it means you can modify (or "patch") the code or use patches provided by other people to fix bugs or add features.

However, depending on patches can be dangerous, because when a new update comes out it's easy to forget to re-apply your patch after making the update (and sometimes you need to change the patch for the new version).

To avoid wiping out patches and breaking critical site functionality, we strongly recommend organizing your patches in some way!

At minimum this could be a special directory with all your patches or a text file with a list of links to the patches.

However, we recommend creating a drush .make file, which is text file that lists the modules, their versions and any patches, which can be used by drush (a Drupal command-line tool) to download your modules and apply the patches. This way, updating a module is just updating the version in the .make file, and running 'drush make' and it'll try to apply your patches against the new version -- if they don't apply any more, you get an error and the update won't happen.

You can use 'drush make' with Drupal 6, 7 and 8 (which is why we use it -- we support all those versions) but if you're doing Drupal 8 development, you can accomplish the same thing with composer, which you'll need to install certain modules and libraries anyway. See this composer plugin for applying patches.

But what if you don't remember what patches you've used already?

If you've lost track, check out the Hacked module! It will compare the module code on your site with the code from Drupal.org at the same version. We use it to create a .make file for all the patched modules when on-boarding a new customer site.

In this article, we covered 3 of the most common site building mistakes that we encounter when taking on a new Drupal site. There's certainly more! In fact, this is only the first article in a 3-part series -- we'll cover 7 pitfalls in total.

Have you encoutered Drupal sites that have these problems? Are there any other important pitfalls that we've encountered when building a Drupal site or reviewing a site built by someone else? Please write a comment below!

Or, if you'd like us to audit your Drupal site, please contact us about a FREE site audit!

Mar 08 2017
Mar 08

by David Snopek on March 8, 2017 - 12:41pm

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 Highly Critical security release for the Services module to fix a Remote Code Execution (RCE) vulnerability.

The Services module provides a standardized solution for building API's so that external clients can communicate with Drupal.

The module accepts user submitted data in PHP's serialization format ("Content-Type: application/vnd.php.serialized") which can lead to arbitrary remote code execution.

This vulnerability is mitigated by the fact that an attacker must know your Service Endpoint's path, and your Service Endpoint must have "application/vnd.php.serialized" enabled as a request parser.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

NOTE: there's a pre-existing, unfixed security issue in the Drupal 6 version of Services from 2013 (see SA-CONTRIB-2013-051 - Services - Cross site request forgery (CSRF)), so using Services in Drupal 6 isn't recommended in general, however, that issue is much less critical than the one announced today.

If you have a Drupal 6 site using the Services module, we recommend you update immediately, or disable the Services module entirely.

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).

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