DPL:Bug Reports

From FollowTheScore
Revision as of 07:07, 15 September 2007 by Eep² (talk | contribs) (→‎<tt>linksto</tt> including links in included template: NOT resolved!)
Jump to: navigation, search

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


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?

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)

See also

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

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

      %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, --Dmb 14:27, 14 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)
      Retrieved from "http://followthescore.org/dpldemo/index.php?title=DPL:Bug_Reports&oldid=6423"