[#45619] - [5.3] Fix strict routing for frontend forms (band-aid only)
- Pending
- Medium
- Build: 5.3-dev
- # 45619
- Diff
- LadySolveig:5.3/fix/strict-routing-band-aid
User tests: Successful: Unsuccessful:
Pull Request to fix frontend form behaviour #42989.
Summary of Changes
The PR #42989 has unfortunately introduced an incorrect behaviour when creating the routing for the forms in frontend. With the enabled strict routing option of the sef plugin, all redirects that can be set for actions like cancel, save and similar controller functions no longer work correctly as the menu parameters can no longer be transferred.
Reason is the missing connection to the assigned menu item as the url is not generated correctly.
- update form actions to remove option
- ensure correct routing for forms in frontend with strict routing enabled and disabled
It's not a complete fix, but at most a band-aid. In my opinion, this should definitely be finally fixed in the router and represents a B/C break that was certainly not intended.
However, it is highly likely that this will also affect some third-party extensions.
Testing Instructions
Make sure the option for strict routing is set to yes in Plugins: System - SEF.
First Test: Create article redirect
- Create a menu item -> type: Create Article
- Set the options for redirecting by form submission and cancel
- Test the cancel and submission of the form and where the redirect leads to
Second Test: Login redirect
-
Create a menu item -> type: Login Form
-
Set the options for redirecting for login and logout
- Test where the redirect leads to after login and logout
Actual result BEFORE applying this Pull Request
Result for the testing instructions:
Redirect options are ignored and the final redirect always goes to the homepage.
Wrong urls in form
Expected result AFTER applying this Pull Request
Result for the testing instructions
Redirect options work and you will be redirected to the correct page after the action.
Correct urls in form
//cc @Hackwar
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 | ⇒ | Front End com_config com_contact com_content com_users |
I have tested this item ✅ successfully on ba6f7a8
Tested in com_content + code review
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45619.
| Labels |
Added:
Release Blocker
bug
PR-5.3-dev
|
||
This is not the correct fix. The right fix would be to remove the whole hard coded URL and instead use Route::_('index.php') instead.
Updated with the proposed fix from @Hackwar and additionally tested for user tasks - login, logout, password reset, registration and username reminder request.
If you find the time I would be very grateful if you could redo your tests. @chmst @coolcat-creations
Nothing has changed in the testing instructions, everything should lead to the same result again.
it would be great if we had some consistency with the ordering of the parts of the form settings. in the long run it makes it easier to spot missing parts.
I would have done this as a separate PR to 5.4 to avoid polluting this PR and because its not a bug fix BUT as these are all views which might have overrides I wouldnt want to ask the user to check all their overrides on 5.3.x and 5.4
So please can we update this PR with changes to provide consistency in the order of parts
I would suggest
- action
- method
- id
- name
- class
<form action="<?php echo Route::_('index.php'); ?>" method="post" id="application-form" name="adminForm" class="form-validate">
I have tested this item ✅ successfully on 07f17a5
Tested successfully. Thank you for your work!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45619.
I have tested this item ✅ successfully on ba6f7a8
Tested successfully, thank you for the fix!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45619.