Fixed, thanks @brianteeman

why is this a plugin and not part of the component.?
as a plugin it could be disabled but for what benefit?

And if it is to be a plugin then it needs to be added to the list of core extensions libraries\src\Extension\ExtensionHelper.php

why is this a plugin and not part of the component.?

Because the action, that is relevant for the purge of the updates, does not happen in com_joomlaupdate but in com_config; and com_config triggers plugin events.

And if it is to be a plugin then it needs to be added to the list of core extensions libraries\src\Extension\ExtensionHelper.php

Good catch, done!

For testing: do I need to be on the latest version (5.2.4) or i.e. on 5.2.3?

For testing: do I need to be on the latest version (5.2.4) or i.e. on 5.2.3?

The provided test instruction don't rely on the actual retrieval of update information but on the execution of "proof statement". So, for these instructions the version does not matter.

I have tested this item ✅ successfully on 257002e

For testing you need to be on a current version, otherwise you will not see the "Check for Updates" button and you cannot test.
But on the latest version, I tested successfully and saw the "purge triggered" message

I tested on localhost with MariaDB

I have tested this item 🔴 unsuccessfully on 257002e

Steps Followed for Testing:

• Applied the patch using Joomla! Patch Tester.
• Edited UpdateModel.php and added die("purge triggered"); to verify the purge execution.
• Navigated to System > Update > Joomla! Update.
• Changed the Minimum Stability option in the Update settings.
• Clicked Save & Close, expecting the purge process to trigger.

Observed Behavior:

• No confirmation of the purge trigger.
• The expected output (purge triggered) was not displayed.

Expected Behavior (Not Achieved):

• The purge function should be triggered after changing the update stability level.

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/44954.}

@komalm have you installed and activated the new plugin before performing the test? applying the patch alone will not be sufficient.

@SniperSister The testing instructions tell to toggle the minimum stability. But they don't tell to check that the purge is also triggered by changing the update channel without and with the PR, i.e. that this still works with the PR. I think the instructions should also cover that case.

@SniperSister There is something wrong when changing the update channel with this PR applied. I've done a real test with the version number patched to 5.3.0-alpha4. When I use the custom URL of this PR with minimum stability = stable, then the update to this PR is found. That's right because the PR builds are tagged as stable in the custom update XML. Then I switch back to the default channel where nothing should be found. But it still shows the update from the custom URL, and the URL of the update site in database is still the custom URL.

Hint: To patch the version to alpha4 I've edited files administrator/manifests/files/joomla.xml and libraries/src/Version.php and then used the database fixer to apply the patched version.

@SniperSister There is something wrong when changing the update channel with this PR applied. I've done a real test with the version number patched to 5.3.0-alpha4. When I use the custom URL of this PR with minimum stability = stable, then the update to this PR is found. That's right because the PR builds are tagged as stable in the custom update XML. Then I switch back to the default channel where nothing should be found. But it still shows the update from the custom URL.

I have tested this item 🔴 unsuccessfully on 4eb1439

Details see my previous comment. Maybe we need a similar fix to #44951 regarding the kind of task?

Or maybe the plugin is listening to the wrong event? When I add some error log for debugging, it shows that the purge is triggered, but the values of $updateURL and $updateType are those for the old value and not the new value of the update site.

@richard67 stupid question: plugin was installed and enabled during the test?

@richard67 stupid question: plugin was installed and enabled during the test?

Sure. I have updated a 5.3-dev installation to the custom update URL of this PR to see if your update SQL works. Then I have checked that the plugin is installed and enabled. Then I have patched the version to 5.3.0-alpha4 like I described in the comment before my test result. Then I have tested.

Instead of a die, I did use error_log for producing debug output to my error log at the place where you said the die should be added.

I've still had the custom URL of the PR entered, minimum stability was stable, and I only changed the update channel from "Custom URL" to "Default" and vice versa and saved after each change.

My debug log has shown that the purge always gets triggered one time, but the values of $updateURL and $updateType are those for the channel before the channel change and save, i.e when I changed from "Custom URL" to "Default", the update type in the log was "Collection" and the URL was the one of the PR, and when I changed from "Default" to "Custom URL" the update type was TUF and the URL was the default one.

@SniperSister This is the debug code which I've used in the applyUpdateSite method of the UpdateModel, just at the end after the $db->execute();:

        // DEBUG
        error_log('DEBUG: Purge triggered');
        error_log('DEBUG: $updateURL="' . $updateURL . '"');
        error_log('DEBUG: $updateType="' . $updateType . '"');

The 2 variables are determined from the params gotten with the statement at the top of the method in line :

$params = ComponentHelper::getParams('com_joomlaupdate');

switch ($params->get('updatesource', 'default')) {
...

Maybe this still gets the old values from before save?

@richard67 I was able to reproduce your finding and have update the PR and the test instructions accordingly

@webgras a re-test would be much appreciated!

I have tested this item ✅ successfully on 9498976

In addition to the testing instructions, I've also tested that it works when the update channel is changed with the CLI, and that the update SQL scripts are working. The latter was tested with MySQL and PostgreSQL.

I have tested this item ✅ successfully on 9498976

RTC