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

[anmari]

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

EG:

• the link before add_query_arg

​http://localhost/wpbeta/?post_type=event&p=2530

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

*After add_query arg:

​http://localhost/wpbeta/?post_type=event&eventdate=20110728T100000#038;p=2530

[anmari]

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:

​http://localhost/wpbeta/?post_type=event&eventdate=20110824T100000&duration=PT30M&feed=ics#038;p=2530

[anmari]

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.

​http://localhost/wpbeta/event/daily/?eventdate=20110824T100000&duration=PT30M&feed=ics

[johnbillion]

Related: #17923

[SergeyBiryukov]

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:

http://localhost/wpbeta/?post_type=event&p=2530&eventdate=20110728T100000

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);

[nathanrice]

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:

http://example.com/wp-admin/edit.php?post_type=restaurant&page=restaurant-settings

Actually, the source looks like this:

http://example.com/wp-admin/edit.php?post_type=restaurant&page=restaurant-settings

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:

http://example.com/wp-admin/edit.php?post_type=restaurant&updated=true#038;page=restaurant-settings

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.

[nacin]

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.

[nathanrice]

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

[nathanrice]

See #19248