Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Nov 18 2020
Nov 18

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

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

Drupal core - Critical - Remote code execution - SA-CORE-2020-012

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

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

FYI, there were other Drupal core security advisories made today, but those don't affect Drupal 6.

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

Nov 05 2020
Nov 05

This is a bit of an update to our update to PHP 7 that we did awhile back.

Last week we contacted all of our clients to announce our PHP 7.4 upgrade plans.

Much like the update to accomodate PHP 7, this update will necessitate some changes for some of our Drupal 6 clients.

Thankfully the scope of changes seems to be a bit smaller so far.

The important thing to note is that we are continuing to make changes to keep Drupal 6 and important contrib modules current with modern, supported (and secure) versions of PHP!

Read on to find out more!

PHP 7.4 support for Drupal 6 (and supported modules)

If there won't be any more security support for PHP 7.2 after December 2020, that means Drupal 6 and it's contrib modules will need to run on PHP 7.4!

Any incompatibilities with PHP 7.4 will be addressed in our Drupal 6 LTS fork! You can see our Drupal 6 fork on GitHub.

Contrib modules too!?

For our clients, we fully support their Drupal security - even for our Basic Plan! This means that we'll update the contrib modules used by our customers to work with PHP 7.4 as well! All your favorite Drupal add-ons from Views to CCK to Panels - and most other Drupal 6 modules will updated to work with PHP 7.4! If you're a Standard or Enterprise client, we'll even be covering more obscure modules or even custom code to have some more longevity!

Our interests are aligned on this! If your site does suffer from a security breach, we're here to help you work through it. We'd prefer you to be as proactive as possible!

Will you support Drupal 6 forever?

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

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

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

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

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

Contact Us For More Information About Our Drupal 6 LTS Service

Oct 01 2020
Oct 01

Two years ago, we had a blog post with the same title: So, When Do I REALLY Need to Upgrade From Drupal 7? A lot has changed in the past two years. In the world, of course, but also in Drupal.

Drupal 7 was released on January 5, 2011. It's nearly 10 years old and going strong!
Drupal 8 was released on November 19, 2015 which itself is nearly 5 years old!

Where do our legacy and most used Drupals stand? Read on...

I'm On Drupal 7, So I Have to Upgrade to Drupal 9 by November 2021 2022?

Due to the COVID-19 worldwide pandemic, Drupal 7's End-of-Life has been changed from November 2021 to November 2022. Drupal 8's End-of-Life remains unchanged at November 2021.

If you get support from a vendor providing Extended Support, then you will have service for several years beyond the 2022 cut-off.

Without an Extended Support vendor, you really should look to upgrade to Drupal 9 - or move off Drupal entirely. Maybe all you really need is a static website?

The good news is that you do have that extra time to get thnigs figured out - whether that is securing a partner to help with long-term support or getting an upgrade project underway.

Contact Us Today for a Free Drupal 7 Site Audit

So If I am on Drupal 8 Today, I Have to Upgrade to Drupal 9 by November 2021?

Maybe, but that's not nearly as bad as it sounds. :)

The secret of D9 is that it's really just the next iteration of D8 - it's not going to be a complete rewrite like D8 or D7 or earlier major versions were.

Drupal 9 simply drops deprecated APIs, and updates 3rd party dependencies (like Symfony) - and not much else. In fact, the goal is to allow contrib modules that don't use any deprecated API to be compatible with both D8 and D9, without needing to have two separate versions of the contrib module (like we have always done in the past).

Upgrading from Drupal 8 to Drupal 9 will be more like upgrading from Drupal 8.5 to 8.6.

If you are uneasy about an update to Drupal 9 from Drupal 8, feel free to let us know!

Contact Us Today for a Free Drupal 8 Site Audit

So If I Get Your Service, I Never Have to Upgrade to Drupal 9?

Well...

We've been providing Drupal 6 Long-Term support for over 4 years, and I think we've proven that commercial Long-Term Support (or as it's called now "Extended Support") works! We've made dozens of security releases, and kept hundreds of sites supported and maintained, and plan to continue to do so for a while.

We've even gotten Drupal 6 core and popular contrib modules updated to run on PHP 7.2.

So, if you don't update to Drupal 9, we're going to provide Drupal 7 Extended Support - just like we've been doing for Drupal 6 - for a long, long time!

But if you don't plan to purchase Long-Term Support from us or another vendor, then you really should plan your upgrade by November 2022 for Drupal 7 or by November 2021 for Drupal 8!

Isn't Drupal 7 Dead Already? Be Honest!

The Drupal Community has committed to getting Drupal 7 to work on the newer versions of PHP through November 2022. Drupal 7 needs adjustments to completely work with PHP 7.2. Since the earlier versions of PHP are all being "End of Life" as well, this is a necessary step to keep your Drupal 7 site safe and secure. PHP is the programming language Drupal is built on, so changes in PHP have massive effects on what happens with Drupal! If all of that sounds a little familiar, it's because myDropWizard announced recently that we would update Drupal 6 to make it compatible with PHP 7!

There are hundreds of thousands - if not over a million - Drupal 7 websites still in operation providing all sorts of critical services.

Drupal 7 is far from dead.

How Hard Is it Move to Drupal 9 (from Drupal 6, 7, or 8)?

As mentioned above, as long as you are updated to the latest version of Drupal 8, and your modules and themes are compatible: it should be relatively simple to upgrade from Drupal 8 to Drupal 9!

Since Drupal 9 is going to be so similar to Drupal 8, moving to Drupal 9 (from Drupal 6 or 7) should be pretty much the exactly same as upgrading to Drupal 8. That might be good news - or disheartening.

You have Drupal 6/7/8 and Want Some Guidance? Please feel free to contact us for a free site-audit today!

OK, So How Hard Is It to Move to Drupal 9?

  • Many of the best modules have gotten incorporated into Drupal Core!
  • Still others have been obsoleted by new and better ways of doing things!
  • Many others have largely gotten updates to Drupal 9 compatibility!
  • Simple sites can be relatively easily updated to Drupal 9 from older Drupals!

That said, upgrading for most older Drupal 6, 7 or even 8 sites can still a big investment of time and money. Especially with the events of the past year, we fully understand that some organizations would prefer to just sit tight!

That's what our Extended Support is all about.

D6LTS D7ES (Early Sign-Up)

What's the Short Answer? When Should I Upgrade?

  • Drupal 6? You should already upgrade if you don't have D6LTS. We've been providing Drupal 6 Long-Term Support (and will continue to do so for the forseeable future :-)
  • Drupal 7? You should make plans to upgrade by November 2022 - or make sure you have D7ES engaged before then.
  • Drupal 8? You should make plans to upgrade by November 2021 - but that should be relatively straightforward if you've been keeping pace with updates.

There are all sorts of reasons why organizations don't update to the latest software - most of it boils down to budget. Small organizations with simple sites can't afford thousands of dollars to upgrade to the latest version of Drupal. Large organizations with comparatively complex sites can't always afford the expense of every upgrade either.

myDropWizard has plans to accomodate the needs of all sorts of organizations.

Sep 16 2020
Sep 16

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

Today, there is a Moderately Critical security release for Drupal core and CTools to fix a Cross-Site Scripting (XSS) vulnerability. You can learn more in the security advisory:

Drupal core - Moderately critical - Cross-site scripting - SA-CORE-2020-007

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

FYI, there were other Drupal core security advisories made today, but those don't affect Drupal 6.

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 17 2020
Jun 17

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

Today, there is a Critical security release for Drupal core to fix a (Cross-Site Request Forgery) CSRF vulnerability. You can learn more in the security advisory:

Drupal core - Moderately Critical - Cross Site Request Forgery - SA-CORE-2020-004

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

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

FYI, there were other Drupal core security advisories made today, but those don't affect Drupal 6.

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 20 2020
May 20

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

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

Drupal core - Moderately Critical - Cross Site Scripting - SA-CORE-2020-002

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

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

FYI, there was another Drupal core security release made today (SA-CORE-2020-003) but that one doesn't affect Drupal 6.

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 18 2020
Mar 18

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

The CKEditor module provides one way to integrate CKEditor into Drupal.

Due to the usage of the JavaScript eval() function on non-filtered data in the admin section, it was possible for a user with permission to create content visible in the admin area to inject specially crafted malicious script.

The problem existed in CKEditor module for Drupal, not in JavaScript libraries with the same names, however, it's highly recommended that you update to the latest version of the CKEditor JavaScript library as well, because it also recently fixed some XSS vulnerabilities.

See the security advisory for Drupal 7 for more information.

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

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

Dec 11 2019
Dec 11

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

The Webform module is for making forms and surveys in Drupal. 

It doesn't sufficiently sanitize token values taken from query strings. If a query string token is used as the value of a markup component, an attacker can inject JavaScript into a page.

See the security advisory for Drupal 7 for more information.

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

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

Nov 14 2019
Nov 14

You may have noticed that today the Drupal Security Team marked 16 modules as unsupported, due to the module maintainer not fixing a reported security vulnerability after a sufficiently long period of time.

Among those modules, there were a few very popular ones like Admininistration Views and Nodequeue, which have have reported ~118k and ~40k sites using them, respectively.

Everytime a popular module is unsupported, there's a certain amount of panic and uncertainty, so I wanted to address that in this article, both for the Drupal community at large, and for our customers in particular, because we promise to deploy security updates the same day they are released.

Read more to see our perspective!

Why does this happen? Why all at once?

For modules supported by the Drupal Security Team, security vulnerabilities are reported to a private issue tracker.

The Security Team's job is to make sure that the process is followed, security advisories (SA's) get written, and ultimately publishing the SA's, releases and the various notifications.

It's actually the module maintainer's job to fix the vulnerability, write the first draft of the SA, and create the release.

If a module maintainer is unresponsive, the security team will tell the module maintainer that they have 2 weeks to post an update. Since this is an Open Source project, and most maintainers are volunteers doing this in their free time, they frequently get much more than 2 weeks.

When there aren't any other big security releases, and the security team has time to do it (the security team is also volunteers!), they go through all the modules that got the 2 week warning and didn't respond, and mark all of them as unsupported. That's why they tend to come out in groups.

How should I react if I depend on one of these modules?

In an SA about a module becoming unsupported, there are two recommended actions:

  • Uninstall the module, or
  • Apply to become the maintainer of the module and fix the vulnerability

There's actually a 3rd possible action that can apply to very popular modules:

  • Wait for a new maintainer to be found and a fixed version to be released

When modules become unsupported, especially if it's a popular module, there can be some amount of panic. And in a way, that's good!

For popular modules, the security team will sometimes search for a new maintainer through private channels before marking a module as unsupported, but it's hard to do because the details need to remain confidential.

If that doesn't work out, marking a module as unsupported is a more public way to advertise for a new maintainer - and because of the added urgency/panic - it frequently works!

Now, if you depend on a module, and have the skill and time to become the maintainer, you should absolutely consider applying to maintain the module!

But if you don't, it can be reasonable to wait a few days to see if a new maintainer steps up, before taking the drastic step of uninstalling the module. Right when the SA is published, the details of the vulnerability are still private, and unless stated in the SA, there aren't any known instances of the the vulnerability being exploited in the wild.

However, after a period of time, the security team may publish the details of the vulnerability publicly, or attackers may figure it out on their own, so you can't wait forever! But waiting a few days is not an unreasonable calculated risk.

How we handle this with our customers?

It depends on the situation.

For a very popular module, where we're pretty certain a new maintainer will step up, we'll usually wait a few days. (We also have an idea of the security risk in the vulnerability, because we have a security team member on staff, so that's taken into account as well.)

In some cases, we may even offer to maintain the module ourselves.

And, in other cases, like for really unpopular modules, we'll tell our customers that they should uninstall it and replace it with an alternative module or custom code. That's something we can help our customers to do, however, it's only included in our support plans that have a bucket of developer hours - for other customers, we'll need to do a paid mini-project for a few hours.

For our Drupal 6 Long-Term Support (D6LTS) customers, we also have the option of waiting until the vulnerability is made public, and then we can make a D6LTS patch for it, even if the Drupal 7 or 8 module is still unsupported without an active maintainer.

But no matter the situation, we hope to help our customers be ready for whatever may happen. :-)

Jun 26 2019
Jun 26

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

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

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

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

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

See the security advisory for Drupal 7 for more information.

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

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

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

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

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

May 21 2019
May 21

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

Long-Term Support isn't glamorous or exciting.

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

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

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

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

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

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

May 17 2019
May 17

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For an individual site - nothing!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

To add the repository, run this command:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

May 08 2019
May 08

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

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

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

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

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

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

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

Apr 17 2019
Apr 17

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

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

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

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

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

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

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

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

Apr 02 2019
Apr 02

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

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

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

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

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

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

Read on to find out more!

Why February 24th, 2022?

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

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

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

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

There's still TONS to do Drupal 6

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

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

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

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

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

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

What are your plans for Drupal 7?

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

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

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

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

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

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

Will you support Drupal 6 forever?

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

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

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

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

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

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

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

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

Mar 20 2019
Mar 20

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

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

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

Thanks!

Mar 14 2019
Mar 14

We're continuing our popular "Support Wizard Help Desk" at Drupalcon 2019! Book some time with myDropWizard for some FREE help with your Drupal site!

You're a first time Drupalcon attendee? You're a veteran Drupaler? Either way, you made part of your Drupalcon mission to fix a lingering issue - or at least to be pointed in the right direction!

We're here to help!

We spend our days helping Drupalers just like you every day with their support needs, so we thought "Let's bring that myDropWizard Support Face-to-Face with Drupalers: FOR FREE!"

So, drop by Booth #811 or (better yet!) schedule with us below!

Where we'll be and when

  • Our booth: We again sponsored DrupalCon this year and will have a booth in the exhibit hall! We're in booth #811!
  • Everywhere! Just like you we want to get around the convention to see everyone and everything. Stop us and say "hello!"

Schedule a one-on-one meeting

Again, we'll be happy to discuss your current challenges (or successes!) anywhere at Drupalcon, but if you want to be double extra sure that you'll be able to chat with us, schedule a one-on-one meeting with us!

We like to keep things simple, so just drop us an email to schedule a meeting with either Elliot or David:

[email protected].

Can't wait to see you there!

We're super friendly, non-imposing people who love Drupal and the Drupal community. :-) We all look forward to hearing how your organization is using Drupal and how we can help! Have a great week in Seattle!

Mar 13 2019
Mar 13

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

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

This module enables you to create customized lists of data.

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

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

See the security advisory for Drupal 7 for more information.

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

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

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

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

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

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

Mar 06 2019
Mar 06

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

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

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

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

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

See the security advisory for Drupal 7 for more information.

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

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

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

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

Mar 06 2019
Mar 06

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

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

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

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

See the security advisory for Drupal 7 for more information.

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

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

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

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

Feb 27 2019
Feb 27

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

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

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

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

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

See the security advisory for Drupal 7 for more information.

Here you can download:

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

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

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

Feb 20 2019
Feb 20

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

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

The Link module provides a field for storing links.

The module didn't properly validate the field data.

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

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

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

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

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

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

Feb 12 2019
Feb 12

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

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

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

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

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

Read the full article to find out how!

Background: Why is this hard?

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

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

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

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

The Magic of Composer

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

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

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

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

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

The peculiarities of CiviCRM

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

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

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

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

TL;DR - What are the commands?

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

First, you need to have the following installed:

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

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

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

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

composer require civicrm/civicrm-asset-plugin civicrm/civicrm-drupal-8 civicrm/civicrm-packages

If you have a Drupal 8 site that isn't composerized, well, you're going to need to convert your site.

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

Installing CiviCRM

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

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

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

Hopefully, all these bugs will be fixed in time.

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

How does it work?

There are two parts to this:

It does the following:

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

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

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

(UPDATE 2020-04-21: Going forward, please use the civicrm/civicrm-asset-plugin and participate with the CiviCRM community to improve it!)

Conclusion

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

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

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

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

Feb 06 2019
Feb 06

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

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

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

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

See the security advisory for Drupal 7 for more information.

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

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

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

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

Jan 16 2019
Jan 16

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

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

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

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

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

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

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

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

Jan 03 2019
Jan 03

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

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

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

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

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

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

Lessons learned from Drupal 6 LTS

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

The age/visibility of the code doesn't matter

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

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

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

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

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

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

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

Many issues affected Drupal 6, 7 & 8

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

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

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

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

Keeping up with PHP is going to be a thing

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

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

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

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

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

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

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

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

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