Update will happily downgrade modules unless you are careful

bummer.

Note: the Update manager tag doesn't duplicate the component. There are parts of the Update manager (e.g. authorize.php) that aren't in update.module, and there are parts of update.module that aren't the Update manager.

Furthermore, I'm going to open a new tag for "Update manager dev" for all the issues dealing with shortcomings in how the Update manager handles -dev releases. ;)

Not unless someone writes a patch, and soon...

Sorry I thought it was an API freeze issue.

Marked this as a duplicate: #1019750: Update Manager recommend update to outdated stable module release when newer dev release is installed.

To correct #14, that issue was marked as a duplicate of this one. This one is (and should be) still open!

Two suggested patches. Both work by comparing the timestamp of the installed -dev release with with the date of the recommended version.

One just hides the entry all together from the upgrade list, another puts the module in the "update manually" table.

But there there are lots of questions here, like:
- Should we instead suggest that the user upgrades to the newest dev version?
- Do we hide the release if they are running the newest dev version?
- Do we run this downgrade check for all releases? Or just -dev releases?

+1 (#11 states it correctly: many modules will stay in dev for a long time to come. Moreover, looking at D6 modules, many never get out of dev, alpha or beta...).

I will review and test as soon as a new patch is proposed.

I tried to add something as suggested in #18, but adding radio buttons in a cell in a tableselect is not something that was foreseen by FAPI. So, unless you add the complete markup yourself to that cell this is a no go.

Another solution I'm currently thinking about is to present a separate table with available dev versions.

- Add header to the table for recommended releases.
- Do not show older recommended versions (current patch).
- Show a new table with available dev releases.
- Only if current install is already dev (to be decided).
- Only if available dev is newer than current install.
- User might select multiple releases for the same project. So additional validation is needed.

Pro's:
- Dev versions are clearly separated from the rest, better than with radios.
- Table for recommended stays the same, no difficult mark-up for radio buttons and subsequent handling of that
- Would allow to present dev version, even when the current install is a normal release. The clean separation will assure that the dev version is not selected by accident.

To be decided for this solution:
- tables for dev-enabled and dev-disabled like now with the recommended tables? (I would say yes)
- present dev versions for normal current installs? (I would say yes, this allows one to install a fix)
- add dates to the information? (for me, the release dates of the available versions - or more specific the difference between them - is an important attribute in selecting between dev and recommended. Especially as currently for many modules new releases are appearing almost weekly.

I will see if I can create a patch for this way (UI part first, so we see what we're talking about).

Please find attached a UI only patch. Don't select the presented dev versions, it won't work. With this patch, I want to know if this is the way to go. If we can agree on the UI, we can continue on implementing the behaviour.

Setting to needs review to trigger the testbot.

glad to see resolving this issue is already in progress, subscribe

Improved patch, that removes the "Undefined variable: dev_entry"that leads to failed tests. for the rest, nothing really changed, still waiting for your reactions and ideas on the UI. (note: AFAIC, this patch needs not be tested by the testbot, it is not functional, it is UI only)

I'm not familiar enough with the update system to provide a real in-depth review, but the two items caught me eye:

+++ modules/update/update.manager.inc	Wed Mar 02 14:51:33 2011
@@ -93,105 +93,138 @@
+      $recommended_entry = array(
+        // The project name to display can vary based on the info we have.
+      	'title' => $title,
+      	'installed_version' => $installed_version,
+        'available_version' => $recommended_version,
+      );

Whitespace / incorrect indentation. The 'title' and 'installed_version' lines are indented by tabs instead of spaces.

+++ modules/update/update.manager.inc	Wed Mar 02 14:51:33 2011
@@ -93,105 +93,138 @@
+      $dev_entry = array(
+        // The project name to display can vary based on the info we have.
+      	'title' => $title,
+      	'installed_version' => $installed_version,
+        'available_version' => $dev_version,
+        '#attributes' => array('class' => array('update-dev')),
+      );

Same as above - The 'title' and 'installed_version' lines are indented by tabs instead of spaces.

Powered by Dreditor.

please can someone post a patched version of the module?

Needs work per #25.

Subscribing

Subscribing. This seems like a big deal -- since a lot of Drupal modules don't yet have stable D7 versions yet, a lot of client sites are ending up with a dev that patches some issues since the last beta-whatever. (Normally I wouldn't hand off a site to a client with dev versions except in extraordinary circumstances.)

The UI suggested in the above patch seems fine to me, but it was noted that this is just the front-end, and it's not functional yet. I also don't know enough about the updating system to be able to figure out how to make it functional, but I will cheerfully test anything anyone else posts...

This is not major there are work arounds use ftp, drush etc

This is not major there are work arounds use ftp, drush etc

I disagree. For average Drupal users, they get an error message saying they need to update. When they update, their modules are downgraded. That's serious.

To me, that's a major issue, it affects 7.x, and it needs to be addressed. I can't believe there's consensus among core developers that this bug is just going to go unfixed until the next major version.

If you can provide evidence that core developers have determined this is going to be ignored, then I'll defer to their decision.

Things are fixed in head first. There is no such thing as a core developer, core development is everyone that is involved. And it being normal does not mean it is ignored it simply means that it is not something that is preventing drupal from being used.

Adding backport tag

@Rootwork please see #1050616: Figure out backport workflow from Drupal 8 to Drupal 7. It will give you (probably way too much) background information on why the process exists as it does.

OK. Thanks for adding the backport tag. I disagree that there aren't core developers -- the big ones are listed right here. Sure, there's no title called "core developer" but there are clearly people whose voice carries more weight because of their long involvement in Drupal core development. It was those people of whom I was speaking.

But with the backport tag on there, I can understand wanting to fix it in head first, so that seems fine.

No they are core maintainers and they don't chime in on every issue. Plus given that the maintainer of this feature set it to normal (dww) I think that someone with knowledge on the area has already spoken.

subscribing
I always fall for the suggestion to upgrade
but instead I get my modules downgraded with serious problems

Bumping this again so it's on top the update.module list... (so it's easier to track)

We should be able to fix this more easily now that we have versioned dev builds.

You are right. We should first fix this then add the option to update to a dev version in a separate issue. My ideas back then are to far reaching. The patch of #16 might be a good starting point to post an up to date patch.

What does drive me crazy, is that no publication dates are shown. It probably does make the UI a bit cleaner, but I do use that information. Though that may be because of this bug...

@marcingy This is not major there are work arounds use ftp, drush etc

Can you provide more informations? Do ftp and drush correctly update the right modules and avoid downgrading dev modules to the previous stable?

Now that we have versioned devs it makes even less sense that Drupal propose to upgrade 7.x-1.0-beta1+7-dev with 7.x-1.0-beta1. It just needs a check on the name (and no other metadata) to understand that the -dev one is 7 commits ahead than the proposed stable.

I wish update.module was an external module, so it would not have this very long workflow to be fixed.

Well, it's not really easier to fix this with versioned dev releases, since neither Update manager nor drush knows anything about them. They're not included anywhere in the release history XML feeds. For example http://updates.drupal.org/release-history/views/7.x and search for "7.x-3.x-dev" and look around. You won't see the fancy "rebuild_version" stuff anywhere in there. See #1314180: Make dev release numbers useful for more. That was going to be a huge can of worms and chx, moshe and myself decided it was easier not to untangle that mess at the same time.

I continue to believe the best solution here isn't a technical one to try to make our tools more friendly with -dev releases, but a cultural one to make project maintainers more likely to create official releases. -dev always sucks for everyone, and people shouldn't have to depend on -dev releases unless they're actually developers. But, I know that's basically fantasy, and given that -dev is ubiquitous, we should attempt to properly support it (as much as that pains me to say).

I'm just a subsystem maintainer, so while my opinion counts for more than many people, ultimately it's up to the actual core committers to decide if this is going to be committed to a given branch. However, for that to happen, someone needs to write a working patch. So, I'd try to fix this in D8 first and then see how far-reaching the changes are and if a D7 backport is feasible.

Note also that we've got https://drupal.org/project/update_test_module and I'd be happy to create some D8 test releases there if folks want to use that for testing this bug on D8.

Bump.

Given various comments on this issue, especially #18, #20 and #29 and #46 has the route to fix this issue been decided upon?

#46

I continue to believe the best solution here isn't a technical one to try to make our tools more friendly with -dev releases, but a cultural one to make project maintainers more likely to create official releases. -dev always sucks for everyone, and people shouldn't have to depend on -dev releases unless they're actually developers. But, I know that's basically fantasy, and given that -dev is ubiquitous, we should attempt to properly support it.

It sounds like the simplist solution is to just get the module maintainers to release regular stable versions rather than to commit single patches to dev but given the end of that statement it doesn't sound like you think dww that this is plausable or likely.

Alternatively is anything to be done with the patches that fietserwin submitted then?

Just trying to get this conversation going again. :)

Yes, I think the proposed cultural "solution" isn't going to happen (at least not universally), so we should fix the update manager. AFAICT, the patches from fietserwin are non-functional, and just UI changes. I haven't reviewed or tested. But, from what I can tell, we have an understanding of the bug, an agreement on the need to fix it, but no working patches for any branches. So, if anyone's interested in re-rolling and starting to get this working, please do! Sadly, I don't have nearly enough time for all the responsibilities I've taken on, have been doing a terrible job as a subsystem maintainer for the update manager, and can't take this patch on myself right now.

Thanks/sorry,
-Derek

#49: You are right my patches were only UI related and not functional. At that time I was, incorrectly, trying to push also some new features into this issue. So, IM(current)O, a patch for this issue should:

• Prevent that a dev version gets overwritten by an older "official" release.
• Add some release date information when a dev version is advised to be overwritten by an official release. this as people won't trust this screen anymore now that this bug has been around for so long.

And thus should not:

• Allow to upgrade from an official release to a dev release (to install a patch).
• Allow to upgrade from a dev release to a newer dev release (to install yet another patch).

How nice these features would be, they should not be part of this issue. Perhaps there are already other issues for these features. If not, they could be created as follow ups. Looking through the comments, there will be support for it from others.

I think that the first patch of #16 comes closest to what we need to solve just this issue. Probably needs to be rerolled, will need tests; and (IMO) the date information.

http://drupal.org/node/1427826 contains instructions for updating the issue summary with the summary template.

The summary may need to be updated with information from comments.

Patch no longer applies.

re-rolled the patch

Removing 'Needs reroll' tag because this issue just needs work, not a reroll. Older patches don't apply because the form moved to the UpdateManagerUpdate controller class.

The #53 is no straight patch of any of the previous patches. It has some similarities with #24, but missing portions of its code. Unless @alansaviolobo can explain what he did and why, I would recommend to ignore the #53 patch.

Reviewing this in the DC Asia code sprint, I could not find a module with the right set of releases to demonstrate that the issue still exists. Of course, this does not mean that it does not exist.

If anyone can detail how to reproduce this issue in D8, that would be helpful.

Just install a DEV release of a module that has an older official release.

Was reviewed as part of Triage at DrupalCon Baltimore2017, this is still an issue so I updated the Issue Summary to use the current template standards.

It would be great if this could be re-rolled in D9, since this issue still exists after 12 years.

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?!".