DPL:Bug Reports

From FollowTheScore
Jump to: navigation, search
This document is no longer in use. 
See the list of bug reports ..

There may be some bug reports in the following document which 
from the respective authors´ point of view still need answer. 
In such cases please create a Bug report according to the new pattern and copy the text.

Gero 14:12, 29 September 2007 (CEST) 

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


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. --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 ... 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... (function stack at Parser::parse)
  1. First all <dpl> calls are each processed.
    (Parser::parse => Parser::strip => DynamicPageList2)
    1. Each call also processes its category tags into mCategories before returning.
      (DynamicPageList2 => Parser::recursiveTagParse => Parser::internalParse => Parser::replaceInternalLinks)
    2. Each "<dpl>reset=categories</dpl>" empties any mCategories categorization done.
  2. Then all {{#dpl:}} calls are each processed.
    (Parser::parse => Parser::internalParse => Parser::replaceVariables => Parser::braceSubstitution => wfDynamicPageList4)
    1. Each call does not categorize into mCategories before returning. Any category tags are returned as part of unprocessed text.
    2. Each "{{#dpl:reset=categories}}" empties any mCategories categorization done.
  3. Then the top level result text as a whole processes its category tags into mCategories.
    (Parser::parse => Parser::internalParse => Parser::replaceInternalLinks)
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 "<dpl>reset=categories</dpl>" would still not work against {{#dpl:}} effects, but subsequent "{{#dpl:reset=categories}}" 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. --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?

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.
--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. --Nad 08:03, 3 September 2007 (CEST)
Which requires yet more syntax/markup conversion between HTML and MediaWiki, making extensions (like Semantic Forms) even more annoying to use, especially with tables and creating links to pages on the current wiki). Bah... -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. --Nad 05:43, 4 September 2007 (CEST)
However, an extension which mindlessly disables wiki markup also has other effects, as I previously mentioned. Duh. -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.
--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? --Rezyk 00:55, 6 September 2007 (CEST)

distinct

distinct (defaults to true) seems to have problems with this query in a template: 

{{#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.''
}}

...showing duplicate entries for a 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: 

{{effect|liquid bubble|water bubble}}

...which should just show the game once (the first parameter is for a Wikipedia link). -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?
--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... -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. 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). -Eep² 10:24, 7 September 2007 (CEST)

debug 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 debug to it but then all text is removed from a page (and if debug=3 is at the end, no warning is given about it should be in the beginning either): 

{{#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 {{PAGENAME}} not working inside a tag...: 

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

In trying to get a query that works here, I don't know why this isn't outputting anything either: 

<dpl>
debug=3
namespace=
titlematch=Test%
resultsheader=\n<h2>See also</h2>
noresultsheader=<div style=display:none></div>
</dpl>

It should show the many articles that start with "Test". -Eep² 06:22, 8 September 2007 (CEST)

  1. 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.
  2. Variables like PAGENAME are not expanded if you use parser tag syntax like <dpl> 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 debug 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 debug 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 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. Gero 12:04, 8 September 2007 (CEST)
Please re-read my initial bug report... -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.


debug=3 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 debug=4 (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). -Eep² 14:33, 9 September 2007 (CEST)


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? 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:

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


If the ordermethod is removed, it works fine:


      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:

      {{#dpl: |category=African Union member states |ordermethod=category,sortkey |headingmode=H4 |columns=3 }} What do you really want to achieve with your query?

      --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:
      Unknown column 'cl_head.cl_sortkey' in 'field list'
      -- 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?
      --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: 66.83.143.246 17:02, 13 September 2007 (CEST)
      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.
      --Gero 18:53, 13 September 2007 (CEST)

      titlematch rendering

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

      {{#dpl:namespace=|titlematch=%$1%|noresultsheader=none}}

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

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

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

      Why don´t you try
      {{#dpl:namespace=|titlematch=%{{{1}}}%|noresultsheader=none}}
      Gero 18:39, 13 September 2007 (CEST)
      Because it's not a template and $1 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:
      Warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in ../wiki/includes/Parser.php on line 3316.
      -Eep² 06:10, 14 September 2007 (CEST)
      Still need help with this... -Eep² 23:23, 18 September 2007 (CEST)
      I do not understand what the "$" should do. What do you mean by 'search string'? I see no functionality in mediawiki which would try to replace a $ character within a document by some value ...
      Gero 19:00, 19 September 2007 (CEST)
      If you look at MediaWiki:Noexactmatch you will see it uses "$1" as a variable for the search string (the text string that was entered into the search field). This is common throughout MediaWiki system messages... -Eep² 05:27, 20 September 2007 (CEST)

      Reply

      Now I understand. The $-replacement is a very special mechanism which only applies to MediaWiki messages. Changing the default message in a way that it presents similar pages to the editor is a very nice idea!

      • The following dpl statement does the job:
       '''There is no page titled "$1".''' You can [[:$1|create this page]].
 <dpl>
 debug=1
 resultsheader=    ''There are some pages similar to '$1':''\n
 titlematch=%$1%
 </dpl>
      • I installed it here, so you can watch it live if you e.g. enter "Nig" in the searchbox.
      • Could you test in your wiki and publish a statement in the FAQ here as others might want to adopt it?

      Gero 12:37, 20 September 2007 (CEST)

      Doesn't work; I still get "UNIQ5f1c6b5250d04dee-dpl-00000002-QINU" with just
      <dpl>
debug=1
titlematch=%$1%
</dpl>
      -Eep² 13:16, 20 September 2007 (CEST)
      You will have to get help from elsewhere. It works here in the DPLDEMO wiki and the UNIQ...stuff does not come from DPL. Gero 13:39, 20 September 2007 (CEST)
      I've checked elsewhere but the results imply the bug is from earlier MediaWiki/DPL versions:
      (You might want to add the "meta" interwiki link, too.) -Eep² 13:51, 20 September 2007 (CEST)

      linksto including links in included template

      I have a game template which has links to various pages that shows which games (that use template:game) link to them (such as ride which uses 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... -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 reset and put {{#dpl:reset=links}} after the DPL statement in the game template. -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. -Eep² 08:07, 15 September 2007 (CEST)
      And even if I {{#if:}} each row to only show filled-in template fields in the table, then my rowspans get screwed up. :/ -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 comparison table DPL queries that uses=Template:game to yield no results too. Seems DPL has a problem finding template fields inside parser functions... :/ -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. 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! --Dmb 15:46, 18 September 2007 (CEST) 

      {{#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,
    ¦}
}}

      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! --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. Gero 16:10, 18 September 2007 (CEST)

      Cool!--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: 

      <DPL>
category=Songs
notcategory=Song Templates
addcategories=true
</DPL>

      Gives me: 

      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)

      For some extra help I just compared the SQL when running with 1.1.0. They're rather similar except for the GROUP BY command at the end: 

      ..... GROUP BY page_id ORDER BY sortkey ASC LIMIT 500

      And with 1.4.1 

      ..... GROUP BY page.page_id ORDER BY sortkey ASC LIMIT 500

      What's with the extra page.page_id?

      Help gratefully accepted! BTW I'm running on: 

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


      Brianoflondon 10:55, 19 September 2007 (CEST)

      Reply

      This error has been reported by another user as well. It is already fixed in my developer´s version and the fix will be part of the next release (which will be published somewhen next week). The reason is that the GROUP statement does not respect the database table name prefix (mw_ in your case).

      Gero 19:07, 19 September 2007 (CEST)

      Thanks

      Thanks! Thought it was something I was doing... I'll stick with 1.1.0 till then.
      19:29, 19 September 2007 (CEST)

      query no longer working

      I don't know why this query isn't working anymore: 

      {{#dpl:
category=games
|linksto={{PAGENAME}}{{!}}{{PAGENAME}}s{{!}}{{PAGENAME}}es{{!}}{{PAGENAME}}ies{{!}}{{PAGENAME}}ing{{!}}{{PAGENAME}}ed
{{#if:{{{1|}}}|{{!}}{{{1}}}{{!}}{{{1}}}s{{!}}{{{1}}}es{{!}}{{{1}}}ies{{!}}{{{1}}}ing{{!}}{{{1}}}ed|}}
{{#if:{{{2|}}}|{{!}}{{{2}}}{{!}}{{{2}}}s{{!}}{{{2}}}es{{!}}{{{2}}}ies{{!}}{{{2}}}ing{{!}}{{{2}}}ed|}}
{{#if:{{{3|}}}|{{!}}{{{3}}}{{!}}{{{3}}}s{{!}}{{{3}}}es{{!}}{{{3}}}ies{{!}}{{{3}}}ing{{!}}{{{3}}}ed|}}
|uses=Template:game
|notnamespace=Template
|notnamespace=Form
|redirects=include
|distinct=strict
|resultsheader=<h2>Games (%PAGES%)</h2>
|noresultsheader<h2>Games (0)</h2>''No games have this action yet.''
}}

      Called from template:action, this query used to list Half-Life² since it has a link to [[locks]] in it, uses Template:game, and is not in the "Template" and/or "Form" namespaces (is in "(Main)") and "locks" is a redirect to "lock". However, if I remove |uses=Template:game the game will show up, but I don't understand why since the game does use template:game... -Eep² 14:08, 19 September 2007 (CEST)

      This sounds a little bit complicated. Currently I am working on a mechanism which tries to get rid of unwanted backlinks created by DPL queries. As this is VERY complicated and might have an influence on the behaviour you described I suggest that you check again with version 1.4.2 (somewhen next week). If you then still feel there is a problem I would need an example here in this wiki, as much stripped down as possible! Gero 19:16, 19 September 2007 (CEST)
      Unwanted backlinks? I want my DPL backlinks! (i.e. for "Article x" -> "what links here" = "DPL report page y"). I find this feature very useful and was planning to build features of my site around this behavior... Is that what you are going to remove? --Dmb 20:58, 19 September 2007 (CEST)
      It's not complicated. I'm just trying to get pages in the "games" category that use the "game" template to show up--but even that doesn't work. Again, if I remove the "uses" line, the query works fine but I need to restrict the results to only pages that actually use this specific template... -Eep² 05:27, 20 September 2007 (CEST)

      Fatal Parser error.

      I've recently updated the extension from version 0.7.7 and am now getting a fatal php error:

      Call to undefined method Parser::recursiveTagParse() in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\lib\wiki\extensions\DynamicPageList\DynamicPageList2.php on line 728

      Any ideas?

      Your MediaWiki installation is too old. The recursiveTagParse() method is available in the newer versions of MW but not in older ones. You should consider to update your mediawiki installation. Gero 23:59, 26 September 2007 (CEST)
      Retrieved from "http://followthescore.org/dpldemo/index.php?title=DPL:Bug_Reports&oldid=6999"