The built in module/theme update feature is great as it greatly decreases the amount of work and the time a site has to be down when updating a lot of modules.
A problem though is that it doesn't take into account which version of a project you are using and can easily end up downgrading a modules, which in turn can lead to the website breaking.
When opening the Update page you get a list of all items for which there are updates available. This list seems to be based on "Recommended version" and it only lists one item per project.
Thus if your installation is using a dev version, but there is an older recommended version, then you can't use this feature because the dev version is not possible to select.
Also, the page is not showing dates, so you really need to have the Available Updates page open as well and switch back and fourth between them.
This feature needs to be smarter and realise that if the installed version is a dev version that is newer than the recommended version, then it is very likely the dev version it should update to.
For experienced users it is not a problem to make sure the correct modules are updated and then manually do the ones that would have been downgraded. Not so experienced user are bound to run into problems with this though.
In these cases there should be two options, using radio buttons, so it is easy to select which version to update to for individual projects.
When clicking the "select all" checkmark, it should also default to the newer dev version (if the installed is a dev version newer than the recommended).
These multiple choice updates should also be easily to spot in the list, either by its own colour or grouped together at the top of the list.
Then when clicking Download it should be smart enough to detect any accidental downgrades and ask me if I really want that. On the same screen I should be able to change the choice for those modules detected to be downgraded.
Closed: outdated
11.0 🔥
update.module
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.
After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.
There is consensus among core maintainers that this is a major issue. Only core committers should add this tag.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Decided to deprecate all the plumbing and remove the UI in 11.2.x. Closing this as outdated.
I've never been so happy to see a terrible bug be closed without being fixed.
Well, let's stick with "outdated" so that people don't go "what are they thinking?!".