Last modified: 2011-08-02 14:07:57 UTC
Hi, Up to not long ago, or at least I think, I {{fullurl:}} could receive a $1 parameter in the mediawiki site messages and translate the parameter before running the fullurl function. Now it does not. i.e. this: {{fullurl:$1|redirect=no}} used to work. Can this be fixed? Also {{urlencode:$1}} gives $1 and not the link... I personally only need on of these to work, but perhaps it will be best if $1 parameters are passed first to templates in mediawiki site messages. Thanks.
{{urlencode:$1}} produces "%241", the "%24" being an encoding of the dollar sign symbol. This was fixed for at least a few hours, then reverted back. http://en.wikipedia.org/wiki/User_talk:Brion_VIBBER#re:_changes_to_link_syntax_behavior
In particular, this bug affects the [[MediaWiki:Searchquery]] and [[MediaWiki:Blockipsuccesstext]] messages on enwiki. Both of these break if accessed via secure.wikimedia.org, since they use hardcoded URLs rather than {{localurl:}}. The latter also breaks if the parameter contains spaces or other URL-unsafe characters (see f.ex. http://en.wikipedia.org/w/index.php?title=Special:Blockip&action=success&ip=Willy+on+Wheels).
Another pretty often used example is link to some log, eg: Page was [{{fullurl:Special:Log|type=move&page={{urlencode:$1}}}} moved] which would be useful eg. on MediaWiki:Nogomatch.
Created attachment 2355 [details] Proposed patch This occurs because curly-brace stuff is evaluated in Parser::transformMsg, before wfMsgReplaceArgs is called. That means $1 can be transcluded from templates and dealt with properly, but also that any string modification screws stuff up. Parser::replaceVariables can't reasonably know what $#s are legitimate replacement thingies to be left alone, and which should be replaced as normal; we can't tell the parser functions to stop replacing $1 altogether in messages because most messages don't use $1 and so it *should* be escaped. Therefore, the only solution appears to be to have wfMsgReplaceArgs treat %24 identically to $. Will that cause some collateral damage? Marginally, but realistically not much more than already happens. Patch isn't really tested, but it appears to solve the problem at least at a quick glance. I might test it more later.
Comment on attachment 2355 [details] Proposed patch Argh, what am I saying? I need more sleep. That will paste in the contents of $1 all right, but they won't be urlencoded. That can be dealt with hackily as well, of course . . . Is there some good reason we're running replaceVariables *before* argument substitution anyway?
Simetrical: "Parameter replacements, if any, are done *after* parsing the wiki-text message, so parameters may contain HTML (eg links or form controls)." (from doc for wfMsgWikiHtml)
Sorry, never mind -- ignore what I just said.
OK. It looks like there is no way to fix this programming wise, perhaps it would be easier to creat a new series of {{fullurl:}} and {{urlencode:}} that will commence before (I'm under the impression that they are run after thesedays) parsing wiki-text messages. You can call these new functions/templates/replacements {{fullurlB:}} and {{urlencodeB:}} (B for "before"). Then we will have a series that runs before parsing the wiki-text message and a series that runs after parsing the wiki-text message.
(In reply to comment #4) > This occurs because curly-brace stuff is evaluated in Parser::transformMsg, > before wfMsgReplaceArgs is called. That means $1 can be transcluded from > templates and dealt with properly, but also that any string modification screws > stuff up. Parser::replaceVariables can't reasonably know what $#s are > legitimate replacement thingies to be left alone, and which should be replaced > as normal; we can't tell the parser functions to stop replacing $1 altogether > in messages because most messages don't use $1 and so it *should* be escaped. It seems to me that the proper fix would be to expand $1 et al. in the same stage named variables like {{PAGENAME}} are, i.e. _during_ template expansion. I haven't looked at the code to see how hard this would be -- presumably the parameters will need to be carried around during recursion -- but it's the one solution that will "Do The Right Thing" (i.e. work as expected). > Therefore, the only solution appears to be to have wfMsgReplaceArgs treat %24 > identically to $. Will that cause some collateral damage? Marginally, but > realistically not much more than already happens. Ewww...
(In reply to comment #8) > OK. It looks like there is no way to fix this programming wise, perhaps it would be easier to creat a new series > of {{fullurl:}} and {{urlencode:}} that will commence before (I'm under the impression that they are run after > thesedays) parsing wiki-text messages. Maybe, but that's the kind of thing that could cause more problems like this down the road, and then that has to be fixed, so you get complexity layered on top of complexity . . . a hack, in other words. In that respect, much like my previous patch (which could easily be fixed up with, of course, further hackiness). (In reply to comment #9) > It seems to me that the proper fix would be to expand $1 et al. in the same > stage named variables like {{PAGENAME}} are, i.e. _during_ template expansion. > I haven't looked at the code to see how hard this would be -- presumably the > parameters will need to be carried around during recursion -- but it's the one > solution that will "Do The Right Thing" (i.e. work as expected). I dismissed it in my last post with "Parser::replaceVariables can't reasonably know what $#s are legitimate replacement thingies to be left alone, and which should be replaced as normal", but really, it *is* the way to go. You would need to pass the array of stuff to be replaced to Parser::transformMsg, and from there to Parser::replaceVariables, where the replacements would be executed between loops. It should hardly be difficult, I suppose, but I haven't tried to mess with that code before.
Changing summary to be more universal and easy to find (I hope). Anyway it would more natural to me if something like this would work: {{#if:$1|not empty|empty}} could use this one on [[MediaWiki:Badfiletype]] to solve the no extension issue: ("." is not an allowed file format. See Commons:File types for more information.) I'm not sure if this is the best way to solve things like that, but still (as already mentioned) it would be more natural to have the value of $1 before {{#function:$1}} is parsed.
*** Bug 9735 has been marked as a duplicate of this bug. ***
I'm a little confused. The above comments mean this bug is not solved yet. On Farsi Wikipedia, this bug persists (see bug 9735 for links and details) but it doesn't on English Wikipedia? Is it that the code has been changed only for EN WP?
The texts in bug 9735 are different: one uses indirection via templates, the other doesn't.
Thank you. For future reference, I would like to reword what you said: The code behind the links for the old and new address, when put in a template, are processed before the rest of the code of MediaWiki:Pagemovedtext, and will work correctly.
*** Bug 10401 has been marked as a duplicate of this bug. ***
In a lot of cases, it's quite desirable to allow message transformation to take place. For messages which are expecting things to be parsed or whatever, it's a good idea to use wfMsgExt() with the right combination of modifiers, which will suppress transformation if parsing.
Rob, having this solution at hand, are you going to apply this to Pagemovedtext or its successor?
"pagemovedtext" no longer exists; the message has been withdrawn in favour of "movepage-moved", which has a different set of parameters.
Rob, in this case can "MediaWiki default" user be used to remove all depricated messages on Wikimedia projects?
When searching for "foo bar", even {{FULLURLE:...$1...|...$1...}} is broken to half ([[MediaWiki:Noexactmatch]])!
No, sorry; {{FULLURLE:...$1...|...$1...}} does not work at all (shows $1, of course)! [http://...$1 Text] was meant (the reason why FULLURLE would be needed ;-)
Something weird about this conversation in Bugzilla: it's listed in [https://bugzilla.wikimedia.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=bug_status&field-1-1-0=product&field-1-2-0=resolution&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=substring&product=MediaWiki&query_format=advanced&remaction=&resolution=---&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&type0-0-0=noop&value-1-0-0=UNCONFIRMED%2CNEW%2CASSIGNED%2CREOPENED&value-1-1-0=MediaWiki&value-1-2-0=---&value0-0-0=&votes=&order=bugs.delta_ts%2Cbugs.delta_ts%2Cbugs.delta_ts%2Cbugs.bug_status%2Cbugs.priority%2Cmap_assigned_to.login_name%2Cbugs.bug_id&query_based_on= this search] as last changed in 1970 (at least on my computer). No idea why.
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Can this be marked as fixed since we changed a good part of messages to replace parameters before parsing?
