Running
drush ups
on any D6 site now returns this:

Name                                        Installed Version    Proposed version     Message
 Drupal                                      6.37                 6.37                 Installed version not supported
 Acquia agent (acquia_connector)             6.x-2.17             6.x-2.17             Installed version not supported
 Administration menu (admin_menu)            6.x-1.8              6.x-1.8              Installed version not supported
 Backup and Migrate (backup_migrate)         6.x-2.8              6.x-2.8              Installed version not supported
...

This means that drush cannot detect nor update any remaining module updates, nor can it apply the current core update. While D6 is deprecated, turning off this functionality seems hasty until updates can be reasonably applied.

Proposed resolutions

From comment #32:

Based on the discussion last night, looks like what is going to happen is (please correct me if I am wrong or expand if I missed something):

- Update status information on drupal.org will be different based on reporting Drupal 6 version, so we can tell pre 6.38 users to update to 6.38. The standard "unsupported" marking affected all versions, so we cannot use that, manual changes are needed. This resolves the immediate concern with the incorrect information.
- We may release Drupal 6.39 with better messaging in place of update status' reporting which points people to a landing page on drupal.org to figure out their further options. There was no firm decision on this point AFAIR.

The issue to discuss a proposed Drupal 6.39:

#2678882: Release to improve LTS messaging in Update status

David Rothstein suggested some alternative approaches in #36.

And an update status alternative from one of the Drupal 6 LTS vendors in #41:

We've finally (sorry for the delay) published our alternative to the 'update' module (it's a fork):

https://www.drupal.org/project/mydropwizard

It does two main things:

  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 Long-Term Support (LTS) vendors, so you'll know if it'll be getting security updates going foward

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.

Comments

mariagwyn created an issue. See original summary.

mariagwyn’s picture

Issue summary: View changes
mariagwyn’s picture

Issue summary: View changes
kbruck’s picture

This is really not good as one cannot update to the latest release using drush any longer.

