Make WordPress Core

Opened 8 years ago

Last modified 5 years ago

#37586 new defect (bug)

Menu customizer: search results not properly filtered

Reported by: virgodesign's profile 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)

#37586.1.diff (1.6 KB) - added by virgodesign 8 years ago.
37586.2.diff (2.3 KB) - added by dinhtungdu 5 years ago.
Introduce new function to get filtered available item types.

Download all attachments as: .zip

Change History (13)

#1 @virgodesign
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 @celloexpressions
8 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release
  • Version changed from 4.5.3 to 4.3

Good catch. Can you create a patch @virgodesign?

#3 @virgodesign
8 years ago

I've created the snippet code, but currently I'm not able to create a patch.

@virgodesign
8 years ago

#4 @virgodesign
8 years ago

  • Keywords has-patch added; needs-patch removed

#5 @virgodesign
8 years ago

  • Keywords dev-feedback added

#8 @celloexpressions
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 @davidbaumwald
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 @davidbaumwald
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.

@dinhtungdu
5 years ago

Introduce new function to get filtered available item types.

#13 @dinhtungdu
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.

Note: See TracTickets for help on using tickets.