If a module is Not Supported, Drupal's warning links to available updates page, which says everything is OK

Attached is a patch that forces the link to go to the module list rather than the update list in the event of an unsupported contrib module.

That patch was rolled on 7.x-beta2, probably why it won't apply. Can someone re-roll?

Managed to get CVS working

Line endings, eh? Lets try this then...

Alright, nevermind cvs then. Apparently the first patch just had a bad filename, the offsets are the same. Trying that.

Alright... I reviewed the patch documentation again. Line endings are UNIX style, path is relative to core. Generated by diff -up. Let's put a stop to this nonsense...

I know it's confusing, but "update.module" is for the part of core (added in 6.x) that checks for available updates to your modules and themes (now called the "Update manager" since it can also install/update your code). The "update system" component is for DB schema updates care of update.php...

Anyway, I don't exactly follow what this patch is doing (since I didn't apply it and look at the surrounding code). However, from the description, it sounds like a bad workaround to a deeper bug. We don't want messages to send people to the available updates page. We want to send them to the Update manager's "Please update my broken stuff" action page by default, not the report showing all the info about available updates. If the Update manager page fails to handle unsupported projects correctly, we need to fix that, not just avoid sending people to that page.

We'll need to see detailed steps to reproduce the bug, ideally with some screenshots. Otherwise, it's hard to verify the bug and fix it.

That said, if the Update manager page doesn't handle unsupported project correctly, that's not a minor bug. In fact, I'd call this major, since it has the potential to confuse users into not upgrading unsupported code, which could be a big problem for them.

As I said, we do *not* want to link to the available updates report. We want to link to the page that lets users recover from the warning, not a page the further overwhelms them with big scary warnings.

Even though unsupported modules are an edge case, it's a major bug if the Update manager page doesn't let you upgrade from an unsupported branch to a newer major branch. See also #977414: Allow updating to a -dev or new major branch with Update manager (related, but different).

I *thought* we had code in Update manager to help users upgrade from an unsupported branch to the now-recommended branch. :/ We'll have to play with the steps above to see what's going on here.

Presumably, yes.

Upon further thought, if there's *no* recommended releases at all for the project, then maybe the update manager page needs to just print a warning about it. That'd be kind of like the situation for when core needs an update -- it's listed on the page as an update you need to do, but the update manager can't actually do the update itself.

Whoops, this fell of my radar without the 'string freeze' tag. I don't have the capacity to do anything about this now, other than pray.

I'm not even clear what the bug is here, downgrading since this has only been reproduced with CCK, which was an edge case that did not meet the major bug definition anyway (since the module wasn't properly unsupported).

I marked the linked issue as a duplicate. It has a patch which is closer to where the discussion here ended up, although I'm not sure it's really the right approach. It is treating UPDATE_NOT_SUPPORTED as the special case, but I think we actually want to deal with "no recommended releases" as the special case, due to this code currently in the Update Manager:

      if (empty($project['recommended'])) {
        // If we don't know what to recommend they upgrade to, we should skip
        // the project entirely.
        continue;
      }

It seems like that code is what can lead the following code to trigger, even when all modules aren't actually up to date:

    if (empty($projects)) {
      $form['message'] = [
        '#markup' => $this->t('All of your projects are up to date.'),
      ];
      return $form;
    }

I'm also putting this back to major priority, since this is easy to reproduce with modules that have been marked unsupported on drupal.org, including ones that were marked unsupported by the security team.

Some examples that work to test it out on (at the time of this writing) include https://www.drupal.org/project/google_website_optimizer (for Drupal 7; this is the example used in the issue I marked duplicate above) and https://www.drupal.org/project/page_access (for Drupal 8).

Here's a potential patch, along with a screenshot showing how it works:

I'm going to credit the person who worked on the patch at #2870690: Unsupported releases don't show up on ' Available updates' - although I did this patch differently, I feel like I at least borrowed some rough ideas from that one.

Definitely needs a reroll / re-write after #3113992: The 'Update' page has no idea that some updates are incompatible landed. Still seems worth fixing this, so that the 'Update' page doesn't say "Everything's cool" when you've got unsupported projects.

Reroll. Original patch had uneven number of closing brackets. I assume this would probably would need some tests.

@sokru: Thanks for working on this!

Re: "Original patch had uneven number of closing brackets" -- I doubt that. Test results for #25 would have exploded if there was a syntax error. I bet git just got confused trying to apply the old patch to the new code, which was refactored by #3113992 and some of the relevant context is now indented another 2 spaces...

Yes, definitely needs tests. See the new tests I added at #3113992: The 'Update' page has no idea that some updates are incompatible. You can almost certainly expand those to cover this, too. Lemme know if you need help with that.

I need to apply the patch and see it in context to actually review this. Quick look of the .patch file itself seems potentially wrong, but I can't say for sure. Hope to get to this soon, but I can't promise when. Hopefully in less than 9.5 years like the last time I stepped away from this issue. ;)

Thanks/sorry,
-Derek

We attempted to look at this on the UX meeting today, but are a bit lost as to what the problem is, how to reproduce it, and what the "before/after" solution being proposed is. An issue summary update would be very helpful.

Problem and how to reproduce were clearly spelled out in the original summary: Have a site with a module that's been marked 'Unsupported'. But I updated the summary to use the default template, and to flesh out pros/cons of the proposed resolutions.

Cheers,
-Derek

We discussed this issue at #3131774: Drupal Usability Meeting 2020-05-05.

Thanks for updating the issue summary. We recommend

1. Add the unsupported projects to the existing "Manual updates required" table.
2. Change the heading of that table to something more generic, perhaps "Recommended action".
3. Change the existing entry in that column (in the row for Drupal core) to a full sentence: something like "Upgrade to 8.8.x ...".
4. Rewrite the second sentence in the new row to avoid the passive voice.

If the table header already says "Recommended action", then we do not have to say "... is strongly recommended" in that second sentence. Something like "If you can, disable everything that depends on this project and uninstall it" is a step in the right direction.

Thanks for the review and direction, @benjifisher et al! I started looking into implementing your suggestions.

The proposed fix from #33 would start displaying info about projects without a recommended version. However, upon closer inspection, that'd also start talking about projects where we failed to fetch available update history (the net is down, you've got a custom project without a history on d.o, etc, etc). Properly handling all of these cases seems rather scope creepy. Partly handling them is also somewhat weird. There's also some refactoring of the code for that form that needs to happen at #3121775: Refactor UpdateManagerUpdateForm::buildForm() to make ::removeCheckboxFromRow() unnecessary. What should we/I do?

A) Just fix the major bug by specially handling the 'project marked unsupported' case, continue to have the implementation a bit clumsy, but Get It Done(tm) with the smallest possible patch for hopefully easier backporting. Then cleanup (some of) the implementation details at #3121775, and finally circle back in Yet Another Follow-up(tm) to handle the other cases where there's no recommended version to use.

B) First fix #3121775 so that we've got a stronger foundation to build on, then fix the bug. Would #3121775 be backportable to All The Branches(tm)?

C) Expand the scope of this issue to properly handle all cases were there's no recommended version, but ignore #3121775 and leave the implementation details sorta weird until it's "safe" to do such refactoring (9.1.x?)

D) Expand this issue's scope to handle everything, and implement it nicely, so that #3121775 becomes unnecessary.

E) Other?

Thanks,
-Derek

Per @dww I was looking at a stale issue summary, so tagging for an update.

@xjm Clarified that for issue scope, we're basically going with #39.A. No sense scope creeping, nor blocking a major bug fix on code refactoring and cleanup.

Also likely that this is 9.1.x only at this point (due to string / UI changes).

Summary updated from #38 and UX meeting.

I rerolled and then updated the patch according to #38. I started from the patch in #25 because of the comments about brackets in #33 and #34, and there was no diff.

I've added some if statements to get around a possible undefined variable. It is a bit messy but instead of focusing on that I want to see what tests fail. Also, I am getting PHPStan errors locally on a line not changed by this patch so want to see what testbot does.

Thanks, just updating the title, which lost "upal's" :)

Just converted to an MR and hid patched, nothing else.