-
-
Notifications
You must be signed in to change notification settings - Fork 529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Dashboard Updates widget's display of the most recent modx version #16608
Conversation
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). |
Sorry for not being clear—should have said when 3.1 is released! |
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. |
Set cache expire back to its original value (forgot to do this before submitting)
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. |
I think Jim is right. We should get 3.0.6 out first with the dashboard fix. |
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. |
There's nothing holding off on a 3.2 soonish after a 3.1 release if the other WIP PRs take more time, @smg6511! |
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. |
@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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
#16608) ### 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) https://github.com/user-attachments/assets/a74f8872-4047-4307-b1c0-0d522581066d ### Related issue(s)/PR(s) Resolves #16466
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
-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 incore/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