Opened 8 years ago
Last modified 5 years ago
#37586 new defect (bug)
Menu customizer: search results not properly filtered
Reported by: | virgodesign | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 4.3 |
Component: | Customize | Keywords: | has-patch dev-feedback needs-testing |
Focuses: | Cc: |
Description
customize_nav_menu_available_item_types
is a filter located in class-wp-customize-nav-menus.php
.
The purpouse of this filter is to restrict item types available in the Menu Customizer.
This filter should be applied even if I perform a research using the search field in Menu Customizer.
But this does not happens.
While in Menu Customizer, doing a research, in search results shows up even items of specific types excluded with customize_nav_menu_available_item_types
filter.
We can resolve this issue using another filter always located in the same class: the customize_nav_menu_searched_items
filter.
With this filter we can restrict the selections of items received from the search result just before sending them to the frontend (ajax response).
But this could be considered only a workaround and not a solution, because items should be filtered/excluded by type BEFORE wordpress performs the query to the database.
We should suppose that, if we uses the customize_nav_menu_available_item_types
to filter item types available on Menu Customizer, most likely we do not want search for elements of theese item types.
Attachments (2)
Change History (13)
#1
@
8 years ago
- Summary changed from customize_nav_menu_available_item_types should filter even search results to Menu customizer: search results not properly filtered
#2
@
8 years ago
- Keywords needs-patch added
- Milestone changed from Awaiting Review to Future Release
- Version changed from 4.5.3 to 4.3
#8
@
5 years ago
- Keywords needs-testing added
- Milestone set to 5.3
#37586.1.diff needs to be reviewed by an active developer and tested (by anyone currently able to test patches). Milestoning as this is a valid bug that has waited long enough for attention and should be resolvable with a minimal effort by an active committer.
This ticket was mentioned in Slack in #core by david.baumwald. View the logs.
5 years ago
#10
@
5 years ago
- Keywords needs-refresh added
The most recent patch fails against trunk
, so this needs a refresh. There are a few WPCS nitpicks to be addressed as well.
This ticket was mentioned in Slack in #core by david.baumwald. View the logs.
5 years ago
#12
@
5 years ago
- Milestone changed from 5.3 to Future Release
This ticket was discussed during today's bug scrub. It still needs a refresh, so it's being moved to Future Release
. If anyone can take ownership during the 5.4 cycle, feel free to move up the milestone.
#13
@
5 years ago
- Keywords needs-refresh removed
@davidbaumwald Let me own this ticket :)
I'm wondering should we make the API simpler by changing the 2nd argument ($return_key
) of get_available_item_types
to $return_type
which is array
or string
.
Mostly, we'll want to get an array of item array or an array of the item name. The current version allows us to get the array of whole item array or array of the specific key which is more flexible.
Good catch. Can you create a patch @virgodesign?