[#47303] - [5.4] Fix invalid URL in Update Notification email when triggered via CLI
- Closed
- 11 Mar 2026
- Medium
- Build: 5.4-dev
- # 47303
- Diff
- Reda-Muhamed:5.4-dev
User tests: Successful: Unsuccessful:
Summary of Changes
When the Update Notification task (plg_task_updatenotification) is triggered via the CLI without a --live-site parameter, Uri::base() inherently falls back to https://joomla.invalid/set/by/console/application/. Because the plugin emails this raw output, it results in broken, confusing links for the user.
This PR adds a safe language string fallback for the CLI environment. If the URL contains joomla.invalid, the email will securely instruct the user to log in to their Administrator dashboard to apply the update, rather than sending a broken link.
Testing Instructions
- Ensure the
System - Joomla! Update Notificationplugin and its associated Scheduled Task are published. - Trigger the task via the CLI using its Task ID:
php cli/joomla.php scheduler:run -i 3 - (Note: To fully trigger the email generation locally, the test environment must have a pending Joomla update available so the script does not exit early).
- Observe the generated email body or URL variables.
Actual result BEFORE applying this Pull Request
The email body contains broken placeholder links:
URL: https://joomla.invalid/set/by/console/application/
Link: https://joomla.invalid/set/by/console/application/administrator/index.php?option=com_joomlaupdate
Expected result AFTER applying this Pull Request
The email body provides a clean, instructional fallback using the new language strings:
URL: URL unavailable (Run via CLI without --live-site)
Link: Please log in to your site Administrator dashboard to apply this update.
Link to documentations
No documentation changes required.
Fixes #47256
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration Language & Strings Front End Plugins |
i don't think this is a solution
My main thought is that the CLI environment natively doesn't know the live site URL. If we rely on forcing users to manually add the --live-site parameter, we are completely trusting their input. If they forget it, or type an invalid domain by mistake, the system will still generate and email a broken link.
I added this string as a safe fallback so the user always gets a clear, instructional email instead of a joomla.invalid link.
How would you prefer to solve the root cause here?
| Labels |
Added:
Language Change
PR-5.4-dev
|
||
Hello @Reda-Muhamed thank you for your contribution.
We discussed this PR in the maintenance meeting and although your solution kind of could be a way, we see an issue, when you get update notifications without knowing which URL you have to look into. The better solution would be to make the --live_site required for this task, when running via CLI and return an error code when not set.
Perhaps something you want to investigate?
I will close the PR for now. Thanks again for your idea.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-03-11 19:19:31 |
| Closed_By | ⇒ | bembelimen |
Hello @Reda-Muhamed thank you for your contribution.
We discussed this PR in the maintenance meeting and although your solution kind of could be a way, we see an issue, when you get update notifications without knowing which URL you have to look into. The better solution would be to make the
--live_siterequired for this task, when running via CLI and return an error code when not set.Perhaps something you want to investigate?
I will close the PR for now. Thanks again for your idea.
First of all I want to thank you for discussing my PR, I really appreciate the feedback and the clear direction
I plan to make the argument required and also add basic format validation (for example ensuring it is a valid URL starting with http:// or https://) to prevent invalid url format.
However, I was just thinking about an edge case: if an administrator passes a fake but properly formatted URL by mistake (like https://blabla.com), the validation will pass, but the generated link in the notification will still be wrong. I assume we should just accept this as user responsibility and rely on basic format validation. Do you agree?
@alikon please let me know if you prefer a different approach
i don't think this is a solution