HTML encoded characters in the custom menu's URL html are decoded after first save and removed after second save

[rocketwood]

Special characters in the custom menu's URL get double html encoded after second save.

Having an array in the URL that is using square brackets (site.com/key[value]), the links break after the second save of that menu item because the & in the & gets double html encoded.

[rocketwood]

Replying to rocketwood:
The issue is when
​http://site.com/post_type/key[value]/ is converted and saved as ​http://site.com/post_type/key[value]/ after the first save and striped of brackets after the second save ​http://site.com/post_type/keyvalue/

[scruffian]

Shouldn't you be using URL encoded special characters, rather than HTML encoded ones - i.e. ​http://site.com/key%5Bvalue%5D?

[mordauk]

I've just confirmed the bug.

If we enter http://wpdev:8888/?p=1&somevar[]=24&somevar[]=25 into the URL of a custom link, we should get http://wpdev:8888/?p=1&somevar[]=24&somevar[]=25 back.

When the menu item is added, we actually get http://wpdev:8888/?p=1&somevar=24&somevar=25 instead.

While it does work to use encoded values, how is a user supposed to know they should do that. WordPress should allow a non-encoded URL to be added and render that properly.

This appears to be due to esc_url().

echo esc_url( 'http://wpdev:8888/?p=1&somevar[]=24&somevar[]=25' );

gives us http://wpdev:8888/?p=1&somevar=24&somevar=25.

[winakeytoheaven]

We have located the bug to the Regex expression in line 3021 of wp-includes/formatting.php:

https://core.trac.wordpress.org/browser/trunk/src/wp-includes/formatting.php#L3021

All I have to do now is fix with the Regex expression.

[ocean90]

Replying to mordauk:

If we enter http://wpdev:8888/?p=1&somevar[]=24&somevar[]=25 into the URL of a custom link, we should get http://wpdev:8888/?p=1&somevar[]=24&somevar[]=25 back.

When the menu item is added, we actually get http://wpdev:8888/?p=1&somevar=24&somevar=25 instead.

This is a duplicate of #25567 and handled in #16859.

[diddledani]

Replying to chriscct7:

Checking the linked #16859 there appear to be appropriate unit tests in the supplied patch. I believe the same patch also correctly fixes this issue. I think therefore this issue should be marked as a duplicate of that ticket and closed.

[welcher]

Duplicate of #26657.

Closing as duplicate as per the above.