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.This issue is waiting on it's parent #395474: Plugin Manager in Core: Part 2 (integration with update status) to be committed.
In the parent issue, DWW's position was that if the Plugin Manager doesn't respect the original Update Status differentiation between different versions of the same project, then users will be unable to choose between a 1.2 security update version and a 1.3 released version (most current).
DWW: Upgrading your Drupal site is *not* as simple as running "software update" on your Mac, and it never will be given how Drupal actually works and exists in the world. This interface has to reflect reality. If you want to completely simplify the interface and hide all the "ugly" details from the "less knowledgeable audience", then you have to change reality. You can't make the interface reflect your ideal vision of reality and then hope reality will magically shift on its own.
Then, later on, Catch summed up the situation with:
We're losing some of the finer grained reasons for upgrading - i.e. I'm on Views 2.6, and Views 3.0 UNSTABLE-1 comes out - the current UI tries to suggest some caution about upgrading to unstable 1 (or alpha, beta, rc), if we only have red and blue, and no descriptive text then we're losing some of that.
There's also the issue of being on 2.5 and having the option of 2.6 OR 3.0-UNSTABLE-1 which the current UI doesn't support. i.e. does it default to 2.6 or 3.0-unstable1. If it defaults to 2.6, will I get nagged to upgrade to 3.0-unstable-1 as soon as I've updated to 2.6? Or do we only ever recommend stable releases from this interface? What if I'm running dev and there's a newer dev build.
There are also other statuses for currently installed modules which are critical but aren't a security update - the main two is when a module author unpublishes a release because it's unsupported - i.e. sites running panels-6.x-2.x which should be prompted to upgrade to panels-6.x-3.x - IMO these should just be red as well.
Then there's the situation where rather than a new security release, modules are so broken that we recommend uninstalling them completely - see http://drupal.org/node/318746 - this status is 'revoked' in the current UI. As far as I can see, the current UI wouldn't show those modules at all, because they don't have updates as such.
Note, I don't think we need to allow for fine-grained updates of contrib modules via this UI, if you want that, use tarballs, drush or cvs - but these particular sitautions where either uipgrading, or not being prompted to do something else can result in a hosed site ought to be dealt with I think.
Comments
Comment #1
Senpai CreditAttribution: Senpai commentedChanging the title.
Comment #2
Senpai CreditAttribution: Senpai commentedIn addition, there's a real need to distinguish between a module and a theme when presenting this upgrade info, and I think this UI can handle it. Wireframe mockups to follow.
Comment #3
JacobSingh CreditAttribution: JacobSingh commentedI think the solution for this is already found on d.o. When a mod maintainer marks a release as "recommended" then it is the one which the user is offered to upgrade to.
I don't see how that doesn't solve the first couple problems in the description.
Theses ones:
* Critical but not security
* Broken mods w/ no upgrade path.
are likely separate issues IMO.
can we decide, before this issue also inundated which of these are MUST HAVE for launch? I'll get Dries to weigh in if I can find him. If we don't start identifying and agreeing on critical path, we are totally doomed.
Best,
Jacob
Comment #4
Senpai CreditAttribution: Senpai commentedIMO Jacob, none of these four auxiliary issues are marked critical for a reason. :) In fact, all four of them are postponed until the main issue is fully committed. Baby steps!
Comment #5
JacobSingh CreditAttribution: JacobSingh commentedThis is in re to http://drupal.org/node/395474#comment-1820434.
My feeling is that it can go either way. Some module maintainers use a lot of branches, some use them sparingly and reserve it for total overhauls. My belief is that a module maintainer is under obligation to set the recommended version to the one people should be using, and that normal people should just be able to upgrade to the recommended version. Honestly, module maintainers should provide some kind of BC in all cases, but I know as well as you that they often don't.
I hear what you are saying though... The dangerous thing is that by making the decision to not allow major version upgrades, we are essentially saying, "you don't need to use SSH or FTP to manage your site, until you do." Which means we have kinda failed to provide an environment for non-geeks to stay up2date. That to me is the core message of this project, and we can't abandon it.
I'd prefer to have the known risk that they may screw up their site. If we focus energy to solve this, I'd like to see it focused on Backup and Migrate module or something in core, to provide for a backup and a recovery operation in case the "recommended" release isn't too great.
I'm not against the idea at all, and what you are saying makes sense, I'm just very nervous about delaying this yet again, if and when we implement the choice of a branch upgrade vs. a security update, how do you propose we do it on the UI?
Best,
Jacob
Comment #6
Paul Natsuo Kishimoto CreditAttribution: Paul Natsuo Kishimoto commentedTag!
Comment #7
dwwNot yet resolved by #538660: Move update manager upgrade process into new authorize.php file (and make it actually work).
See #602496: Clean up the update manager project selector page when updating your site which is related.
Better title and adding Usability tag...
Comment #8
Aren Cambre CreditAttribution: Aren Cambre commentedHas this been forgotten? How does this affect the Plugin Manager's own "port to D7" issue? (#336743: Port Plugin Manager module to D7)
Comment #9
dwwNot forgotten, but not critical and very few people have been helping with with the update manager so no one got around to dealing with this in time for D7.
Comment #10
dwwAdding the Update manager dev tag to track this with other issues relating to how Update manager handles -dev releases.
Comment #11
Kebz CreditAttribution: Kebz commented@ dwww (Derek)
Per your comment https://www.drupal.org/node/977414#comment-3754086 and conversation from this thread https://www.drupal.org/node/977414
I think that it is critical to have an option to upgrade from and to.... regardless of the admins skill/technical level.
The reason being is this .... as this has happened to me (lol) ... when it prompts me to update, I just click and don't realize that it's forcing me to update the "recommended" version vs. the dev version. So then I believe it messes up the installs and database.
It's worth looking into for Drupal core 7.x+ as well since core 8 is not in stable mode and a lot are still in 7.