Ticket #4084 (closed defect: fixed)

Opened 2 years ago

Last modified 1 year ago

add_query_arg urldecodes passed values but doesn't re-encode them.

Reported by: mdawaffe Assigned to: rob1n
Priority: low Milestone: 2.2
Component: General Version: 2.2
Severity: normal Keywords: has-patch
Cc:

Description

It also needs a small tweak regarding the removal of extraneous question marks.

Attachments

4084.diff (0.7 kB) - added by mdawaffe on 04/05/07 03:07:52.
4084b.diff (1.3 kB) - added by mdawaffe on 04/12/07 07:45:16.
idea

Change History

04/05/07 03:07:52 changed by mdawaffe

  • attachment 4084.diff added.

04/05/07 03:07:54 changed by rob1n

  • owner changed from anonymous to rob1n.

04/05/07 03:09:58 changed by rob1n

It looks fine. I think we should test this, though. Just to make sure "double encoding" works as we want it to.

04/05/07 03:10:15 changed by rob1n

  • keywords set to has-patch.
  • component changed from Administration to General.

04/06/07 04:21:23 changed by rob1n

  • status changed from new to closed.
  • resolution set to fixed.

(In [5193]) Re-encode query values after passed to add_query_arg(). Props mdawaffe. fixes #4084

04/07/07 00:04:53 changed by mdawaffe

  • status changed from closed to reopened.
  • resolution deleted.

This ticket urlencodes every argument. Perhaps we should only urlencode those arguments that have passed through parse_str? That would keep things as backward compatible as possible.

What we do now (urlencoding everything, even new arguments) makes the most since but is not backward compatible.

For example, there are a few places in core (and surely plugins too) that do:

add_query_arg( 'foo', urlencode($bar), $url );

That is, the arg is manually urlencoded. Those args will probably now get double encoded with the current code in trunk.

So do we go for a function that works like (I think) it seems like it should, or do we go with a less convenient function that preserves backward compatibility?

Related to #4105 (slash behavior)

04/10/07 06:45:48 changed by rob1n

I think preserving backwards compatibility is important. Whenever we try to switch something up on plugin authors (even with tons of warning -- *cough* $table* *cough*) isn't a good idea. Considering history.

As long as it works (double encoding/decoding), then I see no reason to fix it further.

04/10/07 23:36:55 changed by rob1n

  • status changed from reopened to closed.
  • resolution set to fixed.

04/11/07 03:37:49 changed by rob1n

  • status changed from closed to reopened.
  • resolution deleted.

04/11/07 03:41:44 changed by rob1n

(In [5240]) Rollback wonky part of [5193]. see #4084

04/12/07 07:45:16 changed by mdawaffe

  • attachment 4084b.diff added.

idea

04/12/07 07:46:08 changed by mdawaffe

4084b.diff

Only urlencode()s things that have gone through parse_str().

04/12/07 17:05:10 changed by rob1n

Hmm. Looks interesting. I'll look at this when I get back later.

04/12/07 22:00:25 changed by rob1n

  • status changed from reopened to closed.
  • resolution set to fixed.

(In [5261]) Get add_query_arg() to urlencode all values of parse_str array. Props mdawaffe. fixes #4084

05/12/07 07:15:37 changed by majelbstoat

Just so you're aware, this did break another useful function of add_query_arg, which was in easily adding arguments to param style arguments, like for wp_list_pages(). I was using it, for example, to quickly append rewrite rule query entries. So, for those who were doing a similar thing and specifically didn't want things urlencoding, the workaround is to rawurlencode the argument you pass to add_query_arg and then urldecode the whole result.

09/08/07 14:27:25 changed by markjaquith

(In [6064]) Only urlencode previously existing values in add_query_arg() (more backwards compatible). fixes #4935. see #4084. see #4878