Problem/Motivation

The update module assumes that update.drupal.org might not be the only update server and allows fetching XML from a different URL for each project.

We can't be sure if anybody is actually running an update server for Drupal 8 sites.

There are reasons to think nobody is:

  1. #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates we updated to use a new endpoint, /current for the update server regardless of whether it is update.drupal.org or not. Alternative servers would have had to add the endpoint.
  2. #3074993 also changed the expectation as far as what XML would be returned. If an update server was still returning back the old format, as soon as the sites using that update server updated to Drupal 8.8.3 they would see no updates for core or any modules.

    To test this on 8.8.x site you can revert this single line change and point to old XML endpoint
    Then going to admin/reports/updates will return no updates

  3. This issue was released in Drupal 8.8.3 on March 4, 2020, 2 weeks ago as of opening of this issue
  4. Any update servers that did not 1) create a new /current endpoint and 2) provide XML in the new format would stop working for Drupal 8.8.3 sites.
  5. No one comment on #3074993 about these changes either before after the commit that this will/did break their update server
  6. There have been no issues filed since 8.8.3 was released that any non update.drupal.org update servers have broken.

    There is 1 issue filed #3120168: No available releases found but it is likely that this is because we didn't had a "post_update function to reset the Update manager's cache of fetched data".

    It was closed in 1 day with a suggestion that they need to click "check manually". The original poster did not mention they were using a non drupal.org update server and has not commented back they the solution did not work for them.

    We could file an issue to the post update function. It would help those that skip 8.8.3.

It possible that someone is running an update server but all the sites connecting have not updated to 8.8.3 and that the developer running the update server does not run test on the latest supported release of Drupal and has found this out yet.

It also possible no one is running an update server that Drupal 8 sites are connecting to.

Proposed resolution

Try to find out if any body is running an alternative update server

If no one is than we should:

  1. deprecate this ability and warn sites.
  2. In our test try to mimic the connect to Drupal.org as closely as possible.

    This would mean keeping our XML test fixtures as close as possible to what update.drupal.org provides. So won't to do issues like #3113798: Remove unused (and generally wrong) <tag> markup from Update module test XML fixtures which diverge our test fixtures from update.drupal.org.

Remaining tasks

User interface changes

API changes

Remove an update server API

Data model changes

Release notes snippet

Comments

tedbow created an issue. See original summary.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Title: Determine if other there are other update servers besides updates.drupal.org, if not deprecate the ability to have different servers » Determine if there are other update servers besides updates.drupal.org, if not deprecate the ability to have different servers
Related issues: +#3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates
dww’s picture

dww
we/he/they
commented
Issue summary: View changes

I started making some edits to the summary so it's more legible and clear. But I stopped since I didn't want to completely re-write your proposal. ;)

A few initial responses:

  1. The functionality in question is on a per-project basis. It's not just "an alternative update server" in general, it's an update server for a specific project or projects. The original intention was that if you're hosting your extension(s) offsite (e.g. Github, whatever), but you still want to let Update manager work, you could have your own release history server.
  2. Everything in the summary about core is a red herring. Core definitely uses updates.d.o. No one can change that. Well, I guess you could use the info alter hook, inject the alternate URL for core, etc, but that'd be really weird/silly. ;) The feature you're talking about removing would only impact custom extensions that don't live on d.o, so your assumptions about what would / wouldn't break aren't entirely valid.
  3. It's going to be very hard to determine if anyone is using this functionality or not. By definition, everything hosted on d.o (and therefore, grep-able by us) is not using it. Also by definition, anything using this isn't going to show up in d.o usage stats, etc.
  4. I don't think this issue has anything to do with #3113798 or why that's a good idea or not. ;) Even if we deprecate this feature and force everything that Update manager understands to live on d.o, Update manager itself still doesn't use <tag> anywhere, and we can/should remove all that bogus data from our test fixtures. We should not necessarily remove <tag> from the release history feeds, since other tools can/do consume that information (e.g. drush, upgrade manager, etc). Even if Update manager doesn't care about <tag>, that doesn't mean no one cares about it and we're free to rip it out of the feeds.

All that said, yes, probably no one is still using this, and it'd simplify some things to deprecate it and eventually remove it. But that also wouldn't let us assume that only Update manager is reading the info from updates.d.o, so let's not entangle our assumptions too much.

Thanks,
-Derek

Version: 9.0.x-dev » 9.1.x-dev

Drupal 9.0.10 was released on December 3, 2020 and is the final full bugfix release for the Drupal 9.0.x series. Drupal 9.0.x will not receive any further development aside from security fixes. Sites should update to Drupal 9.1.0 to continue receiving regular bugfixes.

Drupal-9-only bug reports should be targeted for the 9.1.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.2.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.1.x-dev » 9.3.x-dev

Drupal 9.1.10 (June 4, 2021) and Drupal 9.2.10 (November 24, 2021) were the last bugfix releases of those minor version series. Drupal 9 bug reports should be targeted for the 9.3.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.