DPL:Bug Reports

Please add new bugs concerning DPL at the top of this document.

If possible create a page in this wiki which demonstrates the bug and refer to that page!

Old bug reports have been moved to the DPL:Bug Reports Archive...

ordermethod ignored form2 demo (repost)

{{# dpl:
|category=Untranslated
|namespace=FollowTheScore
|shownamespace=false
|ordermethod=titlewithoutnamespace,firstedit
|addeditdate=true
|adduser=true
|addpagesize=true
|mode=userformat
|listseparators=¶{¦class="sortable" ¶!Script ¶!Last ¶!By ¶!Size,¶¦-¶¦style="background:#ccffcc;"¦%TITLE%¶¦%DATE%¶¦%USER%¶¦%SIZE%,¶,¶¦}
|secseparators=\n¦
}}

ordermethod is not processed. Bug to be reported in bugtracker. 82.255.229.238 14:30, 9 August 2007 (CEST)

The bug fix was included into the latest revision (1.3.3) Gero 11:13, 17 August 2007 (CEST)

Resultsheader with columns

The %PAGES% gives back <number of pages>/columns instead of <number of pages>. Is this intentional or a bug?

Page:Resultsheaderwithcolumns

It is a bug and will be resolved. Gero 21:08, 24 July 2007 (CEST)

DPL and Glossary clashing

Question

Using DPL with Glossary seems to result in difficulties in combining categories. Thus previously working combinations of categories result in filtering of output only by the first category, and much larger outputs than intended.

Curious! Any ideas on a work-around?

Reply

What is 'glossary'? Another mediawiki extension? If you want help you need to be more specific. You could upload a well-prepared example. If the glossary extension is needed for that I may be able to install it on this wiki. Gero 18:05, 22 July 2007 (CEST)

Reply

Glossary is a Mediawiki extension http://www.mediawiki.org/wiki/Extension:Glossary The following is part of the example Glossary I was using.

AAP//American Academy of Pediatrics
ABR//auditory brainstem responses
ACE//angiotensin-converting enzyme
ACPC//Area Child Protection Committee now Local Safeguarding Children's Board
ADH//antidiuretic hormone
ADHD//attention deficit hyperactivity disorder

The purpose of Glossary is to show the detailed text (after the //) when the mouse is over the abbreviated text.

I previously had functional queries in DPL. Subsequently, I added Glossary and could get this working. However, when I went back to my pages that used DPL, I found that they had been corrupted producing far more results than usual. This suggested that Glossary was somehow interfering with the DPL logic. I switched Glossary off, as DPL is more useful to me, and found that DPL worked as before.

All Chinese messages are wrong in DynamicPageList2.i18n.php

Every Chinese character has become "??", not normal Chinese character.The DynamicPageList2.i18n.php in the Zip file here also has wrong Chinese characters. See this page if you want to get the DynamicPageList2.i18n.php with right Chinese character.--Roc michael 11:42, 4 July 2007 (CEST)

DPL and RSSfeeds clashing

Hi, our wiki uses Xfeeds and DynamicPageList extensions. There seems to be a problem when they are used on the same page though. An error occurs in the magpierss file that causes the formatting of the page to display the error at the top of the page, and then display the rest of the page. The error occurs on line 404 of the magpie file that Xfeeds uses. Is there a way to fix this?

Columns Bug

When I use the columns setting, it breaks the background-colour I have set. If I remove it, the background-colour comes back.
Contact me here, if you have any further questions.
--Jamie

Can you demonstrate the effect here or in your wiki? Gero 05:18, 25 July 2007 (CEST)

Sorry about that.

Here ya go. :)

--Jamie

Have you seen DPL:Requests_for_new_features_Archive#Global background-color? Maybe you have the same problem?

Gero 15:30, 27 July 2007 (CEST)

When using simple tables in the included page

When using simple tables in the included page, the first to be included looks strange Table bug and not as the original Table Bug 2. All the others Table Bug 3 and Table Bug 4 look different but still not right in the DPLed list.

Is this a bug? And if so is there a workaround or anything I can do to avoid that (except of not using simple tables...)? Please inform me about your reply: NaSe1977 13:11, 25 July 2007 (CEST)

You may consider it a bug or a feature: DPL does not automatically insert newlines between the articles. That´s the reason why the output looks so strange. I modified your Table bug article to show how two additional lines solve the problem.

Gero 16:52, 26 July 2007 (CEST)

Thanks a lot, this helped. Strange enough my DPL2 1.2.9 does not seem to know format, do I have to enable it anyhow? (I used mode=userformat' and 'listseparators=...' instead)

NaSe1977 09:15, 27 July 2007 (CEST)

You may have downloaded the ZIP file just before I had updated it. Please try again and look for the String "'format'" in the source. Gero 09:51, 27 July 2007 (CEST)

Parser functions and templates in <dlp> versus #dpl

I try to call a parser function from within <dpl> and #dpl and find that the latter does not work. For example, I have the following

listseparators=,\n* [[%PAGE%|%TITLE%]]   (%CATLIST%)({{HEKtest3|%PAGE%}}) {{#sub:%TITLE%|0|7}},   

using <dpl> both the #sub function and the HEKtest3 template works as they shall. For #dpl, the result of the #sub is just the text TITLE. For the macro HEKtest3 it's even more strange, because if I output the parameter like {{{1}}}} it works fine, but if I use #sub on the parameter within the same template it does not output anything. So it seems the template has the correct value, but can not use it for anything other than simple output.

Again - this works fine with <dpl>.

Could it be the pipe-character that is the problem?

Thanks H

Possibly; try using template:! or ¦ per DPL:Manual - General Usage and Invocation Syntax#Using DPL2 as a parser function. -Eep² 12:34, 9 August 2007 (CEST)

Thanks - it helped a little. But:

• {{HEKtest3¦%CATNAMES%}} now works fine. The template is able to use the content of %CATNAMES%
• {{HEKtest3¦%PAGE%}} does not work! It creates an output that contains a link to the HEKtest3 template with the content of %PAGE% as the dislpay text. Weird!
• {{HEKtest3¦%TITLE%}} caused the same problem as above
• The #sub function does not work with ¦ either (see description of problem above)

Well, if all you want are the page name and title, try using the MediaWiki magic words {{FULLPAGENAME}} (includes namespace) and {{PAGENAME}} (page title only). -Eep² 17:50, 10 August 2007 (CEST)

Thanks, but that only gives me the name of the page I'm on, and not the name of the page retrieved by the #dpl function

This problem can be easily solved in the latest revision with ²{...}², see the manual. The idea is that this special markup will be translated to twin curly braces during the iteration over the DPL result set. Gero 20:49, 15 August 2007 (CEST)

addpagesize does not correctly report the size of the page

This is a bit pedantic, but its an important 'bug' in my wiki; See the following;

<dpl>
category = page size test
mode = ordered
ordermethod = size
order = ascending
addpagesize = true
</dpl>

1. Page size test page 1 [89 B]
2. Page size test page 2 [771 B]

As you can see by clicking above both pages are apparently about the same size, and page 1 is aparently a bit bigger. By looking at the source of the two pages we can see that this is only the case once the included template text has been taken into account. That is why I call "ordermethod = size" and "addpagesize = true" buggy... They should use the apparent size of the 'rendered page', not the size of the source code for that page.

I think this could be fixed... It would be a big help for me if it was... http://biodatabase.org/index.php/Sandbox

Thanks for the great extension! --Dmb 09:32, 10 August 2007 (CEST)

---

--Dmb 09:32, 10 August 2007 (CEST)

Reply

Summing up the size of included templates would be quite time consuming. I suggest that you create a DPL query which goes over the "original master date" (The copyrighted articles, I assume) and that you convert the link which DPL presents to the user into a link which points to your own article. Of course this is only possible if your article has a 1:1 correspondence with the master articles and if there is a consistent naming convention so that the name of your article can be algorithmically deduced from the master article´s name. O.k.??
Gero 20:54, 15 August 2007 (CEST)

Wrong number of items per column

Hi, I'm dealing with a DPL report that finds 116 articles and place them in 8 columns as specified by the following DPL parser function:

{{#dpl:
   |titleregexp=^TRB....$
   |mode=userformat
   |listseparators={{!}} valign="top" style="padding-right:20px;" {{!}},\n* [[%TITLE%]],,
   |columns=8
   |rowcolformat=style="color:black; background-color:white; text-align:left; vertical-align:top;"
   |replaceintitle=/ /,_
}}

The problem is: I get four columns with 15 items and four columns with 14 items, when the ideal would be 7 columns with 15 items and the last column with whatever is left (11 in this specific case). Is this some kind of off-by-one error in the code? I will try to reproduce it here, with a smaller number of articles: stay tuned!- Manu3d 13:29, 16 August 2007 (CEST)

By the way, this is a screenshot of what I see:

(A few minutes later) I managed to reproduce the problem but it seems to point to a conceptual issue. Check out my user page. The problem is that the code tries to spread evenly the results over the maximum number of columns, adapting the number of items per column to put something into each column. Ideally, using "rows=" together with "columns=" estabilishes the number of items each column contains, potentially reducing the number of visible columns from the number estabilished by the user.

Is there a way around this?

Thanks for your help. - Manu3d 13:52, 16 August 2007 (CEST)

Reply

Indeed DPL tries to spread the results evenly over the columns. So far nobody complained about that... Why is it important to have a less well balanced output scheme? Gero 23:00, 16 August 2007 (CEST)

That isn't balanced, Gero. It should be equal column lengths until the very last column. At least make your idea of "balanced" columns optional... Your way seems balanced for horizontal/row lists (as in Special:Allpages):

 1  2  3  4
 5  6  7  8
 9 10 11 12
13 14 15 16

and not vertical/column lists:

1 5  9 13
2 6 10 14
3 7 11 15
4 8 12 16

-Eep² 11:10, 17 August 2007 (CEST)