Opened 2 years ago
Last modified 3 months ago
#43113 new defect (bug)
Multiple custom item classes are returned as single string when using 'nav_menu_link_attributes' filter with Customizer preview
Reported by: | lrdn | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 4.3 |
Component: | Customize | Keywords: | has-patch has-unit-tests needs-testing |
Focuses: | Cc: |
Description
Normally the variable $item->classes
used in a nav_menu_link_attributes
filter function returns an array of all classes associated with an item, including custom classes defined in the menu settings. However, when using the Customizer to edit an item all custom classes will be returned as a single string. Only after the changes have been published and the page reloaded will it return the expected array.
I've attached a patch that fixes the problem but I am unsure what actually causes the bug.
Attachments (2)
Change History (6)
#2
@
2 years ago
Weston, thanks for taking a look. Simply add a nav_menu_link_attributes
filter function and log the classes array of the item object. I am using the default logger in my example.
<?php function custom_link_attributes($wp_attributes, $wp_item, $wp_args) { error_log(json_encode($wp_item->classes, JSON_PRETTY_PRINT)); return $wp_attributes; } add_filter('nav_menu_link_attributes', 'custom_link_attributes', 10, 3);
Now edit an existing menu item using the Customizer and define at least 2 custom CSS classes. The log output will show both classes located within the same array item.
[ "custom-class-1 custom-class-2", "menu-item", ... ]
As soon as the changes are published, or whenever the menu items are modified in the appearance settings, the item classes will be located in separate array items as expected.
[ "custom-class-1", "custom-class-2", "menu-item", ... ]
My patch is the earliest point at which I could locate and correct the malformed data, but I am guessing the cause is actually located where the string is handed over by the JavaScript request.
#3
@
6 months ago
- Keywords has-patch has-unit-tests needs-testing added
- Milestone changed from Awaiting Review to 5.4
- Version changed from 4.9.2 to 4.3
Storing the classes as a string in the setting value seems right to me because wp_update_nav_menu_item()
expects to receive a string for menu-item-classes
.
The problem occurs (I think) when the nav menu item's properties are overwritten with the customized state in \WP_Customize_Nav_Menu_Item_Setting::filter_wp_get_nav_menu_items()
. The string setting value for classes
overwrites the array value set by wp_setup_nav_menu_item()
.
43113.diff attempts to fix this in \WP_Customize_Nav_Menu_Item_Setting::value_as_wp_post_nav_menu_item()
by ensuring that a string classes
is exploded into an array before it's used to overwrite the property.
@lrdn, would you be able to refresh your memory about this issue and test the patch?
Marking this as a potential small fix to get into 5.4 if it can be tested.
#4
@
3 months ago
- Milestone changed from 5.4 to Future Release
Hi,
With 5.4 Beta 3 approaching and the Beta period reserved for bugs introduced during the cycle, this is being moved to Future Release. If any maintainer or committer feels this should be included or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.
Do you have an example of some code causes the bug to appear?