WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 2 months ago

#21631 closed defect (bug) (duplicate)

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: 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 (11)

#1 @rocketwood
6 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
6 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
6 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
5 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
4 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
4 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
4 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.

#11 @welcher
2 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #26657.

Closing as duplicate as per the above.

Note: See TracTickets for help on using tickets.