Is there any quick fix available?
(The Info about the releases is still accessible here: https://updates.drupal.org/release-history/drupal/6.x - maybe one can manipulate the XML for easy upgrading?)

Github issue: https://github.com/drush-ops/drush/issues/2024

chriso’s picture

Title: D6.38 core update cannot be applied with drush due to deprecated status » D6.38 core update cannot be applied due to deprecated status
FileSize
124.52 KB

Just confirming this isn't merely Drush; clean D6.37 via admin/reports/updates sees the same.

moshe weitzman’s picture

Right - and it isn't just core. Contrib projects no longer show their most recent stable release because that release is unsupported.

mariagwyn’s picture

For what it is worth, as a long-time user of drupal (4.6) and a builder and maintainer of small, non-profit sites, this decision undermines the power of drupal as an open-source project which can run small or large sites. This is a great example of how the developer/builder mindset which drives drupal (and makes it wonderful) as opposed to site-maintainer mindset falls short. There is just no NEED to turn that feature off, certainly not the DAY AFTER the core release.

David_Rothstein’s picture

Project: Drupal core » Drupal.org infrastructure
Version: 6.38 »
Component: other » Updates System
FileSize
55.78 KB

I think this is a drupal.org infrastructure issue rather than a Drupal core issue, so moving there.

Comparing the results from Drupal 5 to Drupal 6 there does seem to be a problem.

For core:
https://updates.drupal.org/release-history/drupal/5.x
https://updates.drupal.org/release-history/drupal/6.x

For contrib:
https://updates.drupal.org/release-history/views/5.x
https://updates.drupal.org/release-history/views/6.x

So the big difference is that almost all of the releases have gone missing for Drupal 6. (A second difference is that <project_status> is set to "unsupported" for Drupal 5 but "insecure" for Drupal 6. At this point, at least, "unsupported" would make more sense.)

I guess the Drupal 6 releases were removed to make sure they don't appear as recommended releases on project pages? But I think there is probably another way to do that; I don't see Drupal 5 downloads on project pages anymore either.

The problem with the current situation can be seen in this screenshot from the Update Status module on a test Drupal 6 site:

So the core entry looks strange but a bigger issue is that the contrib module (Views in this case) isn't even recognized anymore. So there is no link to the project page which people could use to go and manually download the latest release.

Ideally both of these would just be labeled as "unsupported" in this screenshot. I think if the updates.drupal.org data for Drupal 6 were switched to something more like Drupal 5 that would happen.

Even with that, the Update Status module in core may not be smart enough to recommend security releases for unsupported projects. (Ideally what it would do, if you're on Drupal 6.37, is recommend Drupal 6.38 as a security update - but then additionally, or at least once you're on Drupal 6.38, let you know that the project is unsupported.) But if the release data is restored, then this feature could be implemented somewhere else, such as Drush. I would think that "I know I'm using an unsupported project but I still want to update to the latest release of that unsupported project" is a reasonable feature request for Drush or elsewhere -- not just for Drupal 6 but also more generally.

mlhess’s picture

This was done as part of the EOL support. We have a meeting to chat about it how to fix it later on today.

David_Rothstein’s picture

Title: D6.38 core update cannot be applied due to deprecated status » Drupal 6 projects don't show up correctly in Update Status and Drush due to the way updates.drupal.org marked them as deprecated
basic’s picture

#9 is right:

unsupported is the correct project status for Drupal 6 core. I've fixed this in its XML.

Drupal's update module has a limited set of messages available to display, none of which are 100% accurate for the EOL. This behavior may be worthy of a patch to core to improve this process for D7/D8.

As mlhess said, we are meeting today to discuss our options (they are limited) and what the best way to fix this will be.

kgale’s picture

Thanks to all for reviewing the situation and improving upon it. I'm not familiar with the technical mechanisms involved but as a service manager and manager of projects it seems like the sequences of events happened like this:

1. D6 reaches EOL (adieu!)
2. Final security update is released (good)
3. The vulnerability is detailed to the world by virtue of the security release (that's how it works)
4. The most common mechanism for applying the update is essentially disabled (not good)
5. Lots and lots of D6 sites are left insecure because so many will not use alternative update methods (really not good)

David_rothstein's final paragraph in #9 sums up the desired end state in my view. Those with out-of-date, EOL'd versions can still use the Update module to see what is out of date and they can still use drush to get up-to-date with the latest available releases while it's still made clear the project is no longer supported and no additional security updates will be forthcoming.

japerry’s picture

To add for contrib:

Just because Drupal 6 core is not supported doesn't necessarily mean that all contributed modules are not supported or won't have updates either. Its unfortunate that the last release of Drupal 6 didn't have a change to the update status.

I would like the ability to EOL my D6 modules on our own timeframe. There is php 5.4 work being done which will require another views update, probably an update to ctools, and probably other modules as well.

David_Rothstein’s picture

@japerry, from a security perspective both core and contrib are unsupported, not just core.

That said, as far as I know nothing stops you from continuing to create Drupal 6 contrib releases; my guess is they'd show up via the "View all releases" link at the bottom of the project page (just not under the "recommended releases" section).

But then the big question here is whether something can be done so that Update Status and/or Drush is able to tell people about those releases directly on their sites.

mlhess’s picture

An update on this issue

With the end of D6 support. we flagged all d6 modules as "errors" in updates.drupal.org indicating the module is no longer supported. Rather than providing the XML, we just gave an simple error message.

We have backed out this change, as you can see here: https://updates.drupal.org/release-history/views/6.x

With core, we did show there was an update with a manual xml file being provided by our CDN fastly.

The other change we made, was to auto flag all d6 modules as unsupported. However, while the greater community is not supporting 6.x a module maintainer might want to and now they don't have that option. So as PHP 5.6 or PHP 7 comes out they could update their modules with better support.

Moving forward, we will by default mark the d6 modules unsupported, however, a maintainer can mark their module supported.

We are working on some of the back end changes for the above and will update this issue.

mlhess’s picture

I forgot to add, that any maintainer that does add their releases back should get a warning that Drupal 6 is not longer supported by the security team.

drumm’s picture

Our next step is to allow projects to return D6 versions to their project pages, on an opt-in basis:

  • Mark all D6 (and lower) releases as unsupported, unrecommended, and hide the “snapshot” releases too: UPDATE project_release_supported_versions SET supported = 0, recommended = 0, snapshot = 0 WHERE tid IN (87,78,79);
  • Re-enable general support for D6 releases on the API compatibility term’s edit page.
  • Re-check core’s 6.x support, so it shows on http://drupal.org/project/drupal until no longer needed.
  • Project maintainer’s can take that same action on their admin releases pages.
drumm’s picture

Status: Active » Needs review

#18 is done, except for re-adding core. We might not put it back in the same way. The current draft is:

The final Drupal 6 security release is Drupal 6.38. Upgrading sites running 6.37 and lower is recommended.

drumm’s picture

The copy in #19 has been deployed.

No more immediate changes are planned on Drupal.org. Please update this issue if anything new comes up, or mark Fixed if things look okay.

japerry’s picture

Priority: Normal » Critical
Status: Needs review » Needs work

Thank you mlhess and drumm for making the changes so far to bring this back

However, I'm marking critical, because this is affecting thousands of Drupal 6 sites that are being incorrectly told they are insecure. This should not wait until next week.

At this point, since the opt-in change has been made for contrib projects, we should revert back the core unsupported option on the project page to 'supported' but not 'recommended' -- this should fix this issue. We can then come back and figure out a better way to show updates.. whether that is Drupal 6.39 because of this bug or just keeping drupal.org 6.x releases enabled for a period of time.

But the key issue is that we're mixing up messaging about Drupal 6 not being supported by the security team and drupal 6 being not secure and un-updatable. In fact, we have LTS contracts to keep people running drupal 6. we shouldn't be pre-emptively scaring away users.

japerry’s picture

Update for screenshot

japerry’s picture

An update of the problems, and remedies taken.

Core

versions of Drupal 6 prior to 6.38

These were showing as 'unsupported' instead of 'needs security update'

version of Drupal 6 at 6.38

Showing as 'security update required' when 'insecure' was inserted into the xml update script. This has since been removed, and 'unsupported' is showing instead.
This is desired. However, changing this to 'unsupported' causes earlier versions to not prompt for the security update, which negates the whole update system in the first place.

Cannot drush dl or drush up or drush ups

Without D6 being supported, drush fails to update.

Contrib

Modules do not show 'needs update' or 'needs security update'

This problem is likely similar to the core problem, where unsupported overrides the update mechanism.

The only remedy for this, so far, is by marking the module as supported, not recommended (could also add recommended but in general, modules shouldn't be doing that.)

Short Term Fixes

Re-enabled D6 as a 'supported' release

Because of the severity of updates breaking for all D6 sites, I marked Drupal 6 as supported. In the EOL agreement, we said that 'sometime in the future' changes to the update system would eventually break. I don't believe users believed that future to be only days after. Its certainly better than letting Drupal 6.37 sites think that they don't need an important security update to 6.38.

Re-enabled the 6.x taxonomy term

Drumm earlier re-enabled the ability to mark Drupal 6 as supported.

Long Term Fixes

There are a few options that have been suggested:

  1. If we were able to provide custom xml responses as mlhess and mixologic have discussed, we could probably have our cake and eat it too.
  2. Make a Drupal 6.39 release that includes fixes to the update system so we can mark it as unsupported but still utilize the update system to provide updates when modules make releases
  3. Keep Drupal 6 as 'supported' (aka do nothing) and use other messaging to make it clear that D6 is end-of-life
japerry’s picture

I also re-enabled filefield as a supported (but not recommended) release so Drupal 6 sites know that they should update to the latest version.

joshuami’s picture

I approve the fix to make sure that the messaging correctly tells people that they should upgrade if they are not running the latest security patch on Drupal 6 core and filefield. The messaging on contrib still needs some work, but it is consistent with what we've had since Wednesday.

We can pick this back up on Monday when we have the right people around and spend some time thinking this through a bit more.

Gábor Hojtsy’s picture

Tried pinging a few people on the thread, but no success so far. Let me know if I can be of help on this discussion. While it would be unusual to release 6.39, if that is the best choice, we can definitely do it.

dsnopek’s picture

myDropWizard (one of the Drupal 6 Long-Term Support vendors) is going to create an alternative to the update status from Drupal.org.

Since update status on Drupal.org for Drupal 6 doesn't appear to be going anywhere (at least any time soon) and some module maintainers are continuing to support their Drupal 6 modules, I think this is going to work by taking the update status for a module from Drupal.org and then making some changes to it if that module is supported by the LTS vendors (ie. marking it as supported, and maybe adding some new releases if there are security releases beyond what's on Drupal.org).

I think an alternate data source like this is a better solution than messing with how things are marked on Drupal.org, because it kinda breaks the semantic meaning of this data (ex. marking the Drupal 6.x branch as supported, even when it's not actually supported by the Drupal community dilutes the meaning of "supported" on Drupal.org).

We're going to make this data public and won't be charging for it or restricting it to our customers. Assuming we can get lists of supported modules from the other vendors, we'll mark the modules they support as supported as well.

I'm not sure if this will affect what you folks end up doing, but I just wanted to let you know! I'll post again when this is online (hopefully, today or tomorrow).

drumm’s picture

A couple options that could help:

Since update status reports the version the site is running, we might be able to serve different XML to sites using 6.38. We should double check that drush makes the same request as core update status.

A Drupal 8 stub release in the 6.x branch could work. That wouldn't include any file URLs, or otherwise disable drush actually attempting the update. I expect that might show up as a newer version available in update status, triggering the yellow status. This is completely theoretical and would need testing.

kgale’s picture

japerry's comments in #21 and #23 ring true to me and it would be prudent to plan this into future versions. From a business or site management perspective, the term "supported" or "unsupported" as embodied in the update system seems to merge important distinctions that should be functionally separate.

Say a university has 150 D6 sites that are decentrally managed (not an uncommon scenario). Yes, the university should have moved to D7 before now, but given available budgets and resources, it wasn't possible. For cost savings, the teams have decided to instead rebuild on D8 given the promised capabilities. D8 and the contrib space are not mature enough to deliver on all the necessary functionality yet so the teams need to wait until sometime in 2016 or even 2017 to get started. In the meantime, all teams need to make sure the D6 sites are running the last released D6 core and contrib security updates. Any important changes made to key contrib modules will need to be applied while the organization transitions to D8 over time.

What site administrators need to know is:

  • Is the security team active on any D6 core or contrib security issues? (Nope. EOL.)
  • Is my site running the latest available security updates?
  • Are other updates available for my site?

What the site administrators need to do is:

  • See if core and contrib modules are running the latest released security updates right now.
  • Use Drush to apply core and contrib security updates.
  • Periodically see if contrib updates available.
  • Use Drush to apply contrib updates as needed.

Thanks again to all who are spending time addressing this. It seems to be an important issue given the number of organizations who find themselves in a similar position as the example I gave even if they have fewer sites.

dsnopek’s picture

What site administrators need to know is:

- Is the security team active on any D6 core or contrib security issues? (Nope. EOL.)

However, the D6 LTS vendors (all of whom have Drupal Security Team members on staff) will be making public security patches for core and select contrib modules, following the same basic processes as the security team. Site administrators may also be interested to know which of their modules will be supported by the D6 LTS vendors. :-)

kgale’s picture

Excellent point.

Gábor Hojtsy’s picture

Right, so that support does not come from Drupal.org, so drupal.org does not say things are supported. We don't have community resources to maintain / provide that information, make releases, etc. That is the kind of information that @dsnopek's custom service plans to provide instead.

Based on the discussion last night, looks like what is going to happen is (please correct me if I am wrong or expand if I missed something):

- Update status information on drupal.org will be different based on reporting Drupal 6 version, so we can tell pre 6.38 users to update to 6.38. The standard "unsupported" marking affected all versions, so we cannot use that, manual changes are needed. This resolves the immediate concern with the incorrect information.
- We may release Drupal 6.39 with better messaging in place of update status' reporting which points people to a landing page on drupal.org to figure out their further options. There was no firm decision on this point AFAIR.

joshuami’s picture

Added in the related issue created from the conversation yesterday.

David_Rothstein’s picture

- We may release Drupal 6.39 with better messaging in place of update status' reporting which points people to a landing page on drupal.org to figure out their further options. There was no firm decision on this point AFAIR.

I am wary of doing a Drupal 6.39 release. We already declared Drupal 6 unsupported, which means no more releases, so this just muddies the water. And what we're talking about here is a relatively minor enhancement.

As an alternative, isn't it possible (perhaps even easy) to write a Drupal 6 contrib module that uses hook_update_status_alter() to show the site administrator all available unapplied updates, even for projects that drupal.org has marked unsupported? Then the recommendation could simply be that Drupal 6 sites install that module if they want to continue doing updates past the end-of-life.

Update status XML for Drupal 6.37 and lower will continue to show "not secure" messaging
....update status XML for Drupal 6.38 will show "not supported" messaging with project link pointing to drupal.org/about/drupal6-lts

Varying the status like this seems like a clever short-term solution (i.e. for the next few weeks or so). But in the long run I think we do need to show "not supported" messaging for older Drupal 6 sites also. We know that most sites won't ever upgrade to Drupal 6.38 (just like they didn't update to 6.37, 6.36, etc) but they still need to see that Drupal 6 is no longer supported.

Also, any messaging here should focus on end-of-life (EOL), not long-term-support (LTS). LTS is one option for people still running Drupal 6 sites, but not the primary recommended one. I think links should be to https://www.drupal.org/drupal-6-eol (or a similar page) that focuses on the overall EOL status and what it means, not to pages that focus on LTS specifically.

David_Rothstein’s picture

Also, perhaps once this is all ironed out there should be a public service announcement (PSA) at https://www.drupal.org/security/psa reiterating the end-of-life date and explaining what the final behavior of Update Status will be, etc?

As we learned from "Drupalgeddon" there is a huge population of site administrators out there that reads the security PSAs but that does not tend to see announcements that are made elsewhere.

David_Rothstein’s picture

Actually I think we have some other options here. This is partially based on @drumm's suggestion in #28 (which I didn't fully understand when I first read it, but once I got it, it definitely seemed worth exploring):

