- 🇳🇿New Zealand quietone
This work is now in 🌱 Drupal 10 Core Roadmap for Automatic Updates Active .
Dries highlighted at the DrupalCon Vienna keynote that a priority for Drupal is to support core updates from within the UI.
This solution will be just as optional as Update Manager is today, aimed at non-Composer people.
We also had a Composer meeting (attended by Dries, xjm, Mixologic and others) where we highlighted the need for that same UI to support fetching Composer dependencies, to avoid exposing users to Composer.
Anyone who's looked at Update Manager knows that it has been abandoned and unloved for a long time. Our best approach would be to build a new solution (core module or app) and then deprecate Update Manager.
The goal of this issue is to investigate how such an implementation would look, and estimate the amount of effort, then try to gather contributors and funding that could help make it happen. Keeping the initial discussion and planning in this issue, it's too early to split work into subissues.
The order of priority:
1) Support updating Core from within Drupal.
2) Support downloading and updating modules.
3) Download dependent modules when adding a module (Commerce requires Address, download that too).
4) Deal with dependent libraries that currently need Composer in order to work.
There is no doubt that we won't be able to solve all of these in a single core release.
Resources:
http://www.drop-guard.net/blog/auto-updates-in-drupal
https://paragonie.com/blog/2016/10/guide-automatic-security-updates-for-...
https://theupdateframework.github.io/
The initial dilemma is figuring out where the new Updater will live. It could be a new module (core/modules), but it might be necessary (or simply preferable) to have the updater be its own app, living next to the core/ folder, with its own kernel (to make it more robust). Once the Update starts handling core (#1), handling modules (#2 and #3) should be a relatively easy followup. The real trickiness is in #4.
Figuring out how to structure the updater, and how to update core will be a big task, so I'd like to avoid discussing the Composer part for now. Still, here's a spoiler:
You click “Update” or “Install” next to the name of your favorite module. The updater downloads and extracts the module tarball. The library process then starts, and the updater sends two things to drupal.org:
a) the site’s composer.json (possibly reduced) with the addition of the name/version of
the new module.
b) The site’s vendor/installed.json, detailing the current state of vendor.
The drupal.org endpoint runs composer install. This is a faster process than usual because drupal.org will maintain a large composer cache (of both metadata and packages). The installed.json file is then evaluated. Every package that the client site already has (in the same version) is removed from vendor/, for a smaller download. The result (composer.lock, vendor/) is packaged and downloaded. The updater replaces the old composer.json, composer.lock, autoloader. It then adds in the new vendor subfolders. A custom file would also need to identify which vendor subfolders can be deleted, because they’re no longer needed.If you click “Update core”, it’s a similar process. The updater downloads the core tarball, extracts it (replacing vendor/ in the process), the reruns the library process to refetch module libraries. This process could be optimized to ensure it only replaces vendor / reruns the library fetch when needed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This work is now in 🌱 Drupal 10 Core Roadmap for Automatic Updates Active .