Contrib.social

Strategies to speed up update status fetching

Open on Drupal.org →
Created on 10 December 2012, over 12 years ago
Updated 6 May 2025, 28 days ago

DISCLAIMER:
- I tried to find if this is a duplicate, just didn't find any 1:1 duplicate.
- This might get obsolete if we switch to Composer for package downloads. See below.

Problem:
Today, whenever you want to update only one contrib module on your site (e.g. drush up ... or drush pm-updatecode), Drupal spends a lot of time fetching updates for all modules installed on the site. This feels like a big waste of time.

Solution:
There are different directions imaginable.

  1. Send the current version of modules installed on the site, and Drupal will respond with all changes since then. This might have privacy problems, because it reveals more of your site than necessary.
  2. Send the timestamp of the last update check, plus a list of modules to check for, and Drupal will respond with all changes since then. This seems to be like an attractive option, with the same privacy impact as we already have today.
    Little problem: We
  3. Allow people to run their own update server, which pulls new module versions from Drupal and makes them available to your own projects. This could be based on a git repo that holds current versions of all available projects on d.o..

Requirements:
I think it would be very useful if one can .
Use cases:

  1. Multisite: You first dl the updates, then run the db updates on the different sites.
  2. "vendor" branch: You have one git branch "vendor" for original versions of core and contrib, and another branch "live" for locally modified / "hacked" stuff. Whenever you want to update, you would switch to the vendor branch, making your Drupal site potentially unusable, run drush pm-updatecode, then switch back to the live branch and run drush updb.
    (this is what I am currently doing on all projects I start)

This would mean we'd have to keep any "last checked" timestamp and related data outside of the database, somewhere in a file.

Note:
There have been talks about using Composer for project downloads, which might make this discussion obsolete for D8.
✨ Replace .info.yml with composer.json for extensions Postponed
#1433256: Proposal: Composer as a Library Manager →

While I accept that Composer could handle project downloads and version management, I strongly doubt it will help with module dependencies. And even if it does, we might still want to improve the situation in D7 - or at least allow contrib to do this.

📌 Task
Status

Postponed: needs info

Version

11.0 🔥

Component

update.module

Created by

🇩🇪Germany donquixote

Live updates comments and jobs are added and updated live.
  • stale-issue-cleanup

    To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 28 days ago →
    🇺🇸United States smustgrave

    Thank you for creating this issue to improve Drupal.

    We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

    Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

  • Comment 14 days ago →
    🇳🇿New Zealand quietone
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024