A Drupal 8 stub release in the 6.x branch could work. That wouldn't include any file URLs, or otherwise disable drush actually attempting the update. I expect that might show up as a newer version available in update status, triggering the yellow status. This is completely theoretical and would need testing.

I didn't try that suggestion exactly, but I came up with a couple variations that might work instead. I'm attaching screenshots of both. The patches used to generate this are also attached (these patches are hacks to the Drupal 6 Update Status module showing how the drupal.org XML would have to change; in actuality we'd change the XML directly so this wouldn't require any patches to core).

Simple Option

This requires only minimal/simple changes to the data updates.drupal.org would need to return.

Here's what it produces for the Drupal 6.37 available updates page:

And for the Drupal 6.37 status report:

And here's what it produces for the available updates page after updating to Drupal 6.38:

And for the Drupal 6.38 status report:

Not perfect (and doesn't meet my goal of showing "unsupported" for everyone) but clearly an improvement over the current situation.

It doesn't give direct download links either, but that's actually a good thing - the user will be forced to go to https://www.drupal.org/project/drupal to get the downloads, and we can put a link about the Drupal 6 EOL there.

Complex Option

This requires more complicated changes to the updates.drupal.org data (since it would need to add information about Drupal 7 releases to the Drupal 6 XML).

Here's what it produces for the Drupal 6.37 available updates page:

And for the Drupal 6.37 status report:

And here's what it produces for the available updates page after updating to Drupal 6.38:

(The Drupal 6.38 status report in this case is the same as the Drupal 6.37 one.)

Again not perfect, but an improvement over the current situation.

Other notes

I haven't tested these with Drush but I assume they would work similarly.

As can be seen from the screenshots this doesn't affect contrib modules - but I guess those are less important as long as core is marked "unsupported".

David_Rothstein’s picture

Looking over both I would lean towards the simple option myself. The in-site messaging is pretty close to what we'd ideally want, and the fact that it forces users of any Drupal 6 version to go to the Drupal core project page before attempting an update is a good thing because there can be EOL messaging there which can be edited/changed/improved at any time (rather than tying the messaging to code that needs to be distributed to individual sites).

The downside is that I think it might not work with Drush after all... but the update status XML would contain all the information Drush needs so that's at least something that could be fixed/improved in Drush if desired.

jonhattan’s picture

Attached a patch to simulate the simple option in #36 over Drush. This is the output:

$ drush @d6 ups
 Name    Installed Version  Proposed version  Message
 Drupal  6.38               6.38              Installed version not supported
jonhattan’s picture

In case a stub Drupal 8 release (without download link) is added to the xml, as proposed in #28, this is what Drush says:

$ drush @d6 upc drupal
Update information last refreshed: Tue, 03/01/2016 - 23:23
 Name    Installed Version  Proposed version  Message
 Drupal  6.38               8.0.4             SECURITY UPDATE available


Code updates will be made to drupal core.
WARNING:  Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt.  If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.
Note: Updating core can potentially break your site. It is NOT recommended to update production sites without prior testing.

Do you really want to continue? (y/n): y
Undefined index: download_link wget.inc:51                                             [warning]
Undefined index: download_link wget.inc:52                                             [warning]
copy(): Filename cannot be empty drush.inc:766                                         [warning]
Unable to download drupal to  from .                                                     [error]
Updating project drupal failed. Attempting to roll back to previously installed version. [error]
Backups were restored successfully.                                                         [ok]

We could improve the experience with an early check of the download link.

Gábor Hojtsy’s picture

Yeah providing actual links would be dangerous for people trying to in fact perform the update (and fail horribly with a major or two major versions updated).

dsnopek’s picture

Issue summary: View changes
FileSize
136.38 KB

We've finally (sorry for the delay) published our alternative to the 'update' module (it's a fork):

