Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.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.
- 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.
- 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 - 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 fetch updates without a working Drupal install.
Use cases:
- Multisite: You first dl the updates, then run the db updates on the different sites.
- "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.
#1398772: Replace .info.yml with composer.json for extensions
#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.
Comments
Comment #1
Mile23