Show core and extension updates on a single page, accessible from multiple places

I think you uploaded the wrong screenshot.

I just installed a fresh version of it and was clicking around and noticed the same thing.
It seems like the List and Update from "/admin/modules" menu is interfering with the same named menu items from the "/admin/reports/" menu.

I'm not sure why this is a stable blocker for Drupal CMS, but I'm pretty sure it's a bug in Automatic Updates itself. Moving to that queue.

I can confirm that this is reproducible with vanilla core, so it's definitely a bug in Automatic Updates. I'll work on it.

Turns out this is very hard to fix, because local tasks in general are a confusing hellhole that don't work the way you want or expect them to.

Honestly, my feeling is that this is not worth fixing, and instead we should focus on completely revamping the UI to all be on one page (both core and contrib updates), rather than duplicative tabs. That's a much bigger lift, but I think it will be quite a bit more rewarding in the long run, and it would also allow us to sidestep the need to do incomprehensible local task jiu-jitsu.

Nah, screw it. The existing UX is atrocious and buggy. It need not be this way.

I changed it such that:

• There are three local tasks called "Update": one on the themes list, one on the modules list, and one on the reports page. (Same as now.)
• Each one links to a clone of the main Automatic Updates route, which makes the tasks behave properly.
• Automatic Updates Extensions no longer provides a separate route. Instead, it overrides the Automatic Updates route and shows a single unified list of updates, separated into two sections (one for core and one for contrib).

If you don't like the three clones, then what we could do as an equivalence is have one route that is canonical, and the others can just redirect to it. The downside of that is the fact that it kicks you into an entirely different area of the admin backend. But whether that's a problem is for the UX folks to say.

It's a pretty major change, but I think it's a big step in the right direction. The nature of this change, I think, means we should put this in a 4.1.0 release.

I discussed this proposed UX change in a Slack DM with @ckrina and she gave me the sign-off I was hoping for.

The salient bits (lightly edited to remove me dropping profanity):

phenaproxima
Well, okay then. Basically, AU’s UX is an unholy mess. It adds two tabs to several places: one to update core (“Update”) and one for modules and themes (“Update Extensions”). These tabs get duplicated as well in a couple of places, due to the menu system being [wonky]

ckrina
So, if I am understanding this the result is that instead of "Update"x2 and "Update Extensions" x2 there will be only une tab calles "Update" in the Update page?

phenaproxima
Almost. There will be one tab called “Update” and it appears in three places:
Update page
Modules page
Themes page
And it always goes to the same place, which is a complete dashboard of available updates (core and contrib).

ckrina
If I am understanding this well, it makes sense

phenaproxima
That’s what I figured. The idea is to bring AU closer to the unified Extend section envisioned in the wireframes.
Instead of [whatever] it's doing now.

ckrina
YEah, I don't care on a UX perspective if you are duplicating or not: but the Update things place should be one in theory with all the things that need to be updated

phenaproxima
That’s what this does.
All updates in one place.

ckrina
And you should be able to get there from any place where are things that need to be updated

phenaproxima
Yep, that’s what this does too.

ckrina
Then you have my +1

OK, look.

Build tests are still failing, despite my Herculean efforts to make them work. The simple fact is that they are an inconsistent, lumbering mess (and I originally created the framework for them, so I can say that safely) and need to be refactored and redesigned.

That said, all other tests are passing, and Pam has reviewed this. This UX improvement is significant and is a Drupal CMS 2.x stable blocker, so it needs to happen. I think the actual functionality being implemented in this MR works fine, and we cannot keep stalling this because the build tests are garbage.

I'm going to merge this with the failing tests, and I can work on stabilizing everything in other issues.

Merged into 4.x.