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...

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

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)