Custom nav menu items are scheme-sensitive

[dd32]

If you have a website that's available over both https and http, adding a custom URL entry as HTTP will cause it not to be marked as current-menu-item when visited over HTTPS (and vice versa)

At present, custom nav menu's are only marked as present when one of the following is valid:

1. Exact match (http://example.com/page/
2. Match without trailing slash ( http://example.com/page
3. Match with path only ( /page/ )

It seems to me, that both the first and second instances should apply set_url_scheme() to both forms it's comparing (or use some other comparison method that ignores the protocol).

[McGuive7]

I also noticed that the current-menu-item check fails for custom menu links if any parameters are appended to the URL (e.g. ​http://mysite.com/?foo=bar)

I can't imagine a case in which this would be desirable - am I missing something?

[McGuive7]

Fixes to more accurately add current-menu-item class for custom menu items when URLs aren't an exact match (https/http, URL parameters)

[McGuive7]

This patch adds support for the following issue mentioned above:

1. HTTPS vs. HTTP - apply set_url_scheme() when retrieving $item_url
2. URL parameters - apply strtok() to only compare everything before any ? in the URL

[marsjaninzmarsa]

Duh, you was first. :D

[marsjaninzmarsa]

What about not http/https patchs, but relative (point 3)? Did your patch, @McGuive7, covers it? Is this part of core unit-tested?

[McGuive7]

If you re-read the initial message, those are actually 3 scenarios that do successfully work - so relative paths do work already (at least in the latest version of trunk).

[marsjaninzmarsa]

I've just been worried about set_url_scheme() will be destructive to relative urls, but after check - you are right, your patch is definitely better than mine. :)

[McGuive7]

Cool, so now what happens? What's the process for getting this reviewed and integrated? Anyone?

[johnbillion]

Related: #32367

[obenland]

@dd32, can you take a look at the patch?

[dd32]

I also noticed that the current-menu-item check fails for custom menu links if any parameters are appended to the URL (e.g. ​http://mysite.com/?foo=bar)

I think this is deliberate.

Take for example the following url's:

• ​http://example.com/
• ​http://example.com/?p=1
• ​http://example.com/?page_id=5

All of those should be able to be in a menu and not highlight the others items.

I can understand that however you'd want the following to highlight:

• ​http://example.com/page-name/
• ​http://example.com/page-name/?foo-bar

However, what's to say that those have the same content? maybe they should be different menu items too?

I guess it's those hard questions which lead to that case not being handled, but there are filters in place to allow that sort of thing..

For that reason 32221.2.patch​ by @marsjaninzmarsa looks like it's the best way to go here, but I'll do some testing and get something in soon.

[dd32]

In 33103:

Ensure that Custom Links in menu's are marked as current regardless of their scheme.
Props McGuive7, marsjaninzmarsa.
Fixes #32221