[#46045] - [5.3] Improvements to extension updater
- Closed
- 8 Sep 2025
- Medium
- Build: 5.3-dev
- # 46045
- Diff
- BrainforgeUK:5.3-dev
User tests: Successful: Unsuccessful:
Pull Request for Issue # .
Summary of Changes
Added event handler response checks for:
- onInstallerBeforePackageDownload
- onInstallerBeforeUpdateSiteDownload
Added event:
- onInstallerPackageDownloadFailed
Testing Instructions
The test sequence below illustrates:
- How to code for the new functionaity
- The new behaviour when extension 'check for updates' and 'update' fail.
Test sequence:
- Install the patch attached to this pull request.
- Extension updates continue to work as previous.
- E.G. 'check for updates' - all work (some may fail for unrelated reasons).
- Install the test plugin.
plg_installation_test.zip - Enable the test plugin.
- Run 'check for updates' - all fail with a sensible message.
- Re-enable update sites.
- Disable the test plugin.
- Run 'check for updates' - all work (some may fail for unrelated reasons).
- Enable the test plugin.
- Attempt to update one or more extensions - all fail with a sensible message.
- Disable / uninstall the test plugin.
- Re-enable update sites (if necessary).
Actual result BEFORE applying this Pull Request
Expected result AFTER applying this Pull Request
More flexibility for 3rd party developers when handling extension updates.
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
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_installer Libraries |
tecpromotion
- | Title |
|
||||||
| Labels |
Added:
PR-5.3-dev
|
||
Can this be moved into 6.1-dev please.
Can this be moved into 6.1-dev please.
@BrainforgeUK Yes, we can do that. But your PR might show unrelated changes for a while (until the next upmerges all the way up from 5.3-dev to 6.1-dev) as the 5.3-dev branch currently is in advance with some commits compared to 6.1-dev. That might be confusing, so maybe we wait with that.
Will this also enable showing the user the reason why the update failed? e.g. because his download key / subscription expired and he is not allowed to download the file?
Currently the user gets a failed message not stating why it failed (other the that is could not be downloaded: which can be for any reason)
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46045.
These screenshots illustrate the responses I want to achieve.
Implementation requires a developer specific installation plugin plg_installed_thedevelopername to handle the events.
Providing an example in manual.joomla.org would be useful.
======================================
I think adding a AfterPackageDownloadEvent would be useful and make things easier.
Will do that shortly.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2025-09-08 17:17:00 |
| Closed_By | ⇒ | BrainforgeUK | |
| Labels |
Added:
Feature
|
||
@BrainforgeUK You've closed this PR by deleting your fork of the CMS repository. Same happened to your other, older PRs yesterday. Was that by purpose or an accident?
Closed by accident - did not realise deleting the fork would close the PR.
The only thing it seems to affect is being unabled edit / delete changes.
In the light of your earlier comment about 6.1-dev and my idea I mentioned for AfterPackageDownloadEvent I thought best if I moved the changes to 6.1. Will do a new PR.
Regarding the others, from so long ago ..., can they be reopened?
Wanted to tidyup github!
Regarding the others, from so long ago ..., can they be reopened?
@BrainforgeUK No, we can't re-open PRs and restore their branches if the repository (your fork) has been deleted.
@BrainforgeUK you need to fork again, and then re-apply changes from the PR using git apply for diff https://github.com/joomla/joomla-cms/pull/46045.diff
Hint: to get a diff from other PRs just add .diff at the end of URL
These screenshots illustrate the responses I want to achieve. Implementation requires a developer specific installation plugin plg_installed_thedevelopername to handle the events. Providing an example in manual.joomla.org would be useful.
======================================
So what you are wanting to achieve is reporting back to the customer why the download failed: e.g. due to subscription expired.
but by using triggered events, that means that you implement this via a system plugin on the customers site. This is IMO to limiting as that requires a system plugin that listens to these events. What if you are selling a module, or e.g. a task plugin (or whatever extension) that doesn't listen and reacts to event triggers?
IMO this functionality should be implemented in the Joomla updater itself where there is a 'contract' stating possible responses (it could be a json formatted string): just like in the manifest file you can specify a key format to pass to the external download server.
The download server would then be responsible to state why the download didn't succeed and that information would then be displayed to the customer while trying to update.
That way it works independently from what is installed and needs to be installed.
Although I see other uses for the proposed events, I think they are to limited for the use case you stated
@BrainforgeUK New features have to go into 6.1-dev.