Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#18274 closed defect (bug) (invalid)

Add_query_arg doesn't cope with guid in url ie &p= becomes #038;p=

Reported by: anmari Owned by:
Milestone: Priority: normal
Severity: trivial Version: 3.2.1
Component: General Keywords:
Focuses: Cc:


Add_query_arg seems to convert the & relating to any existing query arguments in the query string to the html ascii - thus breaking the url.

Surely this is not the expected behaviour?

This is happening in WordPress 3.3-aortic-dissection, and in
WordPress 3.2.1


  • the link before add_query_arg


$link = add_query_arg('eventdate',$eventdate, $link );

*After add_query arg:


Change History (11)

#1 @anmari
4 years ago

Further input - it only seems to do this to the 'last' query arg.

So further 'add_query_arg's seem to treat existing query arguments acceptably.

eg: more added:


#2 @anmari
4 years ago

Even more input..... Can we modify the title? It maybe a case of "thou shalt not use the guid"

If the permalink is passed instead of guid, then first and subsequent add_query_args turn out okay. Bit spooky?

I did see in the codex a note that the while the post->gui looks like a post link for now, one should not assume that it will always be. So for now will replace with permalink and hope that sorts it out everywhere.


#3 @anmari
4 years ago

  • Severity changed from normal to minor
  • Summary changed from Add_query_arg doesn't cope with existing query arguments in url to Add_query_arg doesn't cope with guid in url ie &p= becomes #038;p

#4 @anmari
4 years ago

  • Summary changed from Add_query_arg doesn't cope with guid in url ie &p= becomes #038;p to Add_query_arg doesn't cope with guid in url ie &p= becomes #038;p=

#5 @anmari
4 years ago

  • Severity changed from minor to trivial

#7 @SergeyBiryukov
4 years ago

Can't reproduce on 3.3-aortic-dissection.

Here's what I do:

$link = 'http://localhost/wpbeta/?post_type=event&p=2530';
$link = add_query_arg('eventdate', '20110728T100000', $link );
echo htmlspecialchars($link);

This results in:


I only get what you get if I add & to the initial URL:

$link = 'http://localhost/wpbeta/?post_type=event&p=2530';
$link = add_query_arg('eventdate', '20110728T100000', $link );
echo htmlspecialchars($link);

#8 @nathanrice
4 years ago

Happening for me too. In my case, I've got a custom post type created (we'll call it "restaurant"). I've got a settings page as a submenu of "Restaurant". To pull the URL to the settings page I use menu_page_url( 'restaurant-settings', 0 ); which gives me this:


Actually, the source looks like this:


Here comes the bug. When I save the settings, I use add_query_arg() and wp_redirect() to add an updated flag to the URL, so I can push an admin notice.

When I do, the resulting URL to which the user is redirected looks like this:


add_query_arg() is getting confused when it sees & and completely borks the result.

The obvious solution is to not use URLs with character entities in them, or if the URL is generated, run it through html_entity_decode() before passing it to add_query_arg().

So, it IS a bug, but I'm not sure how serious it is, or whether it's a regression.

#9 @nacin
4 years ago

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

add_query_arg() does not do any encoding. This only happens when you have encoded data going into add_query_arg() to begin with.

nathanrice, your problem is that menu_page_url() was introduced with esc_url() on both return and echo. Not sure I like that behavior, but I'd suggest it is too late now. Perhaps we could esc_url_raw() for security and get away with only esc_url() when echo'ing. Please open a new ticket to change this behavior — this one is invalid.

#10 @nathanrice
4 years ago

@nacin, good point. I suppose add_query_arg() shouldn't be expected to accept encoded URLs.

Note: See TracTickets for help on using tickets.