Talk:Migration to the new preprocessor

Possible bugs

It is easy to find a difference in rendering. It is hard to determine if it is a new species of bug, or a known difference in rendering that needs on-site Wikicode tweaking, or a reported bug that will require server-side editing. If you have found a rendering difference that is not attributable to an entry under Expected differences (or you are having trouble telling), please list it here (with link or example code) for expert consideration.

Once it has been checked out and sorted appropriately, place [[Image:Pictogram voting keep.svg|32px|right]] (should it be a template?) in the section.

Diff matching

Problem with what is highlighted in a diff page. Never really had issues before today.. but it is no longer highlighting all changes correctly. Example [1] An entire second sentence was added but it only showed a couple changes. It completely misses highlighting "has argued that this closed-door meeting appeared to violate Arkansas' FOIA law".

I've also seen this on other changes I've made (or at least tests using the "show changes" button).

Please correct.. Morphh 22:56, 27 January 2008 (UTC)

Did some testing.. Firefox and IE work fine. Seems to be an issue with Safari, which I haven't used for very long.. so this may have not been introduced by the preprocessor. Something to look at regardless. Morphh 23:04, 27 January 2008 (UTC)

links in references

Some external links are showing up with the mail symbol instead of the link symbol. See en:Carnivora's References and External links sections. - UtherSRG 14:59, 27 January 2008 (UTC)

Looks like it is fixed now. - UtherSRG 23:49, 1 February 2008 (UTC)

P and Script

[2] [3] - Not sure what is going on with this one. The differnce between old/new only seems to happen in action=render (in action=view they return the same html). <p><script>...toc script...</script> vs <script>...toc script...</script>\n<p> -- have seen several more examples, but only in &action=render . -Splarka

Can't reproduce -- Tim Starling 04:33, 17 January 2008 (UTC)

id="UNIQ QINU"

[4] vs [5] - This is a subtle one. The id of certain table cells with ref tags passed as parameters to {{{EpisodeNumber}}} generate a UNIQ-QINU parser error that ends up as the ID tag. Is this something we need to investigate further? - Splarka

This is a bug in the old parser. Parser_OldPP.php line 3157 calls Sanitizer::removeHTMLtags() with replaceVariables as the callback, instead of attributeStripCallback. As a result, HTML attributes generated via template expansion may contain UNIQ markers. -- Tim Starling 04:33, 17 January 2008 (UTC)

Grease pit

please look at wikt:Wiktionary:Grease pit#Testing new parser, where a template (didyoumean) is acting differently when "called" from Mediawiki:Newarticletext; leaves one stray } that doesn't show under any other condition. Robert Ullmann 15:06, 17 January 2008 (UTC)

Found a fix for the problem... Both the old and the new parser are choking on 5 closing braces in a row: }}}}}, I have told connel to add a space in there. Note that the old parser apparently didn't care about this unless it was on the message itself, but the new one trips up even if it is transcluded. Tim is investigating now. Splarka 00:27, 18 January 2008 (UTC)

Update: Tim has tracked it to a double-parse in messages, added over 3 years ago: [6]. Splarka 02:27, 18 January 2008 (UTC)

Template:For

This template fails rather dramatically. --MZMcBride 02:48, 18 January 2008 (UTC)

The template was called with a parameter definition of the form "p=q=r", and used the parameter value "q=r" as parameter definition in another template, assigning "r" to parameter "q". As mentioned this is no longer possible. I adapted the template.--Patrick (talk) 18:16, 23 January 2008 (UTC)

w:Template:Salem-stub

This template on wikipedia has an extranuous <p><br /><p>. I've tracked it down to a somewhat minimal test case. A template call thusly:

<div>foo</div>

<noinclude>{{bar}}</noinclude>

And Template:Bar's contents:

{|
|baz
|}

Seems to need the block level element, blank newline, noinclude, and transcluded table, to show the difference. Splarka 06:13, 18 January 2008 (UTC)

A similar example w:Special:ParserDiffTest/User:Ales_Tosovsky. Splarka 11:27, 18 January 2008 (UTC)

Newsome

Interesting bad input on a template (oldid if fixed):

|postcode_district = HD4
|postcode_area= HD   

==Sport|dial_code= 01484
|os_grid_reference=     
}}

Causes odd interpretation of the parameter. This is probably an expected change. Splarka 09:20, 18 January 2008 (UTC)

This is a serious bug. -- Tim Starling 09:25, 22 January 2008 (UTC)

Adding to the known bugs for now. Splarka 10:10, 24 January 2008 (UTC)

Nowiki

What is <nowiki>Text<!-- </nowiki> --></nowiki> supposed to give? The current parser gives "Text<!-- --></nowiki>", though I would have expected just "Test". What does the new parser do? (I'm asking because of the statement "The includeonly/noinclude tags can now be commented out.") Lupo 13:17, 18 January 2008 (UTC)

There appears to be no difference between the parsers for that case. Splarka 23:55, 18 January 2008 (UTC)

{{!}}

I've encountered w:Template:Countries and territories of Oceania, which renders particularly differently in the new parser. See w:Special:ParserDiffTest/Template:Countries and territories of Oceania. The footnotes generated by w:Template:cnote are being spat out into the generated HTML as pure template syntax. The specific problem seems to be related to the use of {{!}}. I tried changing it to | in a sandbox but then it worked in the new parser and not the old. I can't find a syntax which works in both. Here's the syntax at the heart of it:

{{navbox
...
other stuff
...
{{nowrap|{{cnote{{!}}1{{!}}[[New Zealand]] is often included in [[Polynesia]].}}}}
...
}}

Ideas? Anakin101 01:14, 19 January 2008 (UTC)

It broke on the new parser because the old parser abused the {{!}} bug (which only worked in parserfunctions). It broke in the old parser because nowrap generated a <span class=""> with an equal sign in it, making the {{{1}}} parameter undefined. In sort, they were both bugs in the old parser, one that let it work, and one that broke it. Seems to work fine after a dual fix Splarka 05:12, 19 January 2008 (UTC)

Not quite sure I follow why the fix works, but it does! Thanks! • Anakin101 15:57, 19 January 2008 (UTC)

stub

Where does all the stub-classes arrive from? w:Special:ParserDiffTest/Sweden AzaToth 03:11, 19 January 2008 (UTC)

Worksforme, however as disucssed this may be a cache issue. Reopen if it reappears. Splarka 05:57, 19 January 2008 (UTC)

T think difference apears when you set number in Threshold for stub link formatting (bytes): in preferences. --Li-sung 11:54, 23 January 2008 (UTC)

namespaces concated with template argument doesn't work if space

This is probably more in the category of things that you shouldn't do but the old one let you, but it doesn't seem to work when you include the namespace as a template parameter, and then the page name is harcoded if there is a space between the name and the parameter. Issue goes away if you remove the space, see http://en.wikinews.org/wiki/Template:Asia?timtest=newpp and http://en.wikinews.org/w/index.php?title=Template:Dynamic_Asia&action=edit Bawolff 07:34, 19 January 2008 (UTC)

Couldn't repliace what you were saying, but the bug was TITLE= inside the parser function. Fixed that bug anyway. Was there another? Splarka 09:07, 19 January 2008 (UTC)

I'm not sure. I changed n:template:Dynamic Africa in a different way that seemed to suggest what i said above, but I couldn't seem to recreate that elsewhere either, so you're are probably right. Bawolff 22:25, 19 January 2008 (UTC)

Special:ParserDiffTest/Main_Page

The main page here renders an additional <p><br /></p> with the new parser. Superm401 | Talk 20:57, 19 January 2008 (UTC)

Seems okay after [7]. Splarka 01:34, 20 January 2008 (UTC)

msgnw

msgnw gives the expanded wikitext instead of the wikitext, see e.g. Special:ParserDiffTest/Template talk:Ttc.--Patrick (talk) 09:41, 20 January 2008 (UTC)

That looks like a valid problem, adding to 'pending'. Splarka 01:08, 21 January 2008 (UTC)

dir slash bug

WikiPedia:User:Durova WikiPedia:User:Durova/ bug

Now using a redirect hack

WikiPedia:UserIgorberger WikiPedia:User:Igorberger/

slash "/" should redirect to directory! so dir = dir/ server header should be 200 okay.

So request to dir/ should return dir 200 okay! Igorberger 11:17, 20 January 2008 (UTC)

Historically, pages like User:Foo and User:Foo/ have always been two different pages. I agree that this behavior is not necessarily desired, though. It's also not a bug in the processor. Tuvok[^T@lk/_en.wp] 12:40, 20 January 2008 (UTC)

I have regestered it as a bug at bugzilla dir slash bug 12703 Eventhough it is not a processor bug the core is the sum of its parts and we should keep an eye on how it is handeled. Igorberger 13:46, 20 January 2008 (UTC)

Listed as 'checked' since it is not related to processor migration. We are mostly interested in three things: bugs in the new processor that were not in the old processor (fixable bugs), bugs in the old processor that have been fixed by this migration (for listing under expected differences), and in a few cases, bugs that existed in both processors, but that the new processor made more apparent (such as message transformation utilizing template parameters). Splarka 00:11, 21 January 2008 (UTC)

Single quote in #ifeq

On en we have w:en:Wikipedia:Today's featured article/January 2008 which transcludes w:en:Template:Fapages, since the template was used on other pages I need to ensure that it would update correctly however the ' messed up the comparison and I needed to escape the entries. — en:user:dispenser 01:19, 21 January 2008 (UTC)

It does seem broken, but I can't seem to find any differences between the two parsers in this. See: Parser's "broken" + (page) & grill diff and Wikipedia:Today's featured article diff. Can you create an example on test.wikipedia that shows a difference in behavior? Splarka 04:38, 21 January 2008 (UTC)

No, I cannot. I just wanted to bring this issue to attention while we were making significant changes to the parser. — Dispenser 05:05, 21 January 2008 (UTC)

Interesting. It works on older versions of mediawiki/parserfunctions, it is possilby a very newly introduced bug. {{#ifeq:A'd|{{FULLPAGENAME}}|Yay|hiss}} on [[A'd]] for example works on Wikia, but not here [8]. Splarka 06:58, 21 January 2008 (UTC)

[9]. Splarka 06:10, 22 January 2008 (UTC)

Bugs?

• [10] changes T to T-1
• [11] - missing edit sections (on purpose?)
• [12] - renders almost 1/3rd slower on new parser

-75.73.135.171 06:28, 21 January 2008 (UTC)

• en:Wikipedia:Featured_article_candidates expected, those are transcluded editable sections... bugzilla:6563
• Special:ParserDiffTest/Help:ParserFunctions#Caveats also expected xml headers.
• It can't always be faster, I'm gonna think that is to be expected too, for now ^_^.

Splarka 07:06, 21 January 2008 (UTC)

Problem with Special:ParserDiffTest

Special:ParserDiffTest gives sometimes as output of the old parser something that is not the actual current output. Example:

<gallery>
Image:Goldenwiki.png
</gallery>

supposedly yields <table class="gallery" cellspacing="0" cellpadding="0"></table>, which is obviously wrong. Of course, this is not a major problem, but it may hide some differences, like in this case where it seems the new parser removes a <p></p> from the "gallerytext" div. R 18:05, 21 January 2008 (UTC)

Something with en:w:Template:Announcements/Community bulletin board

Not sure what's going on. Can someone check it out? Rholton 21:28, 21 January 2008 (UTC)

Seems a valid bug:

{{#if:1|
=== Uneditable ===
=== Editable ===
}}

first section in a parserfunction doesn't show an edit. Adding. Splarka 05:32, 22 January 2008 (UTC)

This is still broken.

When clicking any of the 4 [edit] links in the CBB, at en:Wikipedia:Community Portal, it says "Since there is no section T-1...".

When clicking the links via the actual page en:Template:Announcements/Community bulletin board, it says "Since there is no section 1...".

I'm not sure what to do. Quiddity 20:34, 31 January 2008 (UTC)

That "checked" image means it has been checked (in this case, verified as a bug), it does not mean it has been closed. It was moved to the article here. Splarka 08:09, 1 February 2008 (UTC)

BrokenArrow

http://it.wikipedia.org/w/index.php?title=Utente:Gvf/Sandbox10&timtest=newpp is using http://it.wikipedia.org/wiki/Template:Bio/Sandbox2 a simplified version of http://it.wikipedia.org/wiki/Template:Bio which is heavily used on it.wiki --MZMcBride 02:29, 22 January 2008 (UTC)

That template reduces down to:

{{#if:{{NAMESPACE}}|{{Bio/categorie_base}}|Categorie={{{Categorie|}}}}}

which means, the last parameter assigning a category is outside the actual template call. This worked in the old parser due to bugzilla:5678. An expected difference. Splarka 04:42, 22 January 2008 (UTC)

Template:Db-reason

produces a difference. The old parser produced an extra <p><br /></p> 64.222.154.50 03:48, 23 January 2008 (UTC)

Edittools broken when using editintro param

When I use the editintro param to edit a page, the edittools seems to be broken, as the UNIQ prefixes aren't unstripped. Example : this (vs. with old_pp) and this (vs. with with old_pp). iAlex 16:47, 23 January 2008 (UTC)

This should be fixed in r30107. -- Tim Starling 04:35, 24 January 2008 (UTC)

Editing sections of transcluded pages

Observed on en:Wikipedia:Reference_desk/Mathematics using ?timtest=newpp:
This page transcludes already archived pages such as (at this moment) en:Wikipedia:Reference desk/Archives/Mathematics/2008 January 16. The edit links for sections of such included pages have the form http://en.wikipedia.org/w/index.php?title=Wikipedia:Reference_desk/Archives/Mathematics/2008_January_16&action=edit&section=T-1 (for section 1; the number folowing "T-" goes up by 1 for each next section). These links do not work as hoped. The edit box shows (independent of the section number) only the <noinclude>d page header. Lambiam 06:42, 24 January 2008 (UTC)

Yuo must run the target throught the new prepropressor as well, i.e. add &timtest=newpp AzaToth 15:20, 24 January 2008 (UTC)

Automotive units conversion template issue

Observed errors on pages that use en:Template:Auto ft.lbf, for example en:Ford Taurus. It only shows up if you use the Show text from page button. The error could be worked around by using en:Template:Convert instead, but there are a lot of uses of the template that would need to be reworked. 71.112.106.107 08:25, 24 January 2008 (UTC)

This is a known difference. The old behavior was buggy. {{#if: {{{2}}}|{{{2}}}|0}} is bad parser syntax. The proper format is {{#if:{{{2|}}}|{{{2}}}|0}} but a parserfunction isn't even needed here, {{{2|0}}} is fine. I've fixed a bunch of these conversion templates already (but not all). Splarka 09:26, 24 January 2008 (UTC)

This template relied on a bug that has been fixed in the new preprocessor. I fixed the template.--Patrick (talk) 09:25, 24 January 2008 (UTC)

Well, I fixed it better! nyah. (Got an edit conflict there but not here). Patrick: can you come to #mediawiki on freenode? Splarka 09:29, 24 January 2008 (UTC)

You are right, that is easier. I am not familiar with IRC, but you can email me.--Patrick (talk) 10:26, 24 January 2008 (UTC)

Ahh, no big deal. We are just discussing the parser in #mediawiki and the pending switch, and you might find it interesting. You can reach it via chat.wikizine (choose #mediawiki from the dropdown list, near the bottom) if you wanna try out a quick and dirty web-based IRC. Splarka 10:31, 24 January 2008 (UTC)

Well, that is, when I say "we are discussing", I mean, a few times a day for the last two weeks the topic has come up, and sometimes it lasts a while and several people get involved, but most of the time it is other people bugging Tim for new pet features that are peripherially related (or sometimes not at all). The topic should be somewhat common though for the next few hours. Splarka 10:33, 24 January 2008 (UTC)

Link in Special:ParserDiffTest does not work

Not about the preprocessor itself, but a related issue:

The link to the page concerned at the top of the result page of Special:ParserDiffTest does not work.--Patrick (talk) 09:02, 24 January 2008 (UTC)

en:Template:Wales-footy-bio-stub

This template on en.wikipedia doesn't seem to parse properly. en:Template:Wales-footy-bio-stub. Woodym555 11:50, 24 January 2008 (UTC)

{{{{{icon}}}}}, where icon has the value "Soccer icon{{!}}Wales{{!}}50" cannot be used to call Soccer icon with parameters Wales and 50. Use separate parameters for Soccer icon, Wales, and 50.--Patrick (talk) 13:19, 24 January 2008 (UTC)

See also w:WP:VPT#Template:Wales-footy-bio-stub.--Patrick (talk) 14:06, 24 January 2008 (UTC)

Another solution, which has been chosen, is using {{{icon}}} with value {{Soccer icon|Wales|50}}.--Patrick (talk) 02:08, 25 January 2008 (UTC)

en:MediaWiki:Ipbreason-dropdown

en:Wikipedia:Village_pump_(technical)#MediaWiki:Ipbreason-dropdown. Splarka 03:47, 25 January 2008 (UTC)

en:Template:Oxford College Infobox

The map functionality of this template is completely broken; see, for example, en:St Anne's College, Oxford. I don't speak template syntax, so can't tell whether this is an existing known bug or a new one. Any help cleaning the mess up, though, would be appreciated! Thanks, 129.67.19.252 12:05, 26 January 2008 (UTC)

I fixed it, "{{!}} no longer works as template delimiter in Parserfunctions."--Patrick (talk) 13:26, 26 January 2008 (UTC)

Thank you! One of these days I'll learn template markup... 129.67.19.252 23:51, 26 January 2008 (UTC)

Error Message

Don't know if this counts, but the current error message for the database lock shows up as:

The Wikipedia database is temporarily in read-only mode for the following reason:

$1

SkierRMH on En wiki

Added to existing bugs (might not be, but I can't test it). Splarka 08:18, 1 February 2008 (UTC)

Unclosed braces closed later can lead to broken section editing links

If double braces are accidentally left open, and accidentally closed on the other side of a section header, the edit link may report "no such section." If the closing braces are removed from the minimal example, the edit link works again. Minimal example Live example — Carl (CBM · talk) 00:39, 1 February 2008 (UTC)

Added to existing bugs, interesting find! Splarka 08:18, 1 February 2008 (UTC)

Stop parsing after some amount of wikitext

see en:List of Russian Americans and [13]. -- Dispenser 04:13, 8 February 2008 (UTC)

Not a parser bug, merely unbalanced ref tags. -- Dispenser 17:34, 24 February 2008 (UTC)

Comments in ref tag

I can't reproduce this for some reason, but take a look at the footnotes in Arabic-speaking Christians: comments are being displayed as plain text. The comments are inside a <ref> tag that's inside a parameter to an infobox template. There must be something else going on, because this sandbox test didn't exhibit the issue. – Minh Nguyễn (talk, contribs) 07:36, 8 February 2008 (UTC)

The comments were written with <-- instead of <!--, fixed that now. -- Dispenser 17:34, 24 February 2008 (UTC)

Creation of paragraphs

See commons:Special:ParserDiffTest/Template:Idw/lang: New paragraphs are created on each line. Not sure what causes this. -- Bryan (talk|commons) 14:50, 22 February 2008 (UTC)

Never mind, found out: caused by empty lines. -- Bryan (talk|commons) 14:52, 22 February 2008 (UTC)

Random choose/option tags in repeated templates

I'm seeing something odd on one page that repeatedly uses a template that invokes the random selection algorithm. The main page of http://psyklopedin.org (a Swedish-language encyclopedia parody) is calling a template {{VissteDuAtt}} ('did you know') which selects one line of text for display from a series of stored options. Effectively, a template that, if you were to call it ten times in succession from the same page at the same time - even without any parameters, normally should return up to ten different results.

Something like:

• {{VissteDuAtt}}
• {{VissteDuAtt}}
• {{VissteDuAtt}}
• {{VissteDuAtt}}

now seems to return not four different random responses but returns the same response text four times. I believe this broke during an upgrade to MW1.12 and is still broken on MW1.13

Placing a dummy parameter, something like:

• {{VissteDuAtt|1}}
• {{VissteDuAtt|1}}
• {{VissteDuAtt|1}}
• {{VissteDuAtt|1}}
• {{VissteDuAtt|1}}

appears to hide the problem - even if the template nominally ignores the parameter.

Special:ParserDiffTest is of no use in examining this issue as it does not invoke extensions in templates, period. It is just returning the raw <choose><option> tags with all the options visible as wikitext - which tells me nothing.

How do I determine whether the parser changes are what has broken this random bit of Psyklopedin's main page. Do you know... ? --Carlb 23:44, 23 February 2008 (UTC)

I am a sysop at Psyklopedin, but i can't deal with any technical problems, but the fake parameter seems to work, thanks. —Kcaa (81.231.157.80) 13:06, 24 February 2008 (UTC)

By the way, here is an old version of the page with the broken templates. —Kcaa (81.231.157.80) 13:09, 24 February 2008 (UTC)

Subst'ing parameters to XML-style extension tags

In the old parser, I had some templates that I used for subst'ing DPL and <math> tags with parameters. For instance, on {{Foo}}, we would have:

<dynamicpagelist>
  category={{{1}}}
</dynamicpagelist>

On a page, i would write:

{{subst:Foo|Bar}}

And this would correctly fill in the parameter inside the DPL tag:

<dynamicpagelist>
  category=Bar
</dynamicpagelist>

On the new parser, however, parameters inside DPL and MATH tags don't fill-in during subst'ing the template. --Whiteknight (meta) (Books) 23:14, 13 March 2008 (UTC)

I think you can use #tag.--Patrick (talk) 00:42, 14 March 2008 (UTC)

Image size 19.px not equal to 19px

The old parser treats [[Image:someimage.jpg|19.px]] as [[Image:someimage.jpg|19px]], while the new preprocessor treats "19.px" as caption, leaving the picture unresized. --84.128.214.131 23:31, 31 October 2008 (UTC)

I am told that this change was not related to the change to a new preprocessor. Splarka 06:07, 9 November 2008 (UTC)

Go to http://guildwars.wikia.com/wiki/Special:ParserDiffTest, enter [[Image:Thoughtful Sig.png|19px]] and observe, then. --84.128.217.126 13:30, 20 November 2008 (UTC)

Unable to conditionally add sections to tables/Unable to conditionally add categories

It is no longer possible to conditionally add cells/rows/columns to tables.

I.e.

{{#if:{{{image|}}}|
{{!-}}
{{!}}colspan="2" background="{{{image}}}" {{!}} {{#ifeq:{{{status}}}|dead|[[Img:Dead.png{{!}}200px]]| }}}}

The above now results in the table becoming malformed.

Using the following conditional categorisation also does not work.

{{#if:{{{faction|}}}|[[Category: {{{faction}}} NPCs{{!}}{{PAGENAME}}]]}}

AerosAtar 19:04, 8 November 2008 (UTC)

This is a known and explained case. You do not (nor did you ever) need to escape "covered" (by brackets or braces) pipes. It was actually a bug in the old parser that it worked. [[Img:Dead.png{{!}}200px]] should be [[Img:Dead.png|200px]]. [[Category: {{{faction}}} NPCs{{!}}{{PAGENAME}}]] should be [[Category: {{{faction}}} NPCs|{{PAGENAME}}]]. There was one case where this actually broke something, where a template parameter was used both for a template call and its parameters. You only need to transclude-escape pipes used in wikitable syntax (other pipes can be html entities). Splarka 06:06, 9 November 2008 (UTC)

I apologise if this sounds stupid, but it may be that I wasn't stating the problem clearly enough - I have a habit of assuming people know what I mean because I do...

Anyway, the problem I am getting is not with the image in the first instance (though that may have become an issue after sorting out the main issue, so thanks for pointing that out). The problem I am having is with the transclude-escaped wikitable syntax. I.e. this bit...

{{!-}}
{{!}}colspan="2" background="{{{image}}}" {{!}} 

If the IF statement returns TRUE (and thus attempts to insert the additional cells), the table becomes malformed. I can post up an image of the malformed table if it helps to explain what I mean. I know it worked when I built the template using V1.11 of Mediawiki (old pp), but it doesn't work with V1.13 (new pp). I am hoping there is a workaround/fix, as I really don't want to have to re-code all of my templates to use HTML tables.

AerosAtar 01:38, 10 November 2008 (UTC)

Interestingly, the "covered pipes" thing you mentioned above as being a bug still works... It's odd, I use the test on the Migration page, and it returns that I am using the new pp, and I have the problem I mentioned with transclude-escaping wikitable syntax which I didn't have before; but I also still have the problems I had on the old pp, where I need to transclude-escape ALL pipes that are not directly part of the conditional funtion (you stated above that you never needed to, but none of my templates worked unless I did, and they still don't work now if I don't now).

AerosAtar 17:35, 19 November 2008 (UTC)

Any takers on the problem/possible solution? Anyone?

AerosAtar 19:52, 1 December 2008 (UTC)

Is it a problem that occurs on Meta too? Can you give a link to the page with the attempt?--Patrick (talk) 22:21, 1 December 2008 (UTC)

Slightly cut down example ((the [[Image:]] as a background used to work fine before I upgraded, and was taken from another wiki where it still works (they have not upgraded)))

Test
background="" |
Non-Conditional

I am afraid that I cannot provide a link to a page with the problem as it is currently only installed on my local test wiki. I also appear to be unable to provide a screenshot at the moment, though I can email one if anyone thinks it will help.

If it would help to test the whole template, here is the code:

{|class="infbox" style="float:right; width:200px; border:1px solid #8B4513;" cellpadding="2"
!{{Hl2}} colspan="2"|{{{name|{{PAGENAME}}}}}
{{#if:{{{image|}}}|
{{!-}}
{{!}}colspan="2" background="{{{image}}}" {{!}} {{#ifeq:{{{status}}}|dead|[[Img:Dead.png{{!}}200px]]| }}}}
|-
|colspan="2" align="center"|{{{gender}}} {{#if:{{{race|}}}|[[{{{race}}}]]}} {{#if:{{{class|}}}|[[{{#explode:{{{class}}}|/|0}}]]{{#if:{{#explode:{{{class}}}|/|1}}|/[[{{#explode:{{{class}}}|/|1}}]]}}{{#if:{{#explode:{{{class}}}|/|2}}|/[[{{#explode:{{{class}}}|/|2}}]]}}{{#if:{{#explode:{{{class}}}|/|3}}|/[[{{#explode:{{{class}}}|/|3}}]]}}{{#if:{{#explode:{{{class}}}|/|4}}| /[[{{#explode:{{{class}}}|/|4}}]]}}}}
|-
|{{Hl2}} width="60px"|'''Status'''
|{{{status|Neutral}}}
|-
|{{Hl2}} width="60px"|'''Faction'''
|{{#if:{{{faction|}}}|[[{{{faction}}}]]|None}}
|-
|{{Hl2}} colspan="2" align="center"|'''Other Allegiances'''
|-
|colspan="2" align="center"|{{{allegiances|Unknown}}}
|-
|{{Hl2}} colspan="2" align="center"|'''Known Assosciates'''
|-
|colspan="2" align="center"|{{{assosciates|None}}}
|-
|{{Hl2}} colspan="2" align="center"|'''Last Known Location'''
|-
|colspan="2" align="center"|{{{location|Unknown}}}
|-
|{{Hl2}} colspan="2" align="center"|'''Notable Game Logs'''
|-
|colspan="2" align="center"|{{{logs|None}}}
|}
{{#if:{{{descript|}}}|{{(!}}border="1" cellspacing="0" cellpadding="5" align="center"{{!}}{{{descript}}}{{!)}}}}

[[Category:NPCs|{{PAGENAME}}]] [[Category:{{{status|Neutral}}} NPCs|{{PAGENAME}}]] {{#if:{{{faction|}}}|[[Category: {{{faction}}} NPCs{{!}}{{PAGENAME}}]]}}

AerosAtar 19:48, 2 December 2008 (UTC)

Has anyone come up with any possible causes and/or solutions yet? I'm still kinda stuck with this... AerosAtar 19:22, 15 December 2008 (UTC)

Anybody? This issue is really causing me problems, so I would greatly appreciate any help I can get at this point... AerosAtar 21:40, 15 January 2009 (UTC)

Nowiki inside comments and tilde parsing

On Memory Alpha, we use a template to initialize forum discussions, and in it we have a comment about signing your posts. The text currently looks like this:

<!-- <nowiki>Please always sign you post with "-- ~~~~".</nowiki> -->

Now, the tildes get expanded to the sig of the person last editing the template. Moving the nowiki tags outside of the comments? The comment is no longer treated as a comment.

What does this mean? We can no longer edit that template to fix the grammatical typo in there. Before the preprocessor upgrade, the nowiki tags were still valid and handled properly, keeping the tildes as ~~~~. The only workaround for this at the moment is to be very illegal with the code and use the following:

<!-- <nowiki>Please always sign you post with "-- ~~~~". -->

Note the lack of "nowiki" tag, which means that you cannot do any other wiki work on there at all. -- 130.15.49.66 15:26, 22 July 2009 (UTC)

I don't comprehend, this works for me without being expanded:

<!-- Please always sign you post with "-- ~~~~". -->

If you edit this page, you can see it here: "" ... Splarka 07:10, 23 July 2009 (UTC)

I tried that, and same behaviour. See here. Check the specific diff. I'm really confused, since it did work on this page properly. -- 130.15.49.66 12:39, 23 July 2009 (UTC)

Ahh k, this is apparently a bug. See bugzilla:93#c17 but it seems to only happen inside <includeonly> (which you didn't mention in the first post). Splarka 10:22, 24 July 2009 (UTC)

Cleanup/Tasks (TO DO)

If you have found a difference that can be fixed via wikicode, but can not or do not want to change it (say, because it would require a bot, sysop, or you just don't want to expose your IP on a project), please list it here

Implementations of w:Template:Self, eg [14] & [15]	This is due to the usage of {{!}} inside parserfunction bug in the old parser, and only allowed sub-parameters in all but the first parameter. Will probably require migrating to a new template with different formatting, such as {{Otherself|{{GFDL-no-disclaimers}} {{cc-by-sa-3.0|[[Genomics Institute of the Novartis Research Foundation]]}} }}
w:Template:Citation	Needs the #switch replaced with #iferror when that function goes live. Due to the bug in #switch allowing an #expr error to fail the default. done.
w:Category:United_States_state_templates	Almost all of these templates need to be fixed, like [16], per having the equals sign outside the parserfunction (which shouldn't be needed here anyway) {{#if: {{{1|}}} | collapse_state = {{{1}}} }} and such can be changed to: collapse_state = {{{1|expanded}}} Ranges Done: Nevada to Nevada (sic)
de:Template:Taxobox	{{!}} issues
[17]	de:Template:Coordinate issues
eo.wiki Main Page	screwed up
nl.wiki Main Page	screwed up
nn.wiki Main Page	screwed up
fi.wiki Main Page	screwed up
w:Special:ParserDiffTest/Satow,_Germany and w:Special:ParserDiffTest/Hatzfeld etc	Coord problems: parserfunctions inside span title="" parameter causing naughty HTML on error. Probably requires #ifexist to return plain text error instead of <strong>.

s:pt:Predefinição:Integra

Anyone knows how to change this code? May splitting up to five or six new templates with only one {{#if}} call in each one? 555 20:33, 23 January 2008 (UTC)

Discussion

Performance

I'm curious, how does the performance of the new parser compare to the old? Will it appreciably ease the load on Wikipedia's servers or anything? • Anakin101 21:13, 18 January 2008 (UTC)

Well, it will make certain pages load much faster. See this link for an example. Appending ?timing=1 allows you to see the difference in time between the two parsers. Cheers. --MZMcBride 22:49, 18 January 2008 (UTC)

Oh now that's impressive! I should have known there would be a clever testing feature like that. It's a good improvement too. Thanks for the info. • Anakin101 23:05, 18 January 2008 (UTC)

problem with comments on the same line as section headings

The change in behaviour about headings followed by comments will break all headings edited by W:User:Anchor Link Bot, which added comments on the same line as a section to note that a section is linked from another article. It will make these sections not have an edit link which will be confusing. For an example of what I'm talking about, see Islamic dietary laws on En.Wikipedia. I request that either comments on the same line as headings have no effect, or a bot goes through and cleans up all the headings (including instances added by other editors), before this parser goes live. Graham87 08:03, 19 January 2008 (UTC)

Hmmm - thinking about it some more, I can imagine it wouldn't be worth it to code an exception. A bot would probably be the best solution. Graham87 08:23, 19 January 2008 (UTC)

I have seen many examples of this on en.wikipedia but most can easily be fixed when they are encountered. Another common occurence is from subst'd welcome templates on user talk pages. Tim really doesn't want to have to make an exception for this type of header. Splarka 08:45, 19 January 2008 (UTC)

Fair enough. Anchor Link Bot made over 9,000 edits so fixing them would be best left to a bot. If there are specific welcome templates that have this issue, Google could be used to find instances of the templates by searching for unique text within them. For example if those templates all contained "these pages might be useful". Graham87 09:31, 19 January 2008 (UTC)

See W:Wikipedia:Bot requests #Fixing comments after sections for the new preprocessor for the bot request on Enwiki. Graham87 02:26, 21 January 2008 (UTC)

Templates with optional headers

On a related note, it seems like templates with optional headers like W:Template:Attack will not have section edit links with the new preprocessor if the header is used. That's probably ok because, as I have demonstrated at W:User:Graham87/sandbox3, those section edit links didn't work anyway with the old preprocessor. I like the way the new preprocessor is much more consistent - test edits like this one will now be visible in the article instead of silently messing up the edit section button. Graham87 10:01, 19 January 2008 (UTC)

w:Template:Attack would leave an editable section if the first line were changed to:

{{<includeonly>subst:<includeonly>#if:{{{header|}}}|=={{{header-text|Attacks in the article [[:{{{1}}}]]}}}==}}

And then the header would be subst'd in cleanly, instead of leaving an #if in the article. Splarka 11:35, 19 January 2008 (UTC)

Done - I've also done this at W:Template:Attack-summary. I haven't been able to find any other templates with this problem. Graham87 12:08, 19 January 2008 (UTC)

Testing enwiki pages

Thanks for the invitation to test the new preprocessor. I know a lot of pages on enwiki which use complicated layers of templates. Is it possible to test enwiki pages for diffs, and if so, how? Geometry guy 14:48, 19 January 2008 (UTC)

It looks like you found it already, but I'll mention it here for other people: Migration_to_the_new_preprocessor/how_to_test Splarka 21:02, 19 January 2008 (UTC)

Since it's not well stated. For EN use a URL like this - replace the name http://en.wikipedia.org/wiki/Special:ParserDiffTest/NAME_OF_PAGE_TO_TEST

-75.73.135.171 06:28, 21 January 2008 (UTC)

What is the url for a page that is not in main space, e.g. a Template? 64.222.154.50 05:03, 23 January 2008 (UTC)

Just take the location you're at on any wikimedia wiki, eg /wiki/Template:Delete and insert Special:ParserDiffTest/ before the title, eg: /wiki/Special:ParserDiffTest/Template:Delete Splarka 05:43, 23 January 2008 (UTC)

Mention the recommended alternatives

The table of expected differences is technically good, but it would be even better with a simple English explanation for each example of how to reproduce the original intended effect, i.e. suggest a recommended alternative in each row. Just an idea to make it more user-friendly for non-developers who might come along. - Neparis 19:40, 19 January 2008 (UTC)

The problem is, the recommended alternative is rarely simple. There are some examples in the form of actual fixes in the 4th column, but they could use improvement... perhaps a separate subpage like Migration_to_the_new_preprocessor/how_to_fix? Splarka 21:02, 19 January 2008 (UTC)

It would be nice to have one table that includes recommended alternatives, perhaps a new table on a subpage as you suggested? Maybe a clearer heading for the 4th column such as "Recommended alternative(s)" might help too? Just a few thoughts. - Neparis 02:38, 20 January 2008 (UTC)

Disagreement about comments in headers

Am I the only one that think comments themselves shouldn't alter the way a page is display. It seem highly unintuitive. I see that it only pertains when they're at the ends, but still. — Dispenser 05:21, 22 January 2008 (UTC)

Although it's listed as "not really" negotiable, I am er, inclined to agree. There are already thousands of these cases on en-wiki. Too many to fix by hand, and even if they are all fixed once, there are editors who still put them like that, thinking it's the proper way to list backlinks to a section. If it wasn't given as an expected change, I would have considered it a bug, like "Headers broken when a comment follows on the same line", etc. I'm guessing Tim Starling must have a good reason for the change though, better performance or something... • Anakin101 15:16, 22 January 2008 (UTC)

Absolutly! There are thousands of these on enwiki. At one point a bot was making things like
== Section == <!-- linked from [[OtherArticle#OtherSection]] -->
when there was a # link into that header. 209.77.205.9 18:59, 22 January 2008 (UTC)

... As in this example given. I would not be surprised if there are tens of thousands, because I specifically remember a bot was adding them. Maybe that bot can be found and its history used to fix them all up? 209.77.205.9 19:02, 22 January 2008 (UTC)

I reckon that with the number of new revisions that would need to be saved, the effort required to fix them all up on the part of the server would far outweigh the performance boost in the parser by having a simpler header interpreter, not to mention the robot would clutter up article histories. 217.114.165.162 21:43, 22 January 2008 (UTC)

I think it may be fixable. I have to prioritise which of the syntax changes I fix, because I only have a limited amount of time to work on this project. I wasn't aware that this construct was so common. So how about I fix it and ignore some of the more unusual ones for now? The Newsome bug is particularly tricky, maybe that one could wait until after switchover? -- Tim Starling 02:37, 23 January 2008 (UTC)

I discussed this above and the bot that caused this problem is named User:Anchor Link Bot. Graham87 05:21, 23 January 2008 (UTC)

Bot has over 9,000 edits. And these are actually very helpful in maintaining link integrity. I would say don't worry about comments on header lines, let them be. 209.77.205.2 07:21, 24 January 2008 (UTC)

"Not worrying about it" would have involved leaving it as the simpler parsing method of not having them editable sections (due to the way sections are pre-processed for editable breaks in the page, not just for <h#> headers). But this support has been added in: rev:30109. —The preceding unsigned comment was added by Splarka (talk • contribs) 09:45, 24 January 2008 (UTC).

meta keywords in HTML head

For reference, see this discussion regarding the Infobox Canada electoral district template, and the example article en:Champlain (Province of Canada).

In the sample article, the HTML head meta keywords for both the old and new parser contains odd information. With the old parser, entries such as "Newfoundland general election, 1841" appear as keywords (they shouldn't), whereas with the new parser, this doesn't occur, but the equally incorrect "Province of Canada general election, 1841" is present (as it was with the old parser).

The HTML generated from processing the template is correct, but there are keywords generated that should not be. For example, the template correctly determines that there is no article "Province of Canada general election, 1841", so it does not create the link [[Province of Canada general election, 1841|1841]] in the "First contested" field; it only lists the year, unlinked. But as mentioned above, the keyword "Province of Canada general election, 1841" is still generated.

The side effect of this is that it creates false entries in the page links database (see the links to the non-existent Province of Canada general election, 1841). It's not an issue in this example, but it is more relevant in the case of "Liberal", since the template needs to link to various political parties in Canada using markup such as [[Ontario Liberal Party|Liberal]]. The parser generates a meta keyword and page link to the article for both Ontario Liberal Party and Liberal, though it should only do so for the former. See en:Brampton West and links to Liberal for an example. These entries are misleading and may cause confusion.

I don't think this is a critical bug, but it merits some attention. In fact, this may not be a bug at all, but simply that the parser assumes all values entered in a template are relevant keywords. If so, I'm not sure the assumption is valid. Mindmatrix 17:00, 22 January 2008 (UTC)

It sounds like you're complaining about an issue unrelated to the present changes. -- Tim Starling 03:42, 24 January 2008 (UTC)

Edit conflicts

I am not sure whether this is strictly a bug. However, if one has an edit conflict, for example on an AFD or CFD discussion, on clicking preview one is offered what will be saved. If you have written a paragraph one finds that disppears completely. This is very annoying, and it wastes time, since one may have to do it all again. Could the preview not be set up so that the excluded text appeared as part of it - "the following text cannot be saved due to an edit conflict". In some cases, all that would be needed (particularly in the case of AFD and CDF) would be to copy that text to another location (manually), edit the page again and paste it in. For AFD and CFD, it might work for the excluded text to be added anyway at the end of the item, with a warning displayed of what was happening, so tha thte user could edit again. 77.100.162.219 22:34, 22 January 2008 (UTC) - WP user Peterkingiron

• Me thinks you aren't looking down the edit page far enough... there are two php edit windows presented one above the other when an edit conflict occurs... the newer submission, including your text will be in the lower, whoever beat you to adding somethings text will be in the upper, and not infrequently, that upper will also be the full page (depending upon the site implementation, iirc).
  
  In the xfD's senario, you were likely editing a single section. Hence, manually capturing that in the cut buffer with [CTRL]-[A], [CTRL]-[C] (or equivalent) pre-save, or just the para/sentences you are adding in a high edit environment makes recovery easy... Just backspace to before you begin editing, then re-edit the section and paste.
  
  Same deal in the Edit conflict windows, capture the text from the lower, and paste into the upper... the problem there is of course you are now likely seeing the whole page, and not just the section of interest... hence the efficiency and superior preparation and practice of making a "Just in case" copy when you know you are on such a busy page.
  
  Now that's what the rest of us do... as for this: "Could the preview not be set up so that the excluded text appeared as part of it - "the following text cannot be saved due to an edit conflict"."...
  
  I think it likely you're asking to violate causality or some other crystal ball sort of functional need... The preprocessor has to process the data stream sent to it by your browser when you initiate the transmission... it has no knowledge that your "edit access" is real and pending until you save or preview... there's likely some process ID that tags your access in preview mode, and the edit conflict is reported when a later tagging is saved before the one you opened somewhat earlier.
  
  OTOH, if the system were to also record that it was a section edit, perhaps it could be altered to save your text within a comment, or perhaps open a third php window with just the source text you are trying to add to facilitate the two recovery methods mentioned previously. This is indeed a PAIN on large pages with lots of action like village pumps, and the xFD's. I can endorse the idea that such human time wasters could use a bit of automational assistance from the developers to ease the pain! Best wishes // FrankB 17:43, 23 January 2008 (UTC)

Please take bug reports and feature requests unrelated to the present changes to some other page. This page is for issues relating to the new preprocessor. -- Tim Starling 03:54, 24 January 2008 (UTC)

Redirects in preview

Since the parser is being replaced, would this be a good time to fix bugzilla:2333? Rendering redirects as numbered lists in preview doesn't seem very sensible, even if it's not a very serious bug. 194.111.49.254 11:34, 23 January 2008 (UTC)

en:Category:Space articles with comments

All articles in en:Category:Space articles with comments have horribly broken action links to the /Comments subpage under the new parser. 88.85.131.104 22:38, 23 January 2008 (UTC)

Hm, I've updated some of the WikiProject boxes to work with the new and old pp (they use "{{!}}" where they should instead use "|"). I'm sure there's a few more out there too. —Zachary ^talk 23:08, 23 January 2008 (UTC)

paragraph

The old parser interprets the following:

<onlyinclude><span>sometext</span>
</onlyinclude>

when used on a page as:

"<span>sometext</span>"

The new parser produces:

"<span>sometext</span>
"

This leads to the following parserdiffs on en.wikipedia: current events and template start date I'm not sure if this is a bug or expected behaviour, but I did not see it mentioned on the list. TheDJ 15:08, 24 January 2008 (UTC)

This is expected. Please put the </onlyinclude> on the same line as the </span>, this has the same effect in both parsers. -- Tim Starling 03:03, 25 January 2008 (UTC)

Rewrite of Help:Template

I think few would dispute that the current version of the Help:Template page is horrifically cluttered, poorly laid out and structured, repetitive, out-of-date and overly technical, among many other faults. I have completed a first draft of a complete rewrite which can be found at User:Happy-melon/Template. I am interested to hear what other editors think of the version and whether it would make a suitable replacement for the existing page, particularly whether this processor change necessitates any change to the documentation. Please feel free to contribute to the discussion on the talk page. Happy‑melon 19:49, 25 January 2008 (UTC)

Broken template

en:Template:Graphical timeline is broken. Not sure if it has been looked into, thats why am listing it here. --61.16.189.218 05:59, 27 January 2008 (UTC)

That is due to w:Template:For loop (I put a note there), it can be adapted like Template:For.--Patrick (talk) 12:22, 27 January 2008 (UTC)

display problem?

If you try this old version of Canadian Aboriginal Syllabics, you'll see there's a table with Devanagari font at the bottom of the page. In en-Wikipedia, that font is not displayed correctly. However, on this test page, both the 'before' and 'after' pages do display correctly. This makes me think not everything that displays correctly on this test page will actually display properly in Wikipedia. 24.30.150.190 08:11, 27 January 2008 (UTC)

Broken navbox template "state = collapsed" behavior

The template Svplaureats includes this string

| {{#if:{{{state}}}|state = {{{state|}}}}}

with the old parser, a page could have the link

{svplaureats | state=collapsed}

and the template would appear collapsed on that page.

With the new parser, the state=collapsed parameter seems to be ignore IF there is only one navbox template on the page. See, for example W. H. Auden

However, if there are two templates on a page -- the svplaureats one and any other -- then the svplaureats template appears collapsed. See, for example, Seamus Heaney.

Can the new parser correctly interpret the state = collapsed parameter? Macspaunday 03:07, 29 January 2008 (UTC)

I changed it, this is one of the expected differences: "The equals sign between parameter and value can no longer be generated (by transclusion, parameter, parserfunction, etc) as a delimiter in the template parameters, it is interpreted literally."--Patrick (talk) 10:08, 29 January 2008 (UTC)

Thank you for fixing this! It makes life a lot easier to have that simple statement rather than the mess of brackets that were there before. Macspaunday 16:09, 29 January 2008 (UTC)

$1 and templates

Its not clear in the table. Can the including $1 in included pages of the mediawiki ns be fixed by adding them as a pramater of the template? aka pretend $1 = foo and {{bar}} was {{#ifexist:$1|[[$1]]}} and some mediawiki page had {{bar}} on it. Could it be fixed by changing {{bar}} to {{#ifexist:{{{1}}}|[[{{{1}}}]]}} and the system message to {{bar|$1}}? Bawolff 20:15, 29 January 2008 (UTC)

Sort of. Currently the transclusion or parserfunction has to be escaped, with something like w:Templae:((. However, this will probably be fixed before the processor is enabled on any more projects. Splarka 07:53, 2 February 2008 (UTC)

Age template not working

The age template seems to have stopped working on 28 January. on en:user:hbdragon88, it says that I've been a user for 3 years, 3 days. I registerd on en on 25 January 2005. It should be 3 years, 7 days by today. The template has not been edited since 3 January, so I think the processor went out or something. Hbdragon88 23:22, 1 February 2008 (UTC)

Looks fine now, was probably a caching issue.--Patrick (talk) 23:51, 1 February 2008 (UTC)

It does? I've refreshed three times and have also tried it in Internet Explorer (I use Opera most of the time) and I still see 3 years, 3 days. Hm. Maybe this is a problem on my end, but I've tried two different browsers. Hbdragon88 00:24, 2 February 2008 (UTC)

w:Special:ParserDiffTest/User:Hbdragon88, shows no differences, and also shows 3 years and 8 days currently. A purge fixed your userpage. Note that Patrick was probably referring to a server-side cache, not a browser cache. Splarka 07:56, 2 February 2008 (UTC)

"Done, but with errors on page" error

Not sure if it's related to the new software or not, but all en Wikipedia pages come up with a "Done, but with errors on page" warning in the bottome left hand side of my browser (IE6, running on Windows XP). If I double click the error message (say from the main page), I get the following detailed report:

Line: 311

Char: 5

Error: 'document.getElementbyld(...)' is null or not an object

Code: 0

URL: http://en.wikipedia.org/wiki/Main_Page

The error seems to be skin specific - I get it in Classic skin (my usual skin) but not in Monobook. I haven't tried the others. I don't get this on Commons or Welsh (cy) Wicipedia, or on here either, even though I have Classic skin on all of these.Tivedshambo 12:28, 2 February 2008 (UTC)

That is most likely a problem in a site-wide or user script on whatever Wikipedia you're getting that error on (and even if not, I can't possibly forsee any way this could have anything to do with the new preprocessor). If it happens when you are logged out, report this to. w:MediaWiki talk:Common.js Splarka 08:27, 3 February 2008 (UTC)

You're right, I've found it thanks. A bit of .js code that I added to my standard.js code a few days ago (and promptly forgot about), which is obviously incompatible with classic skin. I've now reverted it and everything works. Sorry for assuming it was the new preprocessor.Tivedshambo 06:47, 4 February 2008 (UTC)

Possible Bug

I am not a programmer but here's a possible bug. Why am I receiving spam at the top of the regular Wikipedia page telling me that "Bay area Wikipedians may be interested in the wikimedia-sf mailing list." That really creeps me out because it means that even though I am signed in Wikipedia is stalking my current IP address. I thought that if I was signed in my privacy was protected. Besides it is just an advertisement for businesses like party planners and I thought that Wikipedia was about NO advertising! 70.143.75.31 05:03, 3 February 2008 (UTC)

Hi, If you could please give me a link to the page you found this notice on I will be able to investigate further. Thanks, Nakon 05:15, 3 February 2008 (UTC)

Hi Nakon. I don't think I can get you to the page since they are pages for me and have the anonymous address of, for example, "http://en.wikipedia.org/wiki/Special:Watchlist", but here is a screenshot of the thing I am unhappy about:

Image of problem (That's my Wikipedia name, "Saudade7". I have been here since 2002 and this is the first time I've seen something like this that is clearly targeting me based on my IP even when I am signed in. Most of the time I am in France. Since it came with the Migration bug tag I thought maybe they were related.)

Thanks! 70.143.75.31 06:20, 3 February 2008 (UTC)

Entirely unrelated. It's a w:Wikipedia:Geonotice. --MZMcBride 07:44, 3 February 2008 (UTC)

Math tags not working in Firefox

In Firefox formulas using the "math" tag render as their source text instead of the formatted formulas. I see it on all pages I tried, for example Gini coefficient. Note: no problems on IE. −82.171.59.225 10:10, 3 February 2008 (UTC)

Code inside comments will not evaluate any more

With the old preprocessor, if a template that contained

<!-- {{subst:PAGENAME}} -->

was substed into the page Article this would result in

<!-- Article -->

Now, however, it results in

<!-- {{subst:PAGENAME}} -->

i.e., the code inside comments is not evaluated. This has broken a useful feature in en:Template:AfD, where the appropriate en:Template:Oldafdfull template for closing the AfD was pre-generated within the comments left by the AfD template.

Is there a workaround? Thanks, Sandstein 12:41, 3 February 2008 (UTC)

Yes, though it's ugly: see en:Template:Lessthan. --Ilmari Karonen 14:08, 4 February 2008 (UTC)

OK; thanks for fixing en:Template:AfD. 62.167.9.18 14:49, 4 February 2008 (UTC)

Simple English navboxes

Several navbox templates on simple english eg simple:Template:GermanPresidents now have the collapse function working but either do not display or only display the navbar and a series of "---"--Barliner 18:07, 4 February 2008 (UTC)

Not related to the new preprocessor (it isn't the default on simple.wp at this time, that JS is broken in both parsers equally). Splarka 08:18, 5 February 2008 (UTC)

Sitenotice

How long is the site notice going to stay up? -208.71.238.254 22:04, 5 February 2008 (UTC)

Problems at ru:Wictionary

Since last week we have some problems with article creation and editing. Noexactmatch doesn't work as it should and used to, also several of our Wiki markup menu functions don't work (wikifyer and template insrtion - {{}} - among them). Al Silonov 10:21, 27 February 2008 (UTC)

Problem with wikt:ru:MediaWiki:Noexactmatch is covered in the table on Migration to the new preprocessor, last row: "$1 in transclusion to interface message". You cannot longer use a hack when $1 worked in the transcluded template. Try using $1 (or {{urlencode:$1}}) directly. As for quick insertion, fix your Javascript, the best option is to move it from system message wikt:ru:MediaWiki:Summary into MediaWiki:Common.js. -AlexSm 21:11, 27 February 2008 (UTC)

Content in redirect pages

Many redirects have additional content beyond the redirect link itself; for example en:Notoryctidae and en:Azog. This is no longer visible when the redirect is viewed, except that it is visible if you edit and then preview the redirect page. Is this intentional? The ideal behavior would be for the text to be always visible. — Carl (CBM · talk) 21:06, 28 February 2008 (UTC)

Numbered list containing '%'

I haven't managed to extract a reliable test case yet. en:Rubber-tyred metro#Advantages and disadvantages (second numbered lists goes 1.,3.,4. which is caused by the presence of '%' in the first list item. Removing the percent sign fixes the problem. Could do with some more help tracking this down to find out how '%' is overloaded in the parser and elsewhere. Somehow it causing a list-advance. The generated HTML is:

<li>... 100% ...</li>
<li style="list-style: none"></li>
<li>...</li>
<li>...</li>

thus causing the advance. —Sladen; 82.181.165.208 22:06, 1 March 2008 (UTC)

This is not related to the new preprocessor. There are no differences between the parsers. I believe there is a bugzilla bug for that. Splarka 08:22, 2 March 2008 (UTC)

Question for translation

I'm translating this to Japanese, and found a point I can't comprehend.

About "feasible" in "if restoration of the old behaviour may be feasible" in the third sentence of the first paragraph in Migration to the new preprocessor#Expected differences. My English-Japanese dictionary says "feasible" means "possible", "worthy". Which does this sentence mean? --Widehawk 17:54, 2 March 2008 (UTC)

That indicates, if there is enough public request for it, it is possible for it to be done... but unless people really want back the old behavior, it probably not. Splarka 09:13, 3 March 2008 (UTC)

Thank you. I understand. --Widehawk 01:16, 4 March 2008 (UTC)

Category:Pages with too many expensive parser function calls

That is an automatic category, and it recently changed from "Category:Pages with too many ifexist calls" on our Wiki. I can't tell if the change is caused by the 1.12 -> 1.13 update, the migration to the new preprocessor, or something our wikihost (Wikia) did, but if it's a change that comes with the new preprocessor, it should be documented on this page. --84.128.215.96 14:47, 29 October 2008 (UTC)

It was done with the addition of another expensive magic word PAGESINCATEGORY: in rev:32932, and not because of the new pp. You can change it by editing the system message MediaWiki:Expensive-parserfunction-category Splarka 07:49, 30 October 2008 (UTC)

Retrieving the template inclusion call stack from within an extension

Is there a way for an extension (tag based or parser function) to find out from which page the line comes which invokes the extension?

Background of the question is that an extension might want to behave differently if called from a protected template or if called directly from a normal article page (permission concept). To do this the extension must be able to find out if it was invoked by a wiki text line which is part of an included template and it needs to know the name of that template to check whether the template is protected ... --Algorithmix 21:28, 5 July 2009 (UTC)