Last modified: 2010-05-15 15:38:29 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 2094 - multiple template use leads to wrong output
multiple template use leads to wrong output
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: 1146 2116 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2005-05-07 05:05 UTC by lɛʁi לערי ריינהארט
Modified: 2010-05-15 15:38 UTC (History)
3 users (show)

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

patch for HEAD (1.00 KB, patch)
2005-05-09 21:10 UTC, Michael Keppler
patch for REL14 (1.02 KB, patch)
2005-05-09 21:20 UTC, Michael Keppler
testcase for parsertests (594 bytes, text/plain)
2005-05-16 08:06 UTC, Michael Keppler

Description lɛʁi לערי ריינהארט 2005-05-07 05:05:46 UTC

the '''same template''' renders differently.

As you can see the first template is rendered "''properly''" both
# at the top of
# at the bottom of
# at the bottom of
(that page is also using another template and renders '''both''' properly)

More complex examples are described at

# The pages in the "'''''(fix)''''' set" are using an additional colomn
# This behaviour is known to me seince begining of version 1.4.
# It seams to me that extra lines are inserted depending on
## repetitiv calls of the same template
## the number of extra lines depends if enumeration lists or tables are usef
## in the later case it seems that some overflow occurs because the number
depends on the content of the last cell

Regards Reinhardt [[user:gangleri
Comment 1 Michael Keppler 2005-05-09 21:10:02 UTC
Created attachment 508 [details]
patch for HEAD

The problem is located in the code for the template cache table. When a
template is used multiple times on the same page, then the following happens,
when the template is first parsed:
a) The output text is set to the article content.
b) The line start (anything before the template pattern) is prepended to the
c) The text is stored in the template cache.
As one can see, the prepending of the line start happens too early as the line
start of the first template occurence will be used as content of the second
template occurence this way (and the linestart variable contains a linebreak in
the example of this bug).

So we need to reorder c) and b). The attached patch does just this. The
linestart of the template is only prepended to the output after the cache has
been stored.
Comment 2 Michael Keppler 2005-05-09 21:13:58 UTC
changed title to better describe the problem
Comment 3 Michael Keppler 2005-05-09 21:15:46 UTC
*** Bug 2116 has been marked as a duplicate of this bug. ***
Comment 4 Michael Keppler 2005-05-09 21:20:49 UTC
Created attachment 509 [details]
patch for REL14

same patch for REL14 as for HEAD
Comment 5 lɛʁi לערי ריינהארט 2005-05-09 23:04:48 UTC

Thanks Michael for your attachment. It is active at

What I experienced with:
With some efforts ALL are FIXED.

There is a problem with Windows XP Mozilla Firefox and Java:

When I hit two times return and (make a preview | click on a Java button in the
Romanian interface to generate special characters) ONLY ONE line ( is inserted |
WILL "SURVIVE" ). Most of the time I avoid this inserting some new lines and
deleting them after just counting the number of new lines I REALY need.

When you look at the HISTORY of the last three mentioned pages you will see that
there are some ODD versions. I noticed that your patch MAY relate to the
mentioned Java bug.

What I did to fix
: I commented the line containing "GangleriBot". Then I made a preview. After
this I hit some new lines and made the Preview a few times again until I was
shure that the "blank characters" where "REAL NEW LINES" (whatever this means).

Maybe you are more skilled to analyse the code of the pages in the history and
find out "WHAT ( IS | WAS ) THERE". Maybe it would be an improuvment to be able
to distinguish between ( spaces | tabs | different new line variants in
Linux|Windows|whatever ). Similar to what you can do in TextPad, Word etc.

There shoud be a bug report about beeing able to see changes in "white space"
(?) in history|diff.

Best regards Reinhardt [[user:gangleri]]
Comment 6 Michael Keppler 2005-05-16 08:06:00 UTC
Created attachment 552 [details]
testcase for parsertests

This test case reproduces the bug. Please paste complete attachment content at
the end of your parsertests.txt file.

Without the patch, the test fails because there is an unwanted "<p></p>" in
line 7 of the parser output.

With the patch applied, this unwanted paragraph (caused by a the newline
wrongly taken from the linestart variable) is removed and the test succeeds.
Comment 7 Anders Wegge Jakobsen 2005-05-29 10:37:58 UTC
Patch comitted to REL1_4 and HEAD.
Comment 8 Brion Vibber 2005-06-02 04:48:54 UTC
*** Bug 1146 has been marked as a duplicate of this bug. ***

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