@samson1299 Please use the structure of our pull request template and don't remove things when creating pull request.

Especially confirm that you have read our Generative AI policy by entering X between the squared brackets of the check box so it is checked.

Thanks in advance.

System tests for password reset are failing (test site/components/com_users/Reset.cy.js, see log here https://github.com/joomla/joomla-cms/actions/runs/28290069482/job/83820572296?pr=48028 ). I think that's related to this PR.

Please explain how the urls are cleaner

Please explain how the urls are cleaner never mind I read the issue report which had more usseful information

Real-world case that shows why this matters: on a Joomla 6.1.1 site we manage, the form action on the "remind username" page still inherits view=remind (

This kind of self-referencing, ever-redirecting URL is exactly the sort of thing that trips up crawlers and third-party tooling that parses or caches URLs (in our case we first noticed it via PHP warnings in an unrelated caching plugin that tried to derive a filesystem path from the URL).

Real-world case that shows why this matters: on a Joomla 6.1.1 site we manage, the form action on the "remind username" page still inherits view=remind (<form action="/inloggen?view=remind&amp;task=remind.remind">), confirmed live just now. Following that as a GET request (as a crawler does) triggers a genuine infinite redirect loop: Joomla responds with a 303 whose Location header contains a literal HTML-encoded & instead of a raw & — which is itself invalid, since HTTP headers aren't HTML and shouldn't be entity-encoded. The client ends up looping back to the same URL indefinitely.

This kind of self-referencing, ever-redirecting URL is exactly the sort of thing that trips up crawlers and third-party tooling that parses or caches URLs (in our case we first noticed it via PHP warnings in an unrelated caching plugin that tried to derive a filesystem path from the URL).

Real-world case that shows why this matters: on a Joomla 6.1.1 site we manage, the form action on the "remind username" page still inherits view=remind (<form action="/inloggen?view=remind&amp;task=remind.remind">), confirmed live just now. Following that as a GET request (as a crawler does) triggers a genuine infinite redirect loop: Joomla responds with a 303 whose Location header contains a literal HTML-encoded & instead of a raw & — which is itself invalid, since HTTP headers aren't HTML and shouldn't be entity-encoded. The client ends up looping back to the same URL indefinitely.

This kind of self-referencing, ever-redirecting URL is exactly the sort of thing that trips up crawlers and third-party tooling that parses or caches URLs (in our case we first noticed it via PHP warnings in an unrelated caching plugin that tried to derive a filesystem path from the URL).

Real-world case that shows why this matters: on a Joomla 6.1.1 site we manage, the form action on the "remind username" page still inherits view=remind (<form action="/inloggen?view=remind&amp;task=remind.remind">), confirmed live just now. Following that as a GET request (as a crawler does) triggers a genuine infinite redirect loop: Joomla responds with a 303 whose Location header contains a literal HTML-encoded & instead of a raw & — which is itself invalid, since HTTP headers aren't HTML and shouldn't be entity-encoded. The client ends up looping back to the same URL indefinitely.

This kind of self-referencing, ever-redirecting URL is exactly the sort of thing that trips up crawlers and third-party tooling that parses or caches URLs (in our case we first noticed it via PHP warnings in an unrelated caching plugin that tried to derive a filesystem path from the URL).

Unfortunately the system tests are failing here, and it might be related to the changes in this PR. We will investigate.

Tested this on a live Joomla 6.1.2 site (as a template override, to avoid patching core directly) that was actively hitting the bug described in #48022. Confirmed:

• Form action on both com_users/remind and com_users/reset no longer includes the view parameter.
• Submitted the remind-username form — clean 303 redirect back to the plain login URL, correct system message shown, no more recursive & encoding.
• No errors introduced in this basic flow.

Regarding the failing Reset.cy.js system test: looking at that test file, one of its scenarios specifically submits the reset form via a menu-item link and then checks that the resulting email links back to that same menu-item context. Since this PR changes the form action to a bare index.php?option=com_users (no route context) plus a hidden task field, my guess is that's exactly what breaks — the menu-item/SEF context that used to ride along in the form action route is now lost. Might be worth checking whether the fix needs to preserve the current route context (e.g. via Route::_('index.php?option=com_users', false) relative to the current Itemid, or explicitly carrying an Itemid hidden field) rather than dropping it entirely.