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 Drupal.org 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:
- It still shows security updates if a module is unsupported, so you'll know about security updates you haven't applied, regardless, and
- 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
- 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
- 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 Drupal.org, 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 Drupal.org?
It turns out that the way update status information is served from Drupal.org 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 Drupal.org as individual requests, so the statistics end up on Drupal.org), 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!