[#47202] - [5.4] Editing menu item redirects to list view with original filters
- Fixed in Code Base
- 18 Jul 2026
- Medium
- Build: 5.4-dev
- # 47202
- Diff
- hiteshm0:hiteshm0_filter_issue_on_redirect
User tests: Successful: Unsuccessful:
Pull Request resolves #19652
- 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
Changed the method populateState() in itemModel.php to setUserState ( menu type, client id via getUserStateFromRequest() ) only when a new menu item is being created.
Moved the database query responsible for fetching parent items for a menu item ( via getParentItem() in ItemController.php) from ItemsModel to a new method getParentItems() in ItemModel to prevent ItemsModel::populateState() from running which was unnecessarily updating the session state ( whenever the menutype of a menu item was changed an AJAX request was being handled by getParentItem() )
What this does is that when we edit a menu item and click on 'save and close' we will be redirected to the list view of menu items with the original menu type filter instead of it being set to the menu type of the article that was edited.
But when we create a new menu item the previous functionality is preserved.
Testing Instructions
Case 1: Editing
- go to list view of 'all menu items', do not set any filters
- select an article to edit
- save and close
Case 2: Creating
- create a new menu item
- save and close
Case 3: Editing ( change menu type )
- go to list view of 'all menu items', do not set any filters
- select an article to edit
- change its menu type.
- save and close
Actual result BEFORE applying this Pull Request
get redirected to list view of menu items with the menu type filter set to the menu type of the article edited / created.
Expected result AFTER applying this Pull Request
Case 1:
get redirected to list view of menu items with the original filter ( ie no filter ).
Case 2:
same as before
Case 3:
get redirected to list view of menu items with the original filter
Link to documentations
Please select:
-
Documentation link for guide.joomla.org:
-
No documentation changes for guide.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_menus |
| Labels |
Added:
PR-5.4-dev
|
||
| Labels |
Added:
bug
|
||
I have tested this item ✅ successfully on 7aae034
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47202.
I have tested this item ✅ successfully on 7aae034
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47202.
I have tested this item ✅ successfully on 7aae034
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47202.
I have tested this item ✅ successfully on 7aae034
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47202.
@brianteeman @CSGoat0 Have you also tested cases 1 and 3 when at the beginning in step 1 a filter was set?
The testing instructions cover only the case that no filter was selected in that step.
But the expected result says the original filter shall be restored.
I would expect that to work with any filter and not only none.
Yes
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47202.
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47202.
| Labels |
Added:
RTC
|
||
✅ Final test before merge with JBT
- Seen before PR
- Case 1: Editing
- If all menu items are selected and one is edited, it returns with menu items menu filtered and not all entries
- Case 2: Creating:
- If all menu items are selected and a new one is created, it returns with menu items menu filtered and not all entries
- Case 3: Editing menu type
- If all menu items are selected and a menu item type is changed, it returns with menu items menu filtered and not all entries
- Case 1: Editing
- Applying PR with
gh pr checkout 47202- Case 1: Editing
- ✅ If all menu items are selected and one is edited, it returns to all menu items entries
- ✅ If one menu is selected and one menu item is edited, it returns to the menu selected
- Case 2: Creating:
- ✅ If all menu items are selected and a new one is created, it returns with menu items menu filtered and not all entries
- ✅ If one menu is selected and one menu item is created in the same menu, it returns to this menu selected
- ✅ If one menu is selected and one menu item is created for a different menu, it returns to this different menu selected
- Case 3: Editing menu type
- ✅ If all menu items are selected and a menu item type is changed, it returns to all menu items entries
- ✅ If one menu is selected and one menu item is changed, it returns to the selected menu filter
- Case 1: Editing
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-07-18 16:08:21 |
| Closed_By | ⇒ | muhme |
Thank you very much @hiteshm0 for your contribution. Thanks to @richard67 and @QuyTon for support. Thanks to @CSGoat0 and @brianteeman for testing.
as getUserStateFromRequest() updates the session state, explicitly updating it later might be redundant
can a maintainer let me know what the ideal behavior for case 3 is ? ( i went through the conversation of the issue and could only find the desired behavior for case 1 and case 2 )
Currently, even if you change the menutype from 'X' to 'Y' and then immediately back to 'X' it still redirects back to list view with menu type filter set to 'X' and im not quite sure where the session state is getting updated for that to happen.