Fix strict routing for frontend forms #48022

[samson1299]

Fixes #48022.

• I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.

Summary of Changes

This pull request removes the redundant view query parameter from the frontend Reset Password and Remind Username form action URLs.

The following files are updated:

• components/com_users/tmpl/reset/default.php
• components/com_users/tmpl/remind/default.php

The forms already render within the correct view, so including the view parameter in the form action is unnecessary. The generated form action now contains only the required task parameter while preserving the existing functionality.

Testing Instructions

1. Open the frontend Reset Password page.
2. Inspect the generated <form> element.
3. Verify that the action attribute no longer contains the view parameter.
4. Submit the form and confirm that the password reset request works as expected.
5. Repeat the same steps for the Remind Username page.
6. Verify that both forms submit successfully and no regressions are introduced.

Actual result BEFORE applying this Pull Request

The generated form action URLs include an unnecessary view query parameter, for example:

/reset?view=reset&task=reset.request
/remind?view=remind&task=remind.remind

These URLs create unnecessary URL variations even though the forms are already rendered within the correct view.

Expected result AFTER applying this Pull Request

The generated form action URLs no longer include the redundant view query parameter. The forms continue to function correctly using only the required task parameter, resulting in cleaner URLs.

Link to documentations

Please select:

• No documentation changes for guide.joomla.org needed

• No documentation changes for manual.joomla.org needed

[richard67]

@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.

[richard67]

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.

[brianteeman]

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

[jjnxpct]

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).

[richard67]

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

[jjnxpct]

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.