https://www.drupal.org/project/mydropwizard

It does two main things:

  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 Long-Term Support (LTS) vendors, so you'll know if it'll be getting security updates going foward

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.

Here's a screenshot:

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

EDIT: I wrote a longer blog post about it: http://www.mydropwizard.com/blog/getting-accurate-available-updates-drup...

dsnopek’s picture

Issue summary: View changes

Updated the issue summary with the current set of proposed resolutions.

drumm’s picture

I wonder if the complex option would allow us to inject an arbitrary release version instead of 7.43. Like "D6 is unsupported, click to see upgrade options"

We do want this to be really static, it will be hard-coded in the CDN's Varnish configuration, 7.43 should not be hard-coded.

drumm’s picture

Title: Drupal 6 projects don't show up correctly in Update Status and Drush due to the way updates.drupal.org marked them as deprecated » Drupal 6.38 isn't correct in Update Status, it is unsupported and will be insecure in the long run

Let's focus this issue on core. The technique of serving a different update status response for 6.38 specifically won't easily scale to contrib. There are enough details and difference between core & contrib, let's track them separately.

drumm’s picture

Gábor Hojtsy’s picture

@drumm: makes sense, thanks!

David_Rothstein’s picture

I wonder if the complex option would allow us to inject an arbitrary release version instead of 7.43. Like "D6 is unsupported, click to see upgrade options"

Interesting idea. I'm attaching an attempt at that. It more or less works, but the wording has to be chosen carefully in order for the status report to make any sense (because it automatically displays the version name inside the phrase "version [name] available").

Overall the simple option from #36 seems a bit cleaner, but this one could definitely be a viable alternative. And one very nice thing about it is how it shows all Drupal 6 sites the "not supported" message, not just Drupal 6.38 sites.

Maybe we should compare how each works with Drush (for both the Drupal 6.37 and 6.38 cases)? I'm a little concerned this approach will confuse Drush badly and that it will try to "download" the release.

Here's the Drupal 6.38 available updates page with the new approach:

And the Drupal 6.37 updates page:

And the status report for either:

basic’s picture

I have these changes ready to go for drupal/6.x?version=6.38. We've decided to leave the default update status xml in place for non-6.38 releases to keep things simple. This only affects Drupal 6 core and not contrib.

The modified XML is visible here: http://updates.staging.devdrupal.org.global.prod.fastly.net/release-hist...

If you're looking to test this out locally or on one of your sites, you can set the update_fetch_url to the updates staging server with

drush vset update_fetch_url 'http://updates.staging.devdrupal.org.global.prod.fastly.net/release-history'

In Drupal 6.38 the following is displayed Only local images are allowed.

mlhess’s picture

+1 this looks good. Thank you to the DA folks who put alot of time into making this work.

David_Rothstein’s picture

Status: Needs review » Needs work
  1. <version>Drupal 6 has reached end of life</version>
    

    This makes the text on the status report page say "Not secure! (version Drupal 6 has reached end of life available)", which doesn't make a whole lot of sense.

    See my earlier comment in #47 for more details.

  2. <download_link/>
    

    Unfortunately this makes the "Download" link in the above screenshot point to the site's homepage. (That is why I didn't do it like this in my earlier example.) Ideally it would point to the same place that the other links point. But I'm not sure if that would confuse Drush...?

  3. <link>https://www.drupal.org/about/drupal6-lts</link>
    

    As mentioned earlier I'm still not sure this is the right place to link to. Repeating my comment from #34 since it may have been lost:

    Also, any messaging here should focus on end-of-life (EOL), not long-term-support (LTS). LTS is one option for people still running Drupal 6 sites, but not the primary recommended one. I think links should be to https://www.drupal.org/drupal-6-eol (or a similar page) that focuses on the overall EOL status and what it means, not to pages that focus on LTS specifically.

    I would be interested in hearing what others (especially core maintainers or security team members) think about that, since this is data provided by drupal.org but it impacts what people see when using the actual Drupal core software.

joshuami’s picture

I've update the page we were using for link to be a bit more focused on end of life while still keeping a large call out to the LTS program. I changed the URL as well: https://www.drupal.org/about/drupal6-eol.

This keeps the user pointed to a page rather than the forum post, which is semantically more correct in our new content model. This also gets the information closer to our "about" information for Drupal 7 and 8.

basic’s picture

Status: Needs work » Needs review

Okay, I've added the download link and updated all links to point at the renamed https://www.drupal.org/about/drupal6-eol

You can see the changes here: http://updates.staging.devdrupal.org.global.prod.fastly.net/release-hist...

I've tested with Drush on a 6.38 site and see this:

 Name                                                       Installed version     Proposed version                  Status
 Drupal                                                     6.38                  Drupal 6 has reached end of life  SECURITY UPDATE available
...
Code updates will be made to drupal core.
WARNING:  Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt.  If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.
Note: Updating core can potentially break your site. It is NOT recommended to update production sites without prior testing.

Do you really want to continue? (y/n): y
File drupal6-eol is corrupt (wrong md5 checksum).                                                                                                                   [error]
Updating project drupal failed. Attempting to roll back to previously installed version.                                                                            [error]
Backups were restored successfully.                                                                                                                                 [ok]
drumm’s picture

This makes the text on the status report page say "Not secure! (version Drupal 6 has reached end of life available)", which doesn't make a whole lot of sense.

I think the added verbosity on the main update status page is worth it. This is the only place we can get a message through to the site, let’s make full use of it.

Unfortunately this makes the "Download" link in the above screenshot point to the site's homepage. (That is why I didn't do it like this in my earlier example.) Ideally it would point to the same place that the other links point. But I'm not sure if that would confuse Drush...?

Avoiding confusing Drush is why I picked the empty download link. I tested with this and confirmed Drush goes nowhere near trying to update a Drupal 6 site to an HTML page.

David_Rothstein’s picture

The new page at https://www.drupal.org/about/drupal6-eol looks good to me. (And yeah, it is better than linking to the forum post with its 100+ comments :)

I tested the new version and it seems to work pretty well. Guess it's ready to go? The "Not secure! (version Drupal 6 has reached end of life available)" message is still kind of weird but despite being grammatically incorrect I guess it does get the intended message across... so maybe it's worth the tradeoff given that it does produce a nicer message on the Available Updates page itself.

hestenet’s picture

Status: Needs review » Reviewed & tested by the community

In light of David's latest comments in #54 - going to call this RTBC

basic’s picture

Status: Reviewed & tested by the community » Fixed

I've pushed this deployment forward to production. This should now be live for all Drupal 6.38 sites.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

brad.bulger’s picture

I don't suppose the release information could be fixed to provide "tag" and "mdhash" entries? It's causing errors without them.