[6.0] Fix extensions check for updates bug

[joomdonation]

Pull Request for Issue # .

Summary of Changes

In Joomla 6, we use a single instance of ExtensionAdapter to find updates for all extensions/update sites. The latest update found for previous extension is not reset before finding update for the next extension and it causes the strange bug described in the issue #46066. Basically, if the previous extension has higher version number than the next extension, the update for the next extension could not be found.

Testing Instructions

• Use Joomla 6 (this does not happen on Joomla 5 because in Joomla 5, we create new instance of ExtensionAdapter to find update for each extension)
• Download and install this old version of Akeeba Backup https://www.akeeba.com/download/akeeba-backup/10-0-5/pkg-akeebabackup-10-0-5-core-zip.zip
• Download and install this old version of Admin Tools https://www.akeeba.com/download/admintools/7-8-1/pkg-admintools-7-8-1-core-zip.zip

Note that you need to install the two extensions in exactly order above (Akeeba Backup needs to be installed first because it has higher version number than Admin Tools)

• Go to System ->Update -> Extensions (http://localhost/joomla/administrator/index.php?option=com_installer&view=update), click on Check For Updates button in the toolbar

Actual result BEFORE applying this Pull Request

• Update only found for Akeeba Backup

Expected result AFTER applying this Pull Request

• Update found for both two extensions as expected (since the installed version of the two extensions are outdated)

Link to documentations

Please select:

• Documentation link for docs.joomla.org:

• No documentation changes for docs.joomla.org needed

• Pull Request link for manual.joomla.org:

• No documentation changes for manual.joomla.org needed

[brianteeman]

appears to work correctly in my limited test

I wonder why the original code was changed

[joomdonation]

I wonder why the original code was changed

Look like it was the result of removing some deprecated classes #43794, #43793, #43792. But I haven't looked at the details of all of these PRs yet.

[brianteeman]

My worry is that whatever broke the code here may also have broken code elsewhere and we just havent come across it yet. I wouldnt want us to need to keep using sticking plasters

[joeforjoomla]

I have tested this item ✅ successfully on e10a351

---

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

[joeforjoomla]

Yes it seems to work correctly by resetting the variable.

[richard67]

@joomdonation Could you update the phpstan-baseline.neon file? It seems PHPStan fails for your PR. It fails for parts of code not changed by your PR, no idea why. You can fix that by running ./libraries/vendor/bin/phpstan -b after having run composer install. IT will not require redo of human tests. Can you do that? Or shall I help?

[joomdonation]

@richard67 It would be great if you could help with this PR. I am not familiar with the process yet.

[richard67]

@joomdonation Funny: Just restarting the PHPStan GitHub action has helped. No idea why. Anyway, no need for any changes on this PR.

[joomdonation]

Thanks Richard

[richard67]

I've restored the previous human test result in the issue tracker as the commit which has invalidated the test count was just an improvement of a code comment.

[richard67]

I have tested this item ✅ successfully on eeb3106

---

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

[richard67]

RTC

---

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

[Bodge-IT]

Thanks for the fix @joomdonation and tester @joeforjoomla and tests at last minute @richard67