tilde signatures inside nowiki tags sometimes get expanded (<includeonly><nowiki>~~~~</nowiki></includeonly>)
Open, LowestPublic

Description

Author: timwi

Description:
BUG MIGRATED FROM SOURCEFORGE
http://sourceforge.net/tracker/index.php?func=detail&aid=962917&group_id=34373&atid=411192
Originally submitted by jrdioko (jrdioko)<a href="/help/icon_legend.php?context=user_wantsdonations&amp;user_id=1052697&amp;return_to=%2F"><IMG src="http://images.sourceforge.net/images/icons/donate.png" alt="Accepting Donations" border="0" width="16" height="16"></a> 2004-05-29 23:38

I have created a boilerplate template in the Mediawiki:
namespace which I've been using to welcome new users.
In a section explaining how to use tildes to sign posts, I
use the following code:

"To insert just your name, type <nowiki>~~~</nowiki>
(3 tildes), or, to insert your name and timestamp, use
<nowiki>~~~~</nowiki> (4 tildes)."

Under MediaWiki 1.2, this used to work fine, and using
the {{subst:}} method to insert that text into a user's
talk page would produce the following:

"To insert just your name, type ~~~ (3 tildes), or, to
insert your name and timestamp, use ~~~~ (4 tildes)."

Now, in 1.3, the parsing rules seem to have changed, as
that same {{subst:}} method on the same boilerplate
template results in the tildes being expanded to my full
signatures. The <nowiki> tags are included, but result in
the code of the signatures not being parsed rather than
the tildes themselves staying as is.

I assume a change has been made so that tildes can be
used in templates and a current signature can be
inserted along with the template text. However, I think
there needs to be some way to prevent the tildes from
being parsed (preferably through the use of <nowiki>
tags).

Thanks.

  • Additional comments ------------------------

Date: 2004-08-05 07:23
Sender: SF user vibber

Tentative patch here: http://wp.wikidev.net/User:Brion/Tilde_bug

I'm not certain it won't break something else, so haven't committed
it
yet.


Version: 1.23.0
Severity: normal

bzimport set Reference to bz93.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Aug 16 2004, 6:00 AM

jr_goblinp wrote:

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

jeluf wrote:

Fixed in CVS REL1_3 and HEAD. See Bug 60.

magnusrk+wiki wrote:

This bug is active again in both 1.4.5 and 1.5. Can't say why, but maybe related to the fix for Bug 1188?

Example: http://test.leuksman.com/index.php/User:Dashiva#Subst_and_nowiki

foenyx wrote:

the bug 2172 is probably related to this too. (nowiki tags and galleries in
template)

wegge wrote:

(In reply to comment #3)

This bug is active again in both 1.4.5 and 1.5. Can't say why, but maybe

related to the fix for Bug 1188?

Example: http://test.leuksman.com/index.php/User:Dashiva#Subst_and_nowiki

I've changed the order of things in Parser:pstPass2()

A test page is available on http://playwiki.wegge.dk/Subst_1

I have probably broken something else by this change, so please try to find out
how it breaks.

zigger wrote:

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

brion added a comment.Aug 28 2005, 9:12 PM
  • Bug 3290 has been marked as a duplicate of this bug. ***
brion added a comment.Aug 28 2005, 9:13 PM
  • Bug 3289 has been marked as a duplicate of this bug. ***

alarm wrote:

A fix, which adds second nowiki handling after template substitution

Problem - if using "subst:", raw template content is included in pstPass2 and
~~~~, etc are replaced even if in nowiki.
Adding a second call to a strip after a call to a replaceVariables solves a
problem.

attachment Parser.php.patch ignored as obsolete

alarm wrote:

A simple workaround - in such templates use &#126; instead of '~' and nowiki tag will not be required

koneko wrote:

how convenient :)

gangleri wrote:

(In reply to comment #10)

A simple workaround - in such templates use &#126; instead of '~' and nowiki

tag will not be required

This sounds more like a joke. I think there are enough problems with character
normalisation (some related to usage of %nn). If the nowiki tag is supposed to
be used for "escaping" this should be enough.

brion added a comment.Apr 1 2006, 2:18 AM
  • Bug 5419 has been marked as a duplicate of this bug. ***

robchur wrote:

Patch from comment 9 seems to solve the problem. Applied to SVN trunk, r13917.

It still expands the signature if the nowiki tags are in includeonly tags.
For example, when I save the code:
<includeonly><nowiki>~~~~</nowiki></includeonly>
I get:
<includeonly><nowiki>[[Utente:Pietrodn|Pietrodn]] · [[Discussioni utente:Pietrodn|«zitto e parla!»]] 19:42, 18 gen 2009 (CET)</nowiki></includeonly>

Test: http://it.wikipedia.org/w/index.php?title=Utente%3APietrodn%2FSandbox1&diff=21438577&oldid=21438545

demon added a comment.Feb 3 2009, 4:06 AM

Confirmed comment #15 on local install (r46753).

happy.melon.wiki wrote:

Still present in 1.15-alpha-wmf r53410:

*aaa~~~bbb
*<nowiki>aaa~~~bbb</nowiki>

*<includeonly>aaa~~~bbb</includeonly>
*<includeonly><nowiki>aaa~~~bbb</nowiki></includeonly>

*<noinclude>aaa~~~bbb</noinclude>
*<noinclude><nowiki>aaa~~~bbb</nowiki></noinclude>

*<onlyinclude>aaa~~~bbb</onlyinclude>

*<onlyinclude><nowiki>aaa~~~bbb</nowiki></onlyinclude>

becomes

*aaa<EXPANDED_SIG>bbb
*<nowiki>aaa~~~bbb</nowiki>

*<includeonly>aaa<EXPANDED_SIG>bbb</includeonly>
*<includeonly><nowiki>aaa<EXPANDED_SIG>bbb</nowiki></includeonly>

*<noinclude>aaa<EXPANDED_SIG>bbb</noinclude>
*<noinclude><nowiki>aaa~~~bbb</nowiki></noinclude>

*<onlyinclude>aaa<EXPANDED_SIG>bbb</onlyinclude>

*<onlyinclude><nowiki>aaa~~~bbb</nowiki></onlyinclude>

herd wrote:

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

Proposed patch: Strip ignored parts before pst

IMHO, the ignored parts (<includeonly>...</includeonly>) shouldn't be touched by the pre-save transformation at all. This behavior would also be more consistent, as substed templates aren't expanded either, when they occur inside <includeonly> tags.

The attached patch will change the preprocessor so it replaces the ignored parts with a strip marker before pstPass2, just like comments and other tags are handled already.

Attached: bug93.patch

Created attachment 8141
Patch to allow PST to function normally inside <includeonly>

As an alternative to P.Copp's patch which completely prevents PST inside <includeonly>, here is one that allows PST to happen inside <includeonly> as would normally be expected.

One or the other of these really should be applied, as the current behavior is totally broken. I think this patch more closely conforms to the expectations of most users (witness the complaints that signatures, substitution, and the pipe trick don't work inside <ref> tags).

Attached: 1

Applied Brad's patch in r88997. I really doubt this one will cause pain like the other time I fixed an ancient problem.

And, lo, I was wrong. See P.Copp's comments here: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88997#c17304

Targeting this for newparser.

brion added a comment.Jun 2 2011, 12:35 AM

r88997 reverted in r89308, restoring the previous behavior for now. The test case added in r89191 remains in parserTests.txt but is disabled.

P.Copp added a comment.Jun 7 2011, 3:14 PM

Tried another fix for this in r89648.

brion added a comment.Jun 7 2011, 5:36 PM

Please don't commit new versions of this without very, very clear review first.

Reverted in r89662; the commit changed PST behavior for all 'includeonly' sections, including altering a parser test case to hide the regression. Commit also failed to update all preprocessor classes; there's also now Preprocessor_HipHop.hphp.

Next one trying to fix this, please look at expand(), not at preprocessToObj()

P.Copp added a comment.Jun 7 2011, 9:56 PM

(In reply to comment #25)

Please don't commit new versions of this without very, very clear review first.

Reverted in r89662; the commit changed PST behavior for all 'includeonly'
sections, including altering a parser test case to hide the regression. Commit
also failed to update all preprocessor classes; there's also now
Preprocessor_HipHop.hphp.

The parser test wasn't changed to hide a regression but to adapt to the new behavior, please see the explanation in comment 19 and r89648.

(In reply to comment #26)

Next one trying to fix this, please look at expand(), not at preprocessToObj()

That's what I did :)

brion added a comment.Jun 7 2011, 10:08 PM

The 'new behavior' doesn't appear to be desirable offhand, and isn't what the bug originally discusses at all.

It's perhaps not an unreasonable argument that other things don't get expanded in there, but without some discussion I'd be leery of just going in and changing it unilaterally.

I proposed the patch with the new behavior in November 2009, the only other proposal to fix the bug since then was Brad Jorsch's patch, which turned out to be unusable for other reasons.
So, where should the discussion take place? Should I open another bug which blocks this one?

brion added a comment.Jun 7 2011, 10:39 PM

Lack of any discussion on a bug in two years doesn't necessarily mean "go ahead and commit", especially when it comes to the core markup parser. :)

Quite possibly we'll want to avoid making any changes here at all; the parser's being frozen and rewritten to provide a compatible, but more maintainable version for the future... Future major changes to markup internals will probably involve migrating to more consistent internal structures & markup, so old-style and new-style pages can live side-by-side.

If a change is needed, offhand it sounds like we should only be trying to solve the originally reported bug here: a <nowiki>'s content should never get PST'd, even inside an <includeonly>.

sumanah wrote:

Adding "patch" and "reviewed" keywords for consistency, since this bug contains reviewed patches.

Thehelpfulonewiki wrote:

Reassigning to wikibugs-l per bug 37789

I think this is no longer a bug.

please see: https://he.wikipedia.org/wiki/%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Matanya/test

closing as works for me.

The bug 93 parser test still fails:
-<includeonly><nowiki>~~~~</nowiki></includeonly>
+<includeonly><nowiki>[[Special:Contributions/127.0.0.1|127.0.0.1]] 00:06, 26 July 2012 (UTC)</nowiki></includeonly>

See https://he.wikipedia.org/w/index.php?title=%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Matanya/test&action=edit&undoafter=12784195&undo=12785112

tomta1 wrote:

This bug still "works" with <nowiki> tags and <!-- HTML comment --> too: http://en.wikipedia.org/wiki/User:Rappy4178/sandbox

Qgil added a comment.Apr 11 2014, 4:29 PM

Still happening.

While the bug reported in comment 0 remains to be fixed, the case reported in comment 15 can be still be reproduced.

Writing

<includeonly><nowiki>~~~~</nowiki></includeonly>

and saving the page will result in

<includeonly><nowiki>[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 16:19, 11 April 2014 (UTC)</nowiki></includeonly>

Test:

https://www.mediawiki.org/w/index.php?title=User:Qgil/Sandbox/TestBug93&action=edit&oldid=955872

I notice that inside includeonly tags, both signatures and the pipe trick get expanded, whereas substed templates don't, and all of this is independent of any nowiki-ing.

Add Comment