Empty menu items are deleted without warning

[cameronjonesweb]

I recently discovered that menu items with with an empty label are deleted from the menu upon save without any warning or notice. The particular situation was that I was adding a menu with an icon font for the items, so the labels were empty but had classes. Obviously a HTML comment can be used in this instance, but there should be some way to either communicate with the user that items with an empty label will be removed, disable saving of a menu with empty labels, or some way to handle empty labels without deleting the item.

[welcher]

Thanks for contributing to core! Would you like to propose a solution with a patch?

[audrasjb]

The patch doesn't applies cleanly anymore. Will need a refresh.

Moving to Future Realse as the solution proposed in the patch looks fine on my side.

[audrasjb]

Before the patch: blank menu item removed

[audrasjb]

After the patch: blank menu item remains but its label is not blank anymore

[audrasjb]

The proposed patch (needs refresh) works partially. The menu item remains, but its title is not blank, it takes the object’s original title. I think it will also need to make some changes in wp_setup_nav_menu_item in wp-includes/nav-menu.php.

[samful]

@audrasjb had the right advice here, so thanks for pointing me in the right direction. This patch should solve the issue you were having.

In my testing, the patch seemed to work perfectly, but I also want to note that after testing, I found that the theme "Twenty Nineteen" (My other installed themes had no issues) has a CSS rule which hides any empty <a> tags. So, to get round this I made a quick CSS rule to display empty <a> elements again just for Twenty Nineteen. You may want to include this in your custom css if you are using Twenty Nineteen, or edit it to something similar if using another theme that hides empty <a> elements:

.main-navigation .sub-menu > li > a:empty{
	display: block;
}

I then went on to test what @cameronjonesweb was initially trying to do (put an icon font or a symbol in the menu item):

.main-navigation .sub-menu > li > a:empty:after {
	content: "\00a9";
}

I'll also attach screenshots of the admin view where I edited the menu items and the front end where the empty items have the copyright symbol \00a9. This is just an example of how it can be done using the current patch and the CSS above on the "Twenty Nineteen" theme.

If someone else could give this patch a test too, that would be very helpful :)

[samful]

refeshed with correct src/ path and got rid of some unused variables

[whyisjake]

The patch is not applying cleanly, can we get an update?

[samful]

refreshed for development version (5.5-alpha-20200717.105532)

[samful]

thank you for following up on this @whyisjake

[SergeyBiryukov]

Looks like this removes some code for handling empty titles. Even if removing is the correct approach, that code was originally added for a reason, and I don't feel comfortable making this change late in the release cycle without a proper review of the history of these lines. Moving to 5.6 for now.

[maxpertici]

Keep blank label with a non-breaking space

[maxpertici]

While reading the ticket, if we want to avoid removing too much code, I thought of this "solution". Can we say that it works? (Patch 36212.4.diff)

[audrasjb]

36212.4.diff

[audrasjb]

Menus: Replace blank nav menu item titles with a non-breaking space

[audrasjb]

This is a great alternative @maxpertici, thanks. Works fine on my side (see screenshot bellow).
I’d only change the comment wording, see 36212.5.diff.

Markin this for commit as the last proposed patch is pretty straightforward and doesn't introduce any big change.

[desrosj]

I may be missing it, but what was the reason for removing the "(no title)" in favor of a non-breaking space? That matches how posts without a title are handled elsewhere in the admin ( "(no title)" is displayed ).

[SergeyBiryukov]

Haven't tried to reproduce the issue yet, but if the original problem we're trying to address here is that items marked as "(no title)" are removed on saving, then it seems like the outcome of this ticket should be to keep these items as is, without removing them or forcing them to have a title.

Changing "(no title)" to something else seems more like a workaround rather than an actual solution.

It could be that 36212.3.diff​ is on the right path, it just needs someone to review the history of the affected code, see if the concerns it aims to address are still relevant, and whether it can be safely removed now without any backward compatibility breaks or other unintentional effects.

[hellofromTonya]

In discussing with Sergey at today's scrub, we'll moving this ticket to Future Release as it needs more time per his comments here.

If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

[audrasjb]

Moving for 6.1 consideration.

[audrasjb]

Unfortunately, as this ticket didn't get enough momentum from milestoning to 6.1, let's put it back to Future Release milestone.