by David Snopek on March 4, 2016 - 8:20am

If you still have a Drupal 6 site and use the 'update' module, you probably noticed that you're no longer getting accurate information about security updates on the "Available updates" report. In fact, it's telling you to disable all your modules, which isn't very helpful. :-)

This is because after February 24th, Drupal 6's End-of-Life date, all Drupal 6 modules on were marked as unsupported. This was always part of the plan, because the Drupal community wants to stop supporting Drupal 6, and leave that work to the Drupal 6 Long-Term Support (LTS) vendors.

However, it had an interesting side-effect!

If a module is marked as unsupported, the 'update' module won't tell you about available security updates for that module!

This is particularly problematic because there were 2 big security releases on February 24th as well: Drupal 6.38 and FileField 3.14. If you didn't update right away on February 24th, then on February 25th, there was already no mention of those security releases on the "Available updates" report. (Those two in particular are temporarily marked as supported, so you should actually see them now.)

And if you only do security updates every few weeks or months, then you could be unaware of even more security releases made before the update status information become unreliable.

(Note: While it's NOT recommended to wait that long, the reality is that people with small budgets can only pay someone to perform updates once a month, or every few months. We apply security updates same day for our customers, but not everyone can afford that.)

However, we've created an alternative to the 'update' module which will allow you to get accurate information about security updates, both past, and going into the future with releases from the Drupal 6 LTS vendors!

Introducing the myDropWizard module

We've created a new module, myDropWizard, which is essentially a fork of the 'update' module, with a couple important changes:

  1. It still shows security updates if a module is unsupported, so you'll know about security updates you haven't applied, regardless, and
  2. It uses an alternate data source that reports whether a module is supported by the Drupal 6 LTS vendors, so you'll know if it'll be getting security updates going foward
  3. It will let you know about additional security updates made by the D6 LTS vendors! The LTS vendors are required to post their patches publicly, but there won't be any Security Advisories going out to let people know
  4. Integrates with 'drush ups' and 'drush dl'. If you have this module installed, and use at least Drush 7 (works with PHP 5.3 and up), it will tell Drush to use our data as well!

While it uses a different data source, it continues to report usage information back to, so the community won't lose that valuable resource. This will let us know how many people are still using Drupal 6 in the next months and years!

And you don't have to be a myDropWizard customer to use this module! It's free to use by anyone!

Note: We're still compiling data on which modules are supported or not by the LTS vendors, so expect that to fluctuate and be a little inaccurate for a week or two. Thanks for your patience!

So, if you're still running Drupal 6 and you want more accurate information about security updates going forward, go get the module now!

Answering some likely questions...

If you just want accurate update information, you can stop reading this article now - you've already got everything you need!

However, I anticipate the Drupal community is going to have some technical questions about why we implemented this the way we did, and so I'd like to preempt a few of them. :-)

Why did you fork the 'update' module, rather than provide a compatible alternative data source or use hook_update_status_alter()?

Well, we considered it, and that even was the original plan. The 'update' module actually consults a variable for the URL to use for the data, and we were just going to change it to point to our servers.

However, on further evaluation, we realized that we'd need to make some deeper changes to the way the module processes that data, and provides its messaging.

Namely, we needed to get it to still tell users about security updates even if a module is unsupported, and change the messaging to tell users about what unsupported really means after Drupal 6 End-of-Life. Telling users to disable all unsupported modules isn't really good advice anymore (especially when it likely affects half their modules).

While we could have accomplished this with hook_update_status_alter() and replacing theme functions, that would have been a lot of hacky, awkward code.

Also, we realized that we needed to slightly change the way the data source worked! More on that in the next question...

Why is your data source (ever so slightly) incompatible with the update status information on

It turns out that the way update status information is served from is terribly, terribly inefficient. :-/

First of all, the update status information for each project is stored in relatively large XML files. We considered converting them to JSON (and we still may do that down the line), but didn't go that far just yet. :-)

Second, the end-point for recording usage information is the same as the end-point for getting the XML files, there's just some GET arguments added to the URL with the info needed to record usage statistics. That means the XML files have to be served via PHP, rather than directly by the webserver.

We don't have the server resources to handle 100-200 dynamic, uncached requests (one for each module) everyday for each site that uses our update status information.

So, our fork does a single HTTP POST with the usage information (which goes to our server and is then proxied back to as individual requests, so the statistics end up on, and an HTTP GET for each module's static XML file (which is handled by the webserver, not PHP).

If we start having trouble handling even that, we can move the static XML files to S3 or put our updates site behind a CDN (which is something we couldn't do without making these changes).

Why did you call this module 'mydropwizard' and not something more generic like 'd6lts_update'?

Well, we could have provided this only to our customers by requiring some kind of special key in order to access the data (like many APIs do) and then we wouldn't have had to worry about the server resources it'd take up (our customer list isn't that huge), and we'd be getting paid for it, which would be pretty nice. :-)

But we wanted to provide this to the whole the community for FREE, since it's really something that every Drupal 6 site needs in order to remain secure, even if they can't afford a Long-Term Support plan.

So, we decided to call it 'mydropwizard' so we could write off the expense of maintaining it as an advertising cost. Some people who didn't know about us before, might learn about who we are and take a look at our support plans.

If you have any other questions (that I didn't preemptively think of) please ask in the comments below!

Want to read more articles like this? blog Subscribe to the blog and recieve e-mail updates when new articles are published!


Sounds like a great idea and way to serve the community.

> It turns out that the way update status information is served from is terribly, terribly inefficient. :-/

Given what you have learnt during investigating the d.o update service & core module and developing this new service & module, can you contribute suggestions for improvement back to the d.o service & core update module? Otherwise D6 now has a better service than D8, which would be a shame to remain that way! ;-)
I don't know how possible it would be for the d.o service interface to change, or at least remain backwards-compatible, but some of the improvements you've implemented for your service would be great to have.

Thanks, James!

Given what you have learnt during investigating the d.o update service & core module and developing this new service & module, can you contribute suggestions for improvement back to the d.o service & core update module?

I know that the DA and infrastructure team specifically has discussed changing the way update status information is served in the past and wants to improve it. But they have loads of important things that need their attention and I suspect this is just a little lower on the priority list. :-)

I'd be happy to participate in any public discussions/issues aiming to improve this! That said, the changes I made so far are extremely minimal -- basically, the smallest changes that could make this viable for us. I have a branch where I made much more drastic changes (including changing the data to JSON) but backed down on that in order to get something out fast.

If we rethink how the official status information is served by, I think we should make big changes and re-evaluate everything, since we'll be stuck with whatever we come up with for a long time. Making even small changes is hard (or impossible) to keep backward-compatible, so we may as well go all the way!

This is a really nice contribution. Even thought D6 support is no more, the painful truth is that there are many D6 sites out there, with site owners do not want to upgrade, or do not have budget. I no longer maintain sites on a regular basis for any of my sites, but this would be a really easy way for those who do, and will save lots of time checking the SA list, project page for each project for each client.

I also liked that you getting down with the "Why did you call this module 'mydropwizard' and not something more generic like 'd6lts_update'?" topic. Thank you!

I am one of the folks still supporting Drupal6 sites, so MyDropWizard is important. When I used 'drush pm-updatecode', I got the error 'Command pm-updatecode needs the following modules installed/enabled to run: update.' The solution was to run 'drush en update', update the modules and then 'drush dis update'.

Thanks, Norbert!

Hm. If you're getting that message, it means that drush isn't using mydropwizard for some reason. And that means that by installing the 'update' module and running 'drush pm-updatecode' you're actually getting the old, obsolete data from, which has more projects marked as unsupported and is missing a security update for prepopulate, and will be missing even more updates as time goes on.

What version of Drush are you using? The 'mydropwizard' module can only integrate with Drush 7 or later, so you might need to update Drush. It also depends on the 'mydropwizard' module being enabled and Drush being able to bootstrap Drupal. So, if you're using multisite, you'll need to run Drush from inside the site directory (rather than just at the Drupal root) or use the appropriate Drush alias.

I hope that helps! If you have any more problems, please open an issue in the queue:


hello David,

we are actually drupal 6 site maintainers. Drupal 6 now reached eol. We have installed myDropWizard module get drupal LTS security updates. Our clients not willing to offer too much money for security updates. if we want get security patches is there any open source links where these security patches are available.

Thank you.

So, if you're using the mydropwizard module, it will actually give you information about the security releases created by the Drupal 6 LTS vendors. For example, if you use the Prepopulate module, it will tell you about a 2.3 release which doesn't exist on, but that we created which includes the security fix for SA-CONTRIB-2016-009 which was created by the LTS vendors.

That said, the LTS vendors don't support all contrib modules! We only support the modules used by our customers. So, if a vulnerability is found in a module that none of the vendors support (for example, like the recent vulnerability in the Hybridauth module) the fix won't be ported to Drupal 6.

So, while you could make customers safer by using the D6 LTS releases we make, there might not be releases for all the security vulnerabilities that affect a customer.

Add comment