Last modified: 2010-05-15 15:38:29 UTC
the '''same template''' renders differently.
As you can see the first template is rendered "''properly''" both
# at the top of http://jadesukka.homelinux.org:8180/betawiki/%E7%84%A1
# 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
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
changed title to better describe the problem
*** Bug 2116 has been marked as a duplicate of this bug. ***
Created attachment 509 [details]
patch for REL14
same patch for REL14 as for HEAD
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]]
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.
Patch comitted to REL1_4 and HEAD.
*** Bug 1146 has been marked as a duplicate of this bug. ***