Problem/Motivation
Automatic Updates Extensions is not marked as stable. One reason for that is that we don't know how different modules will handle backwards compatibility and is just more likely to crash your site than updating core. But this problem is not going to change anytime in the near future.
Here are reasons I think we should mark the module as stable, with some small changes I will suggest in the solutions section
- The module has been experimental for a long time and we haven't had any bug reports on it for a long time(ever?). I think the code is pretty solid.
- The module only has 5 classes including 2 forms
- As we added test coverage in the main module we duplicated the coverage in Automatic Updates Extensions as needed.
- In #3307369: Validate all changed or updated Drupal projects with Update XML we moved the validation to ensure that all Drupal project that are staged are actually secure according to Drupal.org's update XML. So even if we get logic in wrong in this module Package Manager would not allow us to install a module that is not supported and secure according to update XML
- Package manager also handles all the other general type of validation like making sure the active lock file has not changed since the update has been staged, we have enough disk space, etc
- Sites have to update their contrib anyways and will do this directly with Composer or if they don't know Composer they will do it the old fashion way. Automatic Updates Extensions has advantages over both these methods.
Using Composer directly could let you update to versions of Drupal modules that are insecure or unsupported according to drupal.org's XML.
Updating by just moving new versions of the Drupal module in directly in place will not handle Composer dependencies. This could actually be a security concern because a contrib module security update may be issued solely to update one if its own dependencies that has it own security release. If the module was originally installed with composer and has its dependencies installed but for whatever reason a new site admin doesn't know the composer way to do things the depencies might NOT be updated.
- Some users of the main module might be using because they don't know how to update their site via Composer. Maybe someone made the site but now they are in charge. They may be keeping Drupal core up to date but not updating contrib modules for security releases
Proposed resolution
We should mark the module as stable with the following changes
- Mark \Drupal\automatic_updates_extensions\ExtensionUpdateStage as internal, all the other classes are already internal
- Add extra warning that updating contrib modules may crash your site depending the on particular module. Suggest that all updates should first be tried locally
- (optional) Add a checkbox that user to above warning to make the user acknowledge the risk
Remaining tasks
Issue fork automatic_updates-3436741
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
tedbowCreated #3436993: Ensure exceptions are shown if updating extensions and there is composer stager error. I think we should be committed first. I have an MR there passing tests
but not postponing this because we can still work on the form changes needed here
Comment #4
tedbowThis could be reviewed. Would need the child issues committed first before we commit this though
Comment #5
tedbowComment #6
phenaproximaJust a minor phrasing change, then this is RTBC when tests are clear.
Comment #7
tedbowAddressed @phenaproxima's review
Comment #8
phenaproximaLooks like there's one unresolved thread. Otherwise this is RTBC when tests pass.
Comment #9
phenaproximaComment #12
tedbowComment #13
tedbow@phenaproxima thanks!
Comment #14
phenaproxima