freakofnurture wrote:

{{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.

ayg wrote:

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.

attachment 6261a.patch ignored as obsolete

ayg wrote:

Comment on attachment 2355
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?

dto wrote:

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)

dto wrote:

Sorry, never mind -- ignore what I just said.

yonidebest wrote:

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...

ayg wrote:

(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.

ayg wrote:

*** Bug 10401 has been marked as a duplicate of this bug. ***

robchur wrote:

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?

robchur wrote:

"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?

Wiki.Melancholie wrote:

When searching for "foo bar", even {{FULLURLE:...$1...|...$1...}} is broken to half ([[MediaWiki:Noexactmatch]])!

Wiki.Melancholie wrote:

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

lenoxuss wrote:

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?