Issue:Arbitrary adding of empty paragraph
Description: | DPL inserts arbitrary empty paragraphs in some cases. |
Extension / Version: | DPL / 1.8.9 |
Type / Status: | Bug / open |
Problem
I noticed a very strange behavior of DPL (1.8.9) on one of my wikis. The following tag version always produces an extra empty paragraph between the heading and the list, whereas the parser function does work alright, even with all those whitespace added to it. On my test installation (same provider, version - 1.15.3) both versions fail!
== DPL Test - Tags == <dpl>category=Dateiformate</dpl>
== DPL Test - Parser Function == {{#dpl: | category = Dateiformate }}
I wonder if anyone else has noticed a similar behavior and has an idea what might be the cause.
I have already had a look at Issue:DPL extension inserts a blank line headline but think this problem is unrelated.
tia Frank
- I have the same issue (I think). The dpl works fine, but a blank line is added at the beginning of the list. I noticed this when I tested some functions with StringFunctions to replace some characters from the list produced by my DPL query. It works OK on my MW1.15.1 installation which used DPL version 1.7.6. However, the same statements failed on MW1.16 with DPL 1.8.9.
- The only difference is that DPL 1.8.9 produces the extra blank line. I have not yet tried the BOM removal procedure described elsewhere, but will do so and report back.
Update (trunk version, release 82094)
I did some further testing and found that the strange behavior even exists when using the parser function.
The following works ok:
==== Heading ==== {{#dpl: | debug = 1 | category = African Country }}
produces the following output:
Heading
- DPL Example 015
- Issue:Includematch does not filter results
- Republic of Burundi
- Republic of Cameroon
- Republic of Cape Verde
- United Republic of Tanzania
- Category:North Africa
Any other text produces an additional empty P tag before the DPL output:
Any other text before the DPL parser tag {{#dpl: | debug = 1 | category = African Country }}
Any other text before the DPL parser tag
- DPL Example 015
- Issue:Includematch does not filter results
- Republic of Burundi
- Republic of Cameroon
- Republic of Cape Verde
- United Republic of Tanzania
- Category:North Africa
That's what it looks like on my wiki:
Seems to work here with DPL 2.0, though ... --nakohdo 17:55, 15 February 2011 (CET)
Reply
Tried the Byte Order Mark fix but it made no difference. Basically, if I run the following
a b c{{#dpl:xxxx}} where {{#dpl:xxxx}} produces the string "(stuff)"
on 1.7.9 I get:
a b c (stuff)
on 1.8.9 I get
a b c
(stuff)
- Upgraded to the latest Trunk and it fixed my problem
- phew
- Satisfying to solve it, and thanks for the great extension
- It may have something to do with the number of result lines or with the debug level. Does the same effect happen when you set "debug=1" ? Gero 15:02, 27 January 2011 (UTC)
- Yes, problem persists with each debug level I tried (tested on two separate installations). I'm using MediaWiki 1.16.2, PHP 5.2.17 and DynamicPageList (Version 1.8.9)(release 81764). There's always an empty P tag with an empty BR tag inside. The parser version works ok. --nakohdo 12:57, 15 February 2011 (CET)
- Could you please create a test page here (parser version and tag version) in this wiki? I will try to fix the problem in DPL 2.0. Gero 19:53, 16 February 2011 (CET)