WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 2 years ago

#21631 new defect (bug)

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

Reported by: rocketwood Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.4.1
Component: Menus Keywords: close
Focuses: Cc:

Description

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.

Change History (10)

#1 @rocketwood
5 years ago

  • Summary changed from Special characters in the custom menu's URL get double html encoded after second save to HTML encoded characters in the custom menu's URL html are dencoded after first save and removed after second save

#2 in reply to: ↑ description @rocketwood
5 years ago

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/

#3 @rocketwood
5 years ago

  • Summary changed from HTML encoded characters in the custom menu's URL html are dencoded after first save and removed after second save to HTML encoded characters in the custom menu's URL html are decoded after first save and removed after second save

#4 @scruffian
4 years ago

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

#5 follow-up: @mordauk
3 years ago

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.

#6 @winakeytoheaven
3 years ago

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.

#7 in reply to: ↑ 5 @ocean90
3 years ago

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.

#8 @chriscct7
2 years ago

  • Keywords has-unit-tests added

#9 follow-up: @chriscct7
2 years ago

  • Keywords needs-unit-tests added; has-unit-tests removed

#10 in reply to: ↑ 9 @diddledan
2 years ago

  • Keywords close added; needs-patch needs-unit-tests removed

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.

Note: See TracTickets for help on using tickets.