Last modified: 2011-08-02 14:07:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6261 - Parser functions to receive parameters like $1 in MediaWiki site messages (especially fullurl, urlencode, localurl, ...)
Parser functions to receive parameters like $1 in MediaWiki site messages (es...
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low normal with 10 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: testme
: 9735 (view as bug list)
Depends on: 10400
Blocks: 10399
  Show dependency treegraph
 
Reported: 2006-06-09 22:05 UTC by yonidebest
Modified: 2011-08-02 14:07 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Proposed patch (734 bytes, patch)
2006-09-15 04:19 UTC, Aryeh Gregor (not reading bugmail, please e-mail directly)
Details

Description yonidebest 2006-06-09 22:05:46 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.
Comment 1 freakofnurture 2006-06-28 14:23:15 UTC
{{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
Comment 2 Ilmari Karonen 2006-06-30 16:16:41 UTC
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).
Comment 3 Danny B. 2006-08-25 12:31:12 UTC
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.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-09-15 04:19:02 UTC
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 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-09-15 04:23:59 UTC
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?
Comment 6 Dan Li 2006-09-15 04:48:34 UTC
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)
Comment 7 Dan Li 2006-09-15 05:05:27 UTC
Sorry, never mind -- ignore what I just said.
Comment 8 yonidebest 2006-09-15 07:59:55 UTC
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.
Comment 9 Ilmari Karonen 2006-09-15 11:00:41 UTC
(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...
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-09-17 01:27:36 UTC
(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.
Comment 11 Nux 2006-12-03 02:23:46 UTC
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.
Comment 12 Brion Vibber 2007-04-30 18:59:10 UTC
*** Bug 9735 has been marked as a duplicate of this bug. ***
Comment 13 Huji 2007-04-30 21:33:18 UTC
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?
Comment 14 Brion Vibber 2007-04-30 22:31:33 UTC
The texts in bug 9735 are different: one uses indirection via templates, the
other doesn't.
Comment 15 Huji 2007-05-01 14:19:16 UTC
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.
Comment 16 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-28 18:10:07 UTC
*** Bug 10401 has been marked as a duplicate of this bug. ***
Comment 17 Rob Church 2007-06-28 18:21:08 UTC
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.
Comment 18 Huji 2007-06-29 07:16:25 UTC
Rob, having this solution at hand, are you going to apply this to Pagemovedtext or its successor?
Comment 19 Rob Church 2007-06-29 07:37:16 UTC
"pagemovedtext" no longer exists; the message has been withdrawn in favour of "movepage-moved", which has a different set of parameters.
Comment 20 Huji 2007-06-29 13:32:30 UTC
Rob, in this case can "MediaWiki default" user be used to remove all depricated messages on Wikimedia projects?
Comment 21 Melancholie 2008-02-27 18:24:54 UTC
When searching for "foo bar", even {{FULLURLE:...$1...|...$1...}} is broken to half ([[MediaWiki:Noexactmatch]])!
Comment 22 Melancholie 2008-02-27 18:27:39 UTC
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 ;-)
Comment 24 p858snake 2011-04-30 00:09:56 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 25 Alexandre Emsenhuber [IAlex] 2011-08-02 14:07:57 UTC
Can this be marked as fixed since we  changed a good part of messages to replace parameters before parsing?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links