Last modified: 2014-09-28 22:09:32 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&user_id=1052697&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.
*** Bug 102 has been marked as a duplicate of this bug. ***
Fixed in CVS REL1_3 and HEAD. See Bug 60.
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
the bug 2172 is probably related to this too. (nowiki tags and galleries in template)
(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.
*** Bug 2546 has been marked as a duplicate of this bug. ***
*** Bug 3290 has been marked as a duplicate of this bug. ***
*** Bug 3289 has been marked as a duplicate of this bug. ***
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.
A simple workaround - in such templates use ~ instead of '~' and nowiki tag will not be required
how convenient :)
(In reply to comment #10) > A simple workaround - in such templates use ~ 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.
*** Bug 5419 has been marked as a duplicate of this bug. ***
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
Confirmed comment #15 on local install (r46753).
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> ================
*** Bug 20248 has been marked as a duplicate of this bug. ***
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.
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).
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.
r88997 reverted in r89308, restoring the previous behavior for now. The test case added in r89191 remains in parserTests.txt but is disabled.
Tried another fix for this in r89648.
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()
(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 :)
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?
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>.
Adding "patch" and "reviewed" keywords for consistency, since this bug contains reviewed patches.
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
This bug still "works" with <nowiki> tags and <!-- HTML comment --> too: http://en.wikipedia.org/wiki/User:Rappy4178/sandbox
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.
