tilde signatures inside nowiki tags sometimes get expanded (<includeonly><nowiki>~~~~</nowiki></includeonly>)
OpenPublic

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 added a subscriber: wikibugs-l.
bzimport set Reference to bz93.
bzimport created this task.Via LegacyAug 16 2004, 6:00 AM
bzimport added a comment.Via ConduitAug 16 2004, 8:09 PM

jr_goblinp wrote:

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

bzimport added a comment.Via ConduitSep 19 2004, 8:05 AM

jeluf wrote:

Fixed in CVS REL1_3 and HEAD. See Bug 60.

bzimport added a comment.Via ConduitJun 14 2005, 12:58 PM

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

bzimport added a comment.Via ConduitJun 14 2005, 1:00 PM

foenyx wrote:

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

bzimport added a comment.Via ConduitJun 14 2005, 3:12 PM

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.

bzimport added a comment.Via ConduitJun 27 2005, 12:08 PM

zigger wrote:

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

brion added a comment.Via ConduitAug 28 2005, 9:12 PM
  • Bug 3290 has been marked as a duplicate of this bug. ***
brion added a comment.Via ConduitAug 28 2005, 9:13 PM
  • Bug 3289 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitDec 1 2005, 10:12 AM

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

bzimport added a comment.Via ConduitDec 1 2005, 10:27 AM

alarm wrote:

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

bzimport added a comment.Via ConduitFeb 15 2006, 4:16 PM

koneko wrote:

how convenient :)

bzimport added a comment.Via ConduitFeb 16 2006, 2:03 AM

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.Via ConduitApr 1 2006, 2:18 AM
  • Bug 5419 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitApr 29 2006, 2:20 AM

robchur wrote:

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

Pietrodn added a comment.Via ConduitJan 18 2009, 6:44 PM

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.Via ConduitFeb 3 2009, 4:06 AM

Confirmed comment #15 on local install (r46753).

bzimport added a comment.Via ConduitJul 24 2009, 10:04 AM

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>

bzimport added a comment.Via ConduitAug 15 2009, 4:06 AM

herd wrote:

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

bzimport added a comment.Via ConduitNov 26 2009, 3:55 AM

paul.copperman wrote:

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

Anomie added a comment.Via ConduitFeb 14 2011, 2:21 AM

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

MarkAHershberger added a comment.Via ConduitMay 27 2011, 8:58 PM

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

MarkAHershberger added a comment.Via ConduitMay 29 2011, 11:24 PM

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

bzimport added a comment.Via ConduitJun 7 2011, 3:14 PM

paul.copperman wrote:

Tried another fix for this in r89648.

brion added a comment.Via ConduitJun 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.

Platonides added a comment.Via ConduitJun 7 2011, 9:34 PM

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

bzimport added a comment.Via ConduitJun 7 2011, 9:56 PM

paul.copperman wrote:

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

bzimport added a comment.Via ConduitJun 7 2011, 10:32 PM

paul.copperman wrote:

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

bzimport added a comment.Via ConduitNov 9 2011, 8:44 PM

sumanah wrote:

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

bzimport added a comment.Via ConduitJun 22 2012, 7:40 PM

Thehelpfulonewiki wrote:

Reassigning to wikibugs-l per bug 37789

Matanya added a comment.Via ConduitJul 25 2012, 8:02 PM

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.

Platonides added a comment.Via ConduitJul 26 2012, 12:08 AM

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

bzimport added a comment.Via ConduitSep 12 2012, 3:49 PM

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

Jackmcbarn added a comment.Via ConduitSep 28 2014, 10:09 PM

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.

duplicatebug removed a subscriber: duplicatebug.Via WebDec 13 2014, 11:38 AM

Add Comment