Last modified: 2014-09-28 22:09:32 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 93 - tilde signatures inside nowiki tags sometimes get expanded (<includeonly><nowiki>~~~~</nowiki></includeonly>)
tilde signatures inside nowiki tags sometimes get expanded (<includeonly><now...
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
1.23.0
All All
: Lowest normal with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: need-parsertest, newparser, patch, patch-reviewed
: 102 2546 3289 3290 5419 20248 (view as bug list)
Depends on: 22602
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-16 06:00 UTC by Timwi
Modified: 2014-09-28 22:09 UTC (History)
20 users (show)

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


Attachments
A fix, which adds second nowiki handling after template substitution (1.21 KB, patch)
2005-12-01 10:12 UTC, Andrius Ramanauskas
Details
Proposed patch: Strip ignored parts before pst (1.76 KB, patch)
2009-11-26 03:55 UTC, P.Copp
Details
Patch to allow PST to function normally inside <includeonly> (1.42 KB, patch)
2011-02-14 02:21 UTC, Brad Jorsch
Details

Description Timwi 2004-08-16 06:00:59 UTC
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.
Comment 1 Johnathan 2004-08-16 20:09:37 UTC
*** Bug 102 has been marked as a duplicate of this bug. ***
Comment 2 JeLuF 2004-09-19 08:05:02 UTC
Fixed in CVS REL1_3 and HEAD. See Bug 60.
Comment 3 Dashiva 2005-06-14 12:58:08 UTC
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
Comment 4 FoeNyx 2005-06-14 13:00:53 UTC
the bug 2172 is probably related to this too. (nowiki tags and galleries in
template)
Comment 5 Anders Wegge Jakobsen 2005-06-14 15:12:43 UTC
(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.
Comment 6 Zigger 2005-06-27 12:08:23 UTC
*** Bug 2546 has been marked as a duplicate of this bug. ***
Comment 7 Brion Vibber 2005-08-28 21:12:00 UTC
*** Bug 3290 has been marked as a duplicate of this bug. ***
Comment 8 Brion Vibber 2005-08-28 21:13:22 UTC
*** Bug 3289 has been marked as a duplicate of this bug. ***
Comment 9 Andrius Ramanauskas 2005-12-01 10:12:27 UTC
Created attachment 1121 [details]
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.
Comment 10 Andrius Ramanauskas 2005-12-01 10:27:01 UTC
A simple workaround - in such templates use &#126; instead of '~' and nowiki tag will not be required
Comment 11 Darkoneko 2006-02-15 16:16:00 UTC
how convenient :)
Comment 12 lɛʁi לערי ריינהארט 2006-02-16 02:03:57 UTC
(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.
Comment 13 Brion Vibber 2006-04-01 02:18:19 UTC
*** Bug 5419 has been marked as a duplicate of this bug. ***
Comment 14 Rob Church 2006-04-29 02:20:50 UTC
Patch from comment 9 seems to solve the problem. Applied to SVN trunk, r13917.
Comment 15 Pietrodn 2009-01-18 18:44:38 UTC
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
Comment 16 Chad H. 2009-02-03 04:06:08 UTC
Confirmed comment #15 on local install (r46753).
Comment 17 Happy-melon 2009-07-24 10:04:09 UTC
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>
================

Comment 18 Splarka 2009-08-15 04:06:19 UTC
*** Bug 20248 has been marked as a duplicate of this bug. ***
Comment 19 P.Copp 2009-11-26 03:55:07 UTC
Created attachment 6824 [details]
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.
Comment 20 Brad Jorsch 2011-02-14 02:21:07 UTC
Created attachment 8141 [details]
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).
Comment 21 Mark A. Hershberger 2011-05-27 20:58:25 UTC
Applied Brad's patch in r88997.  I really doubt this one will cause pain like the other time I fixed an ancient problem.
Comment 22 Mark A. Hershberger 2011-05-29 23:24:09 UTC
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.
Comment 23 Brion Vibber 2011-06-02 00:35:23 UTC
r88997 reverted in r89308, restoring the previous behavior for now. The test case added in r89191 remains in parserTests.txt but is disabled.
Comment 24 P.Copp 2011-06-07 15:14:48 UTC
Tried another fix for this in r89648.
Comment 25 Brion Vibber 2011-06-07 17:36:33 UTC
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.
Comment 26 Platonides 2011-06-07 21:34:16 UTC
Next one trying to fix this, please look at expand(), not at preprocessToObj()
Comment 27 P.Copp 2011-06-07 21:56:33 UTC
(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 :)
Comment 28 Brion Vibber 2011-06-07 22:08:12 UTC
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.
Comment 29 P.Copp 2011-06-07 22:32:53 UTC
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?
Comment 30 Brion Vibber 2011-06-07 22:39:28 UTC
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>.
Comment 31 Sumana Harihareswara 2011-11-09 20:44:42 UTC
Adding "patch" and "reviewed" keywords for consistency, since this bug contains reviewed patches.
Comment 32 Thehelpfulone 2012-06-22 19:40:52 UTC
Reassigning to wikibugs-l per bug 37789
Comment 33 matanya 2012-07-25 20:02:48 UTC
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.
Comment 34 Platonides 2012-07-26 00:08:37 UTC
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
Comment 35 tomta1 2012-09-12 15:49:38 UTC
This bug still "works" with <nowiki> tags and <!-- HTML comment --> too: http://en.wikipedia.org/wiki/User:Rappy4178/sandbox
Comment 36 Quim Gil 2014-04-11 16:29:03 UTC
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
Comment 37 Jackmcbarn 2014-09-28 22:09:32 UTC
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.

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


Navigation
Links