Fix Dashboard Updates widget's display of the most recent modx version

[smg6511]

What does it do?

Added new SoftwareUpdate Processors for retrieving available MODX and Extras updates information, utilizing the new upgrades API. This PR is a Phase 1 fix that solves the issue at hand, but also paves the way for a more flexible and comprehensive Updates widget display to be done in a Phase 2 PR. In that next phase, users will be able to control what level of update MODX candidates should be shown (via a few new system settings).

The new MODX download functionality provides a direct download instead of a link to the modx.com downloads area.

Why is it needed?

The widget currently incorrectly shows the current -dev version.

How to test

1. Manually delete session data from the database.
2. Clear browser and MODX caches and verify that the widget displays the correct update version.
3. Test with an up-to-date -pl release (currently 3.0.5), a -dev release (github 3.0.x or 3.x), and an older -pl or -dev release (3.0.0 - 3.0.4). This is a little tricky, because you're going to pull down the 3.1.0-dev from github to review. You may want to manually override the installed version in core/src/Revolution/Processors/SoftwareUpdate/GetList.php (line 33), setting it to various versions to see what happens in the Dashboard widget (e.g., 3.0.1-pl or 3.0.6-dev, etc.).

Example (with 3.0.4-dev installed)

Screen.Recording.2024-08-30.at.2.25.35.PM.mov

Related issue(s)/PR(s)

Resolves #16466

[rthrash]

Should it show both 3.0.5 and 3.1 as upgrade options?

[smg6511]

Should it show both 3.0.5 and 3.1 as upgrade options?

No, although I suspect what's catching your eye is Bob's Upgrade MODX, which is showing both (and shouldn't).

[rthrash]

Sorry for not being clear—should have said when 3.1 is released!

[smg6511]

Ahh, ok, in that case: At this juncture I'm only aiming to fix the immediate problem—that the latest release shown is incorrect. So for this first PR I only want the widget to do what it means to do now (show the single latest -pl release). A second PR will focus on improvements and expanding the list of possible downloads, which will likely involve the introduction of a couple new system settings (or maybe widget properties) to make the listing user-configurable.

So to answer your question, when 3.1 is released, the results of this PR will only show that release.

[smg6511]

@rthrash @opengeek - Hey guys, it'd be great to get this change into 3.0.6 (assuming that is still going to be the next release), as it seems pretty bad to be showing an invalid upgrade version in the UI.

[rthrash]

The next release will likely be 3.1, and soon, as we're down to a handful of open PRs remaining. Since point releases don't break backward-compatibility, there shouldn't be a need for a 3.0.6.

[opengeek]

I think Jim is right. We should get 3.0.6 out first with the dashboard fix.

[smg6511]

Yeah, and that would give a little more time to get some of the more feature-oriented PRs (such as the modals one I've been working on for a while and a couple others) finalized for inclusion in 3.1.

[rthrash]

There's nothing holding off on a 3.2 soonish after a 3.1 release if the other WIP PRs take more time, @smg6511!

[opengeek]

Where is the data for this getting cached? Running the cache refresh, emptying the session table, and loading the dashboard with browser caching disabled is not working.

[smg6511]

@opengeek - We'll have to look into that further. I did not change that aspect of the process, so the caching is just as it was. Although, if you happened to pull this PR down early (soon after I posted it), you may need to pull down the latest updates. I had forgotten to set the expiration back to the correct default (I set it to 0 when I was working on the PR). Maybe that's causing the problem you're seeing?

[opengeek]

@opengeek - We'll have to look into that further. I did not change that aspect of the process, so the caching is just as it was. Although, if you happened to pull this PR down early (soon after I posted it), you may need to pull down the latest updates. I had forgotten to set the expiration back to the correct default (I set it to 0 when I was working on the PR). Maybe that's causing the problem you're seeing?

No, I just pulled it down fresh this morning again. I'm guessing wherever it is being cached is not being refreshed. It only works if I physically delete the contents of the cache folder, which should NEVER be needed. I'll dig in and see if I can figure it out.

[opengeek]

I found where it is cached. It uses the same cache partition as the extras updates, which is not refreshed when the Clear Cache action is selected from the menu. We can handle that separately as this works as expected beyond that issue.