View source for DPL:Bug Reports

Please add new bugs concerning DPL <big> '''at the bottom of this document'''</big>.
 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]]...'''

__TOC__
__NEWSECTIONLINK__ <!-- Makes it look like a talk page with + next to 'edit' -->

==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. [[User:Gero|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.

<pre><nowiki>
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
</nowiki></pre>

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.[[DPL source as a ZIP archive|The DynamicPageList2.i18n.php in the Zip file here]] also has wrong Chinese characters. See this [http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/DynamicPageList2/DynamicPageList2.i18n.php?view=log page] if you want to get the DynamicPageList2.i18n.php with right Chinese character.--[[User:Roc michael|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?

== reset=categories doesn't always work with parser function usage ==

Example: See [[Test reset categories]], which includes part of [[Sudan]] (through a parser extension DPL call) and [[Test matches]] (through a parser function DPL call). Without the reset=categories call, it would inherit all the categories from both articles. With reset=categories, the categories from Sudan are suppressed, but [[:Category:Test]] (which comes from Test matches) is not suppressed. --[[User:Rezyk|Rezyk]] 12:33, 31 August 2007 (CEST)

=== Answer ===
I had to do a lot of investigations regarding the "reset" parameter. And unfortunately it still doesn´t work always as expected. Are you a programmer? I could well need some help at that matter ... [[User:Gero|Gero]] 13:41, 31 August 2007 (CEST)

:Well, I am no expert, but here are my thoughts after looking around in DPL 1.3.8 and MediaWiki 1.9.3:
:Starting from the top level page parsing... <small>(function stack at Parser::parse)</small>
:#First all <nowiki><dpl></nowiki> calls are each processed.
:#:<small>(Parser::parse => Parser::strip => DynamicPageList2)</small>
:##Each call also processes its category tags into mCategories before returning.
:##:<small>(DynamicPageList2 => Parser::recursiveTagParse => Parser::internalParse => Parser::replaceInternalLinks)</small>
:##Each <nowiki>"<dpl>reset=categories</dpl>"</nowiki> empties any mCategories categorization done.
:#Then all <nowiki>{{#dpl:}}</nowiki> calls are each processed.
:#:<small>(Parser::parse => Parser::internalParse => Parser::replaceVariables => Parser::braceSubstitution => wfDynamicPageList4)</small>
:##Each call does ''not'' categorize into mCategories before returning. Any category tags are returned as part of unprocessed text.
:##Each <nowiki>"{{#dpl:reset=categories}}"</nowiki> empties any mCategories categorization done.
:#Then the top level result text as a whole processes its category tags into mCategories.
:#:<small>(Parser::parse => Parser::internalParse => Parser::replaceInternalLinks)</small>
:The error case is step 2.1 spitting out a category tag that dodges 2.2's mechanism (because it is unprocessed text, not in mCategories) and is processed into mCategories in step 3. One way to address this might be to have 2.1 do categorization processing like 1.1 does (have wfDynamicPageList4 apply recursiveTagParse to its result like DynamicPageList2 does). Any <nowiki>"<dpl>reset=categories</dpl>"</nowiki> would still not work against <nowiki>{{#dpl:}}</nowiki> effects, but subsequent <nowiki>"{{#dpl:reset=categories}}"</nowiki> would. Note: if that does work, I wonder if wfDynamicPageList4 should also return with noparse=true (see description of Parser::setFunctionHook).
:A "more clean and thorough" design might be to apply that fix, and also have DynamicPageList2 and wfDynamicPageList4 each record/copy the state of mCategories before calling DynamicPageList and restoring that state (if say, categorize=false) after calling recursiveTagParse. --[[User:Rezyk|Rezyk]] 07:58, 1 September 2007 (CEST)

=== Reply 2 ===
Thank you for clarifying this. It was a conscious design decision NOT TO call recursiveTagParse at the end of a DPL parser function call as this gives much more freedom to the user. For example today you can define a table outside a DPL call and then invoke DPL just to produce some rows for that table (the table may contain other rows coming from other DPL statements or rows which you wrote manually). If I called ''recursiveTagParse'' this would no longer be possible because the parser would not understand a pipe charater at the beginning of a line as a markup for a table row (because it wouldn´t know that it is inside a table when expanding DPL output).

Do you see a chance to get rid of unwanted category assignments without calling the parser?

[[User:Gero|Gero]] 11:21, 2 September 2007 (CEST)

:Hmm..although your explanation made sense and appeared to match observed behavior (parser extension calls recursiveTagParse and does not smoothly embed rows), I could not see why it should be true from the parser code. So I made a test installation of MediaWiki+DPL, and found:
:* Calling recursiveTagParse at the end of DPL parser function processing does ''not'' break table-row-embedding. The recursiveTagParse will not understand the '''"\n|"'''s as wikitable syntax, but will pass them through unaltered in the replacement text for the substitution, and they will be picked up as wikitable syntax during the parsing of the higher level result text (step 3 above).
:* The reason why DPL parser extension calls cannot manage table-row-embedding (with higher level results) is unrelated to its recursiveTagParse call. It is because parser extension results do not get substituted back in until after the higher level wikitable processing.

:I don't see any way to do it without some intermediate parsing/processing at this level (and honestly, I expect that any other way found would have to be a hack that breaks some other design abstraction). Adding a recursiveTagParse call does seem to work well as far I have seen, though.
:--[[User:Rezyk|Rezyk]] 07:47, 3 September 2007 (CEST)

::I've had a fair bit of trouble with wiki-table syntax within templates and parser-functions before and found that sometimes it's best to resort to using html syntax for the tables which doesn't confuse the parser so much. --[[User:Nad|Nad]] 08:03, 3 September 2007 (CEST)

:::Which requires yet more syntax/markup conversion between HTML and MediaWiki, making extensions (like [[mw:Semantic Forms|Semantic Forms]]) even more annoying to use, especially with tables and creating links to pages on the current wiki). Bah... -[[User:Eep²|Eep²]] 12:54, 3 September 2007 (CEST)

::::This is a problem which applies to wikitext tables when used with parser-functions in general and concerns the wiki-parser code not the code of any particular extension implementing them. --[[User:Nad|Nad]] 05:43, 4 September 2007 (CEST)

:::::However, an extension which mindlessly disables wiki markup also has other effects, as I previously mentioned. Duh. -[[User:Eep²|Eep²]] 06:53, 4 September 2007 (CEST)

::::::I would like every-one in this Wiki to treat all others with respect. Building good software requires a lot of energy. We shouldn´t waste energy on an emotional level. Personally, I respect the efforts of Semantic Net Approaches very much. I have been working with databases that represented 'semantic triples' like RDF when even abbreviations like OWL and RDF had not been born. I see a lot of potential in DPL but I also see its limitations. I inherited the code about 10 months ago and did not have the courage to change it fundamentally (although I should have done so). Anyway, if somebody has the courage, here is my challenge and my vision for a ''DPL3'':
::::::* DPL3 should use a well designed language for expressing which kind of information you want. The Semantic World has a lot to offer here.
::::::* DPL3 should have a ''Mapping Layer'' in which the author of a wiki defines how the constructs of that abstract language can be mapped to the pecularities of a special wiki.
::::::* I am not sure if the mapping layer would state rules which are interpreted dynamically whenever a query is executed or whether it would define a set of rules which is used to fill auxiliary tables whenever a document gets updated. All systems I have built in former times (except DPL) have been using such tables.
::::::* output formatting should be completely separate from the query engine (i.e. the query might produce an intermediate XML text)
::::::Let me finally add that my time does definitely not allow to attack a task like ''DPL3''. But I will try to keep up DPL until I see something better coming up.
::::::--[[User:Gero|Gero]] 13:09, 4 September 2007 (CEST)

::Would it be helpful if I submitted a modification that used recursiveTagParse to handle something like "categorize=false", and was still able to handle wikitable row embedding? --[[User:Rezyk|Rezyk]] 00:55, 6 September 2007 (CEST)

== <tt>distinct</tt> ==

<tt>[[distinct]]</tt> (defaults to true) seems to have problems with this query in a template:

<pre><nowiki>
{{#dpl:
category=Games
|linksto={{PAGENAME}}{{!}}{{PAGENAME}}s{{!}}{{PAGENAME}}es{{!}}{{PAGENAME}}ies{{!}}{{PAGENAME}}ing{{!}}{{PAGENAME}}ed{{#if:{{{2}}}|{{!}}{{{2}}}{{!}}{{{2}}}s|}}{{#if:{{{3|}}}|{{!}}{{{3}}}{{!}}{{{3}}}s|}}
|redirects=include
|resultsheader=<h2>Games (%PAGES%)</h2>
|noresultsheader=<h2>Games (0)</h2>''No games have this effect.''
}}
</nowiki></pre>

...showing duplicate entries for a [http://www.tnlc.com/wiki/index.php?title=Carnivores_2 game] (that has links to "bubbles" ''and'' "water bubbles" on it) on http://www.tnlc.com/wiki/index.php?title=bubble which has this on it:

<pre><nowiki>{{effect|liquid bubble|water bubble}}</nowiki></pre>

...which should just show the game once (the first parameter is for a Wikipedia link). -[[User:Eep²|Eep²]] 12:11, 5 September 2007 (CEST)

:Seems to be a bug, but I am not sure. Can you create a tiny example here in this wiki to show the effect?
:--[[User:Gero|Gero]] 20:45, 5 September 2007 (CEST)

::Would you rather just be able to view the source of the aformentioned pages? Although I've already given you the relevant code... -[[User:Eep²|Eep²]] 05:44, 6 September 2007 (CEST)

:::No. I need to change the code, activate debugging etc. Give an example here and I will look for it. [[User:Gero|Gero]] 19:46, 6 September 2007 (CEST)

::::OK, see [[test distinct]] for a templateless version that still exhibits the bug (and see [[DPL:Discussion#Exclusion_of_Duplicate_Pages]] for an earlier misplaced bug report by an anonymous user from over a month ago, too). -[[User:Eep²|Eep²]] 10:24, 7 September 2007 (CEST)

== <tt>debug</tt> doesn't work ==

In trying to diagnose why the following query shows the "See also" header even when no results are found, I tried adding <tt>[[debug]]</tt> to it but then all text is removed from a page (and if <tt>debug=3</tt> is at the end, no warning is given about it should be in the beginning either):

<pre><nowiki>{{#dpl:debug=3|namespace=|titlematch={{PAGENAME}}%|resultsheader=\n<h2>See also</h2>|noresultsheader=<div style=display:none></div>}}</nowiki></pre>

<!--
{{#dpl:debug=3|namespace=|titlematch={{PAGENAME}}%|resultsheader=\n<h2>See also</h2>|noresultsheader=<div style=display:none></div>}}

{{#dpl:debug=3|namespace=|titlematch={{PAGENAME}}%|resultsheader=\n«h2»See also«/h2»|noresultsheader=«div style=display:none»</div»}}
-->
'''Uncomment the hidden queries (with and without "double angle brackets") above in edit mode to see for yourself.'''

Oddly, as a tag, the query doesn't hide the page but doesn't output any debug (or ''any'') info either (should at least complain about <tt><nowiki>{{PAGENAME}}</nowiki></tt> not working inside a tag...:

<pre><nowiki>
<dpl>
debug=3
namespace=
titlematch={{PAGENAME}}%
resultsheader=\n<h2>See also</h2>
noresultsheader=<div style=display:none></div>
</dpl>
</nowiki></pre>

In trying to get a query that works here, I don't know why this isn't outputting anything either:
<pre><nowiki>
<dpl>
debug=3
namespace=
titlematch=Test%
resultsheader=\n<h2>See also</h2>
noresultsheader=<div style=display:none></div>
</dpl>
</nowiki></pre>
It should show the [http://semeb.com/dpldemo/index.php?search=test&fulltext=Search many articles that start with "Test"]. -[[User:Eep²|Eep²]] 06:22, 8 September 2007 (CEST)

:#Try using '''double angle brackets''' like this  «tt»...«/tt». also around the '''div''' tags. This will postpone tag expansion to the execution time of DPL. This may help.
:#Variables like PAGENAME are not expanded if you use parser tag syntax like &lt;dpl&gt; change the DPL call to curly braces (i.e. parser function syntax)

::I know about "magic words" not being usable inside parser tags but the main issue is <tt>debug</tt> not working at all (which has nothing to do with double angle brackets--which also have no effect on the query--see above and uncomment the hidden parser ''function'' queries in edit page mode to test for yourself in preview mode)...  -Eep

:3. The last query you wrote produces correct debug output on my test wiki but does not do so here. I will have to find out why; if you leave away the debug statement you get the expected output, right?

::No; hence why I'm even bothering to use <tt>debug</tt> in the first place to find out ''why'' the query isn't giving the expected results as I explained in the first sentence in this section above... -Eep

:4. Read the [[DPL:Manual_-_General_Usage_and_Invocation_Syntax|manual chapter]] on syntax. It is extremely important. Maybe you can improve the text in the manual to help others in avoiding mistakes. I did my best to explain. [[User:Gero|Gero]] 12:04, 8 September 2007 (CEST)

::Please re-read my initial bug report... -[[User:Eep²|Eep²]] 12:19, 8 September 2007 (CEST)

:::O.K. I did not read carefully enough.
:::* To me it looks as if the only problem ist that ''debug=3'' always leads to an empty page (which is bad enough ..). ''Debug=3'' works in my private wiki and hopefully does so on yours. At the moment I have no idea why it has that effect here on dpldemo ...
:::Apart from that your first query is o.k. (I replaced PAGENAME by a fixed value) If you use PAGENAME (which is o.k. of course) then you must use the statement ''within a template'' as the very page where the DPL statement itself is located never will be wshown as part of the outpout. This is due to very complicated recursion loop problems and is not likely to change.

{{#dpl:namespace=|titlematch=A%%|resultsheader=\n

:<tt>debug=3</tt> does not work on my wiki; it results in a blank page as this section's bug report is all about... And, oddly, if I use <tt>debug=4</tt> (see [[test debug]]) I get the SQL query at the page's top (over the logo but under the actions/personal portlets) but the page is otherwise blank (at least in terms of the DPL query and how it should be formatted). -[[User:Eep²|Eep²]] 14:33, 9 September 2007 (CEST)

<h2>See also</h2>|noresultsheader=<div style=display:none></div>}}

----
::: If we replace the titlematch by something which does not exist the output is empty as we would expect (there is no difference in the kind of angle brackets we use):
{{#dpl:namespace=|titlematch=NONEXISTING%|resultsheader=\n<h2>See also</h2>|noresultsheader=<div style=display:none></div>}}
---
So my conclusion is that the debug=3 is the only remaining problem. Could you check on your wiki if 'debug=3' works there? [[User:Gero|Gero]] 10:25, 9 September 2007 (CEST)

== ordermethod=category,sort produces duplicates ==

There are four entries in [[:Category:African Union member states]], but each is repeated up to six times in this DPL call.  distinct=true does not affect the results:

<nowiki>
{{#dpl:category=African Union member states
|columns=6
|ordermethod=category,sortkey
|distinct=true
}}
</nowiki>
{{#dpl:category=African Union member states
|columns=6
|ordermethod=category,sortkey
|distinct=true
}}

If the ordermethod is removed, it works fine:

{{#dpl:category=African Union member states
|columns=6
}}

[[User:66.83.143.246|66.83.143.246]] 23:49, 11 September 2007 (CEST)

=== Reply ===
I don´t think this is a bug. Each of the countries belongs to several categories and you told DPL to order the articles by category. What should poor DPL do? It tries its best in creating a list for each category and ordering each of that lists by articlename (sortkey). If you use ''headingmode'' you can see that:

<nowiki>
{{#dpl:
 |category=African Union member states
 |ordermethod=category,sortkey
 |headingmode=H4
 |columns=3
}}
</nowiki>
What do you really want to achieve with your query?
:--[[User:Gero|Gero]] 08:55, 12 September 2007 (CEST)

::I would expect it to have the same four entry output as the query without ''ordermethod=category,sortkey'', but with the entries ordered by the category sort order.  This would produce each of the four only once, although I see that the behaviour with ''headingmode'' has a very different result.  What query will result in only the four entries in the category, sorted by their sortkey in the category?  Say if [[Somalia]] was in the category ''Category:African Union member states|Ancient Name'' so that it sorted before [[Cameroon]] in the DPL result.  What I am trying to accomplish is a query that returns instructions in the order that they are to be done, where each instruction is a separate page and in a category with a numerical sort key for their ordering.  If I use ''category=sortkey'', I get an SQL error:
<pre>
Unknown column 'cl_head.cl_sortkey' in 'field list'
</pre> -- [[User:66.83.143.246|66.83.143.246]] 13:52, 12 September 2007 (CEST)

:::Look at [[:Category:Step]]. I tried to build a small example. Can you demonstrate your problem using that example?
:::--[[User:Gero|Gero]] 08:50, 13 September 2007 (CEST)

::::I see that sorts all of the [[:Category:Plan]] steps before all of the [[:Category:Execute]] steps, but the steps in each category are unordered.  What I need is the ability to sort the individual entries in the category by their sortkey rather than alphabetically.  For instance, what if the [[Task think]] step must happen before the [[Task buy food]] step?  (Otherwise you just purchase the groceries without planning what to make)  It seems that '''ordermethod=sortkey''' should do it, but this produces an sql error: [[User:66.83.143.246|66.83.143.246]] 17:02, 13 September 2007 (CEST)

{{#dpl:
 |category=Plan
 |ordermethod=sortkey
}}

:::::Indeed there is a bug with the sortkey ordermethod. It works if you write "sortkey,category" as you can see on the [[:Category:Step]] page. But inside the nested query the comma is misunderstood. Therefore you must call a separate Template. Not beautiful, but o.k. as a work-around, I think.
:::::--[[User:Gero|Gero]] 18:53, 13 September 2007 (CEST)

== <tt>[[titlematch]]</tt> rendering ==

I'm having trouble getting this query to render correctly in [[MediaWiki:Noexactmatch]]. If I render it as:

<pre><nowiki>{{#dpl:namespace=|titlematch=%$1%|noresultsheader=none}}</nowiki></pre>

...it gives "none" for every page, even if the page actually ''has'' pages that use "$1" (the searched-for string). So then I tried it as a parser tag:

<pre>
<nowiki>
<dpl>namespace=
titlematch=%$1%
noresultsheader=none
</dpl>
</nowiki>
</pre>

But then I just get "UNIQ8b04b9c2c32d65b-dpl-00000004-QINU"... -[[User:Eep²|Eep²]] 14:17, 13 September 2007 (CEST)

:Why don´t you try
:<pre><nowiki>{{#dpl:namespace=|titlematch=%{{{1}}}%|noresultsheader=none}}</nowiki></pre>
:[[User:Gero|Gero]] 18:39, 13 September 2007 (CEST)

::Because it's not a template and <tt>$1</tt> is what the MediaWiki page is already configured to accept as the input (search) string... I tried adding the braces but then I get this error:
:::<b>Warning</b>:  array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in <b>../wiki/includes/Parser.php</b> on line <b>3316</b>.
::-[[User:Eep²|Eep²]] 06:10, 14 September 2007 (CEST)

::Still need help with this... -[[User:Eep²|Eep²]] 23:23, 18 September 2007 (CEST)

== %PAGES% and $wgDPL2MaxResultCount ... ==

It seems like %PAGES% should not be affected by $wgDPL2MaxResultCount, but it is. For example, http://pdbwiki.info/index.php/Talk:Main_Page 

The DPL on that page reports 500 articles in the category. Any way that %PAGES% could specifically get its data from the database without hitting $wgDPL2MaxResultCount ? It seems that the idea of $wgDPL2MaxResultCount is quite contrary to its behaviour wrt. %PAGES%.

Cheers, --[[User:Dmb|Dmb]] 14:27, 14 September 2007 (CEST)

== <tt>[[linksto]]</tt> including links in included template ==

I have a [http://www.tnlc.com/wiki/index.php?title=Template:game game template] which has links to various pages that shows which games (that use template:game) link to them (such as [http://www.tnlc.com/wiki/index.php?title=ride ride] which uses [http://www.tnlc.com/wiki/index.php?title=Template:action template:action]). However, now each page will show ''every'' game that uses template:game--even if the actual game's text does not have an actual link to the page. This seems like a bug to me... -[[User:Eep²|Eep²]] 14:05, 14 September 2007 (CEST)

:OK, I figured it out on my own (again, while editing [[C#Combine queries and use a nested query for redirect tracking]], which I still think needs to be better explained and implemented into DPL without requiring nested queries and yet another template to do a redirect list that MediaWiki does natively...see [[DPL:Discussion#Redirects to include pages that link to them?]] for more info). I had to use <tt>[[reset]]</tt> and put <tt><nowiki>{{#dpl:reset=links}}</nowiki></tt> after the DPL statement in the game template. -[[User:Eep²|Eep²]] 08:00, 15 September 2007 (CEST)

:OK, ''not'' resolved. Sheesh...now ''no'' links to ''anything'' on a game which uses template:game is showing up on other pages. What the hell? Only existing links in the ''template'' should not cause games with the ''template'' to show up in lists--while still allowing links in template ''parameter fields'' to still show the game in lists. -[[User:Eep²|Eep²]] 08:07, 15 September 2007 (CEST)

::And even if I <tt><nowiki>{{#if:}}</nowiki></tt> each row to only show filled-in template fields in the table, then my <tt>rowspan</tt>s get screwed up. :/ -[[User:Eep²|Eep²]] 10:11, 15 September 2007 (CEST)

:::Trying to correct this, I decided to try a full HTML table in the template. Unfortunately, this causes my [http://www.tnlc.com/wiki/index.php?title=Comparison_table comparison table] DPL queries that <tt>[[uses]]=Template:game</tt> to yield no results too. Seems DPL has a problem finding template fields inside parser functions... :/ -[[User:Eep²|Eep²]] 15:50, 15 September 2007 (CEST)

::::The problem with too many links showing up and the negative effect of reset=all unfortunately exists. The links which one DPL query creates are seen by the other one and lead to kind of an avalanche effect. I do not have a solution for this at the moment. You could try to generate links which use the ''Call'' extension to point to the referenced page instead of directly linking to them. That should work. [[User:Gero|Gero]] 18:22, 16 September 2007 (CEST)

== linksfrom with 'some other option' causes SQL errors  ==

Below is the DPL that kills the page (in pre for obvious reasons).

I am trying to find out which combination of options exactly causes the error... [[linksfrom]] alone or combined with [[category]] and [[userfomat]] and [[listseparators]] seems fine... must be one of the addXXX parameters... (I can confirm removing the addXXX allows the DPL to run... it just fails to return any useful data because you need the addXXX's to get results!). But what is up with this page! click the edit button next to the above title! --[[User:Dmb|Dmb]] 15:46, 18 September 2007 (CEST)

<PRE>
{{#dpl:
  |category       = Country
  |linksfrom      = Main_Page
  |count          = 10
  |mode           = userformat
  |addauthor      = true
  |addpagesize    = true
  |addpagecounter = true
  |addfirstcategorydate = true
  |userdateformat       = d-m-Y
  |listseparators = 
    {¦ class="sortable"
      \n! 
      \n! Date
      \n! Name
      \n! Author
      \n! Views
      \n! Size
    \n¦-,
      \n¦ align="right" ¦ %NR%
      \n¦ align="right" ¦ %DATE%
      \n¦ align="left"  ¦ [[%PAGE%]]
      \n¦ align="left"  ¦ [[User:%USER%¦%USER%]]
      \n¦ align="right" ¦ %COUNT%
      \n¦ align="right" ¦ %SIZE% B,
    \n¦-\n,
    ¦}
}}
</PRE>

Hmm... it seems to 'die' in a much more friendly way on your site than it does mine! Below is the debugging output that I got from your site...

The DPL extension produced a SQL statement which lead to a Database error.
The reason may be an internal error of DPL or an error which you made,
especially when using DPL options like titleregexp.
Query text is:
SELECT DISTINCT `page`.page_namespace as page_namespace, `page`.page_title as page_title, pagesrc.page_title as sel_title, pagesrc.page_namespace as sel_ns, REPLACE(REPLACE(CONCAT( IF(`page`.page_namespace=0, , CONCAT(CASE `page`.page_namespace WHEN 1 THEN 'Talk' WHEN 2 THEN 'User' WHEN 3 THEN 'User_talk' WHEN 4 THEN 'Dpldemo' WHEN 5 THEN 'Dpldemo_talk' WHEN 6 THEN 'Image' WHEN 7 THEN 'Image_talk' WHEN 8 THEN 'MediaWiki' WHEN 9 THEN 'MediaWiki_talk' WHEN 10 THEN 'Template' WHEN 11 THEN 'Template_talk' WHEN 12 THEN 'Help' WHEN 13 THEN 'Help_talk' WHEN 14 THEN 'Category' WHEN 15 THEN 'Category_talk' WHEN 100 THEN 'Type' WHEN 101 THEN 'Type_talk' WHEN 102 THEN 'Test' WHEN 103 THEN 'Test_talk' WHEN 104 THEN 'DPL' WHEN 105 THEN 'DPL_talk' WHEN 106 THEN 'Wgraph' WHEN 107 THEN 'Wgraph_talk' END, ':')), `page`.page_title), '_', ' '),'♣','⣣') as sortkey, page_counter, page_len, rev_user, rev_user_text, DATE_FORMAT(cl0.cl_timestamp, '%Y%m%d%H%i%s') AS cl_timestamp FROM `revision` AS rev, `pagelinks` as plf, `page`as pagesrc, `page` INNER JOIN `categorylinks` AS cl0 ON `page`.page_id=cl0.cl_from AND (cl0.cl_to='Country') WHERE 1=1 AND `page`.page_is_redirect=0 AND `page`.page_id=rev.rev_page AND rev.rev_timestamp=( SELECT MIN(rev_aux.rev_timestamp) FROM `revision` AS rev_aux WHERE rev_aux.rev_page=rev.rev_page ) AND `page`.page_namespace = plf.pl_namespace AND `page`.page_title = plf.pl_title AND pagesrc.page_id=plf.pl_from AND ((plf.pl_from=1)) ORDER BY sortkey ASC LIMIT 10

Error message is:
Column 'page_counter' in field list is ambiguous (localhost)

Good luck! --[[User:Dmb|Dmb]] 15:41, 18 September 2007 (CEST)

=== Answer ===
Thanks for your analysis! Indeed the latest DPL version uses some exception handling to bring up such problems in a way which makes my life easier ;-). The cause was an internal design change which happened two months ago. The error occurs whenever you use one of ''pagecounter, pagelen or page_touched'' in a certain constellation. The bug fix was not so complicated and you will find it in the next release.
[[User:Gero|Gero]] 16:10, 18 September 2007 (CEST)

: Cool!--[[User:Dmb|Dmb]] 18:39, 18 September 2007 (CEST)

==Upgrading from 1.1.0 to 1.4.1 causes addcategories=true to break==
I've been running with 1.1.0 turned on for some time so I thought I'd give 1.4.1 a go. When I turn it on the following code:
<pre>
<DPL>
category=Songs
notcategory=Song Templates
addcategories=true
</DPL>
</pre>
Gives me:
<pre>
The DPL extension produced a SQL statement which lead to a Database error.
The reason may be an internal error of DPL or an error which you made,
especially when using DPL options like titleregexp.
Query text is:
SELECT DISTINCT `mw_page`.page_namespace as page_namespace, `mw_page`.page_title as page_title, REPLACE(REPLACE(CONCAT( IF(`mw_page`.page_namespace=0, , CONCAT(CASE `mw_page`.page_namespace WHEN 1 THEN 'Talk' WHEN 2 THEN 'User' WHEN 3 THEN 'User_talk' WHEN 4 THEN 'WMD' WHEN 5 THEN 'WMD_talk' WHEN 6 THEN 'Image' WHEN 7 THEN 'Image_talk' WHEN 8 THEN 'MediaWiki' WHEN 9 THEN 'MediaWiki_talk' WHEN 10 THEN 'Template' WHEN 11 THEN 'Template_talk' WHEN 12 THEN 'Help' WHEN 13 THEN 'Help_talk' WHEN 14 THEN 'Category' WHEN 15 THEN 'Category_talk' END, ':')), `mw_page`.page_title), '_', ' '),'♣','⣣') as sortkey, GROUP_CONCAT(DISTINCT cl_gc.cl_to ORDER BY cl_gc.cl_to ASC SEPARATOR ' | ') AS cats FROM `mw_page` LEFT OUTER JOIN (`mw_categorylinks` AS cl_gc) ON (page_id=cl_gc.cl_from) INNER JOIN `mw_categorylinks` AS cl0 ON `mw_page`.page_id=cl0.cl_from AND (cl0.cl_to='Songs') LEFT OUTER JOIN `mw_categorylinks` AS cl1 ON `mw_page`.page_id=cl1.cl_from AND cl1.cl_to='Song_Templates' WHERE 1=1 AND cl1.cl_to IS NULL AND `mw_page`.page_is_redirect=0 GROUP BY page.page_id ORDER BY sortkey ASC LIMIT 500

Error message is:
Unknown column 'page.page_id' in 'group statement' (localhost)
</pre>

Help gratefully accepted! BTW I'm running on:

    * MediaWiki: 1.10.0
    * PHP: 5.2.1 (cgi)
    * MySQL: 5.0.27-standard 


[[User:Brianoflondon|Brianoflondon]] 10:55, 19 September 2007 (CEST)