Difference between revisions of "DPL:Bug Reports"

Revision as of 13:50, 26 August 2007

Please add new bugs concerning DPL at the bottom 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)

Yup... but how do I do it??? Cheers, --87.160.217.187 20:09, 24 August 2007 (CEST)

Quite simple: use the namespace, categories etc. which apply to your raw data articles, set addpagesize=yes and use 'replaceintitle' to make the transformation of the title. Have a careful look into ther manual ;-). If you really can´t figure out how to do it, create demo pages which reflect the principle structure of your current pages here in this wiki and I´ll show you how to do it. ::::

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)

I agree with Eep², the current way of handling it seems to originate from row-oriented thiking and it's fine for that purpose. But you wouldn't want a row-oriented result looking like this, would you:

 1  2  3  4
 5  6  7  8
 9 10 11 12
13 14 15
16 17 18
19 20 21

-Manu3d 11:38, 17 August 2007 (CEST)

Decision

O.k., your arguments convinced me. Will be changed in the next version. Gero 14:38, 17 August 2007 (CEST)

Well, you don't have to choose one way over the other, but if you allow both list directions (as an option), the associated balancing should take effect with it. -Eep² 15:12, 17 August 2007 (CEST)

Question Re: Templates

This isn't really a bug, but I wanted ask about this. If I have a template called 'Awards' and the template took too fields 'Award' and 'Date' where Award is a name of an award from a specific list and date is the date its awarded, can I use DPL to get a list of all pages using the 'Awards' template with 'Five Year Award' in the Award field? -Thanks. 18:21, 18 August 2007 (CEST)

Answer

You should be able to do this with uses=Template:Award, include={Awards}.dpl and includematch=/Five Year Award/ ; see the manual for details. There are examples for similar applications of DPL on this website. Your template Awards.dpl should contain code that produces a table row in your result. Gero 20:41, 18 August 2007 (CEST)

The bug of Template:Catlist?

Could anyone give me a hand? please! —The preceding unsigned comment was added by Roc michael (talk • contribs) 06:36, August 21, 2007. Please sign your posts!

Do you have Simple Forms and Call installed per DPL:Catlist? -Eep² 09:08, 25 August 2007 (CEST)

Thank you, Eep²! Please see The bug(s) is/are nothing about DPL.

environment setting

• MediaWiki: 1.10.0
• PHP: 5.1.6 (apache2handler)
• MySQL: 5.0.24a-community-nt-log
• Parser hooks
  1. CategoryTree
  2. CharInsert
  3. Cite
  4. CreateBox (version 1.5)
  5. CSS (version 1.0.0, 2007-06-15)
  6. CurrentUsers (version 1.0.2, 2007-07-26)
  7. DPLforum (version 3.2)
  8. DynamicPageList2 (version 1.3.1)
  9. Inputbox
  10. LabeledSectionTransclusion
  11. NiceCategoryList
  12. ParserFunctions
  13. RegexParserFunctions (version 0.1)
  14. Semantic Forms (version 0.5)
  15. Semantic MediaWiki (version 0.7)
  16. Simple Forms (version 0.3.4, 2007-08-03)
  17. SimpleTable
  18. StackFunctions (version 0.6)
  19. StringFunctions (version 1.9.3)
  20. SyntaxHighlight
  21. Variables
  22. Winter (Wiki INTERpreter) (version 2.0.2)

Reply

Open the Catlist article and remove one leading '{' from the #dpl statement. Thus you will see the input which is sent to DPL. Then check the argument of the namespace parameter. You seem to have user defined namespaces. Make sure that they start with numbers of 100 and greater (as recommended). Gero 16:24, 21 August 2007 (CEST)

Different results

Thank you, Gero!

After your instructions, I'v found that some different results, but I still don't know what're the reasons. The statements like bellows:

 {{#dpl: namespace=Category | format = ,\n*%TITLE%,, }}

and

 {{#dpl: namespace=Template | format=,\n*%TITLE%,, }}

Could cause the results

%DPL-1.3.1-??: ??? 'namespace' ??: 'Category'! ??: namespace= ???? (?) | Attribute | Attribute_talk | RD | RD_talk | Relation | Relation_talk....?

and

%DPL-1.3.1-??: ??? 'namespace' ??: 'Template'! ??: namespace= ???? (?) | Attribute | Attribute_talk | RD | RD_talk | Relation | Relation_talk....?

But in this site thay don't make this results? I notice that the version of between this site and mime are different. Is it the reason. Please help me! --Roc michael 00:51, 22 August 2007 (CEST)

The bug(s) is/are nothing about DPL

After several my testing I found the bug(s) I met is/are nothing about DPL. The reason of the bug(s) is/are that I've ruined my testwiki by changing charset of Localsetting.php to utf8 and ansi again and again.

Whan I changed the charset of Localsetting.php, my wiki-system will become unstable and some arguments of DPL can't work.

Thank Gero and others. You are very kind.--Roc michael 14:42, 22 August 2007 (CEST)

SQL error with uses= and linksfrom=

1.3.2 had this bugfix:

Bugfix with SQL error

ambiguous 'page_name' in SQL statement fixed (appeared when namespace= and linksfrom= were used together)

I believe there is a similar bug with 'page_id' in the SQL statement which appears when uses= and linksfrom= are used together. I put an example on Test linksfrom, which now errors: MySQL returned error "1052: Column 'page_id' in where clause is ambiguous (localhost)". It appears that uses= adds a reference to page_id which should be something like `page`.page_id instead.

Answer

Thank you for reporting that error. If you find a problem with a DPL statement, please add 'debug=4' as first parameter. This will echo the SQL statement even if it is buggy. Otherwise calling an article with such a DPL statement will reuslt in an empty page so that the user has no idea what went wrong.

Indeed there are some other parameter combinations (only with linksfrom) which cause the same error, for example revision+linksfrom. Will be repaired. Gero 09:06, 24 August 2007 (CEST)

Direct subcategory feature broken by spaces?

I added this example to Test category hierarchy‎. "category=*African Country" appears to not descend any subcategories, but "category=*African_Country" works correctly. —The preceding unsigned comment was added by 64.186.172.226 (talk • contribs) 18:43, August 23, 2007. Please sign your posts!

Yes. The bug will be corrected soon. Gero 14:40, 26 August 2007 (CEST)

Deleted pages show up on Special:Wantedpages

I have a query that pulls back a list of pages in a category called "Spec Work Required". I've had two matching articles that proved to be unnecessary and were deleted. They no longer show on the page with the query, but when I look at the special page, "Wanted Pages", they appear.

I restored one of them, removed the categories, saved the change, and deleted the article again, and it still appears on the Wanted Pages list.

The wiki where this is going on is a private one where my software development team is spec'ing a fairly large software application, so I can't share the pages with anyone at this time. In order to try to demonstrate the problem further, I created The Deleted Republic on this site. I don't seem to have rights to delete that page, though, so I can't complete the bug test.

To complete it, someone with adequate rights would have to delete The Deleted Republic, check to see that it has in fact been removed from the country list, then check Wanted Pages to see if the article appears. If it does, then I'd say the bug is verified.

At this point, this is not a critical bug as my team is pretty careful about checking our Wanted Pages list to make sure we're not referring to lots of specs that don't exist, but I'm thinking about incorporating this extension into another wiki site where it could be much more problematic.

--Aaron Overton 20:26, 25 August 2007 (CEST)

Answer

Hello Aaron, I tried to follow the procedure outlined above. After deleting "The Deleted Republic" it still shows on the WantedPages -- but because this very article refers to it ;-)). I suggest that you try in your wiki the following:

• delete an article which is part of a DPL result
• execute runJobs.php (in the maintenance directory) OR wait for an hour OR open the article containing the query and saving it without changes.
• Each of these steps should have the effect that the reference from the query page becomes deleted from the database. At least the last method works in my local wiki.

You could also add a final DPL statement with reset=all (see the manual for details!) to the article containing your query. Then the database will never contain backward links from the query page to the article page. In that case it should be enough to just delete the article.

Could you please check all of the above and report here briefly if it works as described? It would be nice if you could add an entry to the FAQ article afterwards ... Gero 14:26, 26 August 2007 (CEST)

Creating an annual calendar

When I try to creat an anual calendar with the commands of

{{CalendarSingle|year=2007|month=01|show_year=no|basepage=Events:}}
...
{{CalendarSingle|year=2007|month=12|show_year=no|basepage=Events:}}

I get an error - See DPL:Bug Reports/Annual calendar

Strange, it does work on this wiki. Doesnt work on mine, I can't even post the wikitext. [1]

-- 14:50, 26 August 2007 (CEST)