#formlink delivers incorrect data to a form if there is an & character in one of the template parameters, like this:
{{#formlink: form=Some form
| link text = Click here | ||
| query string = Some form[Some property]={{{Some parameter with an ampersand like Ben & Jerry's | }}}&Some form[Some other property]={{{Some other parameter | }}} |
}}
Version: unspecified
Severity: trivial
Forgot to mention that manually using {{urlencode: }} on all parameters works around the problem. Perhaps there's no other clean way of resolving this? Off the top of my head, I'm just guessing that the only way for #formlink to solve this is to choose another delimiter to separate parameters. I suppose it could be configurable, like delimiter=&&&&
If I could control user input (which isn't possible) %26 or & would work.
Since I can't control user input, #formlink requires workarounds to validate the data entered by users, url-encoding of all parameters, or both. I'm changing this to WONTFIX, since the characters are provably not handled correctly, which makes this bug report valid, but maybe not one to bother with fixing.
I don't know how #formlink handles the query string - is it possible for it to distinguish where the parameters are, so it can url-encode them? I'm not sure if that can be done reliably, which would be another reason to "WONTFIX" this bug report. Does the MediaWiki parser do its job before #formlink gets a chance to manipulate parameters?
Setting this back to "invalid" - #formlink does with the "query string" parameter exactly what it says it will do, which is to pass it to the query string. Any intelligence beyond that is out of its scope.
That sounds like the definition of "WONTFIX". I reported this correctly, so I just changed it back. If you want to insist on it being marked as invalid, can you explain why? I see no aspect of this report that is incorrect in any way. Your decision to not fix it is sound, but that doesn't have anything to do with the validity of the information I reported here, as far as I can tell.
It's invalid because there's no bug there - the fact that an '&' in the wrong place in the query string causes problems is simply a function of how query strings work.
I just took a look at the code, and I see what you mean about this not being a bug. Even though I don't follow exactly what's going on, except for the \n\n workaround, it's obvious the code for #formlink wasn't intended to validate the data. I guess maybe you would prefer to call this bug report an enhancement. Either way, the bug/enhancement report is still correct. Being correct means it's not invalid.
On to more important issues...
{{fullurl:}} and external link syntax can handle query string data more reliably than #formlink, but without some of its features, so for #formlink to be more useful, it needs to work in the same cases.
It looks like there's a built-in url-encoding function in PHP:
http://php.net/manual/en/function.urlencode.php
All that needs to be done is isolate the parameter values, url-encode them, and then return the string. The code for #formlink is in SF_ParserFunctions.php, beginning on line 158 and ending on line 166. I don't understand it much, but I'm guessing the variable that holds the #formlink parameter values is $params.
Beyond that, I'm not sure what to do next. Do you have any advice if I want to try figuring out how to fix this?