Difference between revisions of "DPL Example 022"
| Line 20: | Line 20: | ||
| namespace = Issue | | namespace = Issue | ||
| uses = Template:Issue | | uses = Template:Issue | ||
| − | | include = {Issue}:Description | + | | include = {Issue}:Description,#Problem,#Reply |
| − | | table = class="wikitable sortable",Issue,Description | + | | table = class="wikitable sortable",Issue,Description,Problem,Reply |
| order = descending | | order = descending | ||
| count = {%DPL_count:10%} | | count = {%DPL_count:10%} | ||
Revision as of 18:14, 2 August 2009
The result of this query is written to a cache; the next requests will be served from that cache. Add &DPL_refresh=yes to the URL to enforce a cache update. Note that each scrolled page is separately cached. Once you refresh the cache, all pages of former scrolling actions are removed. Try the following:
- load the page and click on the small "refresh" link below the table (if you do not see the link, load the page a second time)
- remove the "&DPL_refresh=yes" part AND the "&DPL_offset=0" part in the URL of your browser and reload the page
- reload again
- scroll to the next page
- scroll back, i.e. click on "1..10"
- scroll forward (11..20)
- scroll forward (21..30), then load the page a second time
- click on the small "refresh" link below the table
- remove the "&DPL_refresh=yes" part in the URL of your browser and reload the page
- scroll back (11..20)
- scroll forward (21..30)
- In step 1 there is no message - the cache has silently been created, cache pages of older scroll events have been removed
- In steps 2,3,5,6,11 you should see a small note which proves that the result comes from the cache. Watch the "age" indicator!
- In the other steps (2,4,7,8,9,10) you should see a note that the cache has been created or re-built.
Extension:DynamicPageList (DPL), version 3.2.1: Warning: Unknown parameter 'dplcache' was ignored. Help: available parameters: addauthor, addcategories, addcontribution, addeditdate, addexternallink, addfirstcategorydate, addlasteditor, addpagecounter, addpagesize, addpagetoucheddate, adduser, allowcachedresults, allrevisionsbefore, allrevisionssince, articlecategory, cacheperiod, categoriesminmax, category, categorymatch, categoryregexp, columns, count, createdby, debug, distinct, dominantsection, eliminate, escapelinks, execandexit, firstrevisionsince, fixcategory, format, headingcount, headingmode, hiddencategories, hitemattr, hlistattr, ignorecase, imagecontainer, imageused, include, includematch, includematchparsed, includemaxlength, includenotmatch, includenotmatchparsed, includepage, includesubpages, includetrim, inlinetext, itemattr, lastmodifiedby, lastrevisionbefore, linksfrom, linksto, linkstoexternal, listattr, listseparators, maxrevisions, minoredits, minrevisions, mode, modifiedby, multisecseparators, namespace, noresultsfooter, noresultsheader, notcategory, notcategorymatch, notcategoryregexp, notcreatedby, notlastmodifiedby, notlinksfrom, notlinksto, notmodifiedby, notnamespace, nottitlematch, nottitleregexp, notuses, offset, oneresultfooter, oneresultheader, openreferences, order, ordercollation, ordermethod, qualitypages, randomcount, redirects, replaceintitle, reset, resultsfooter, resultsheader, rowcolformat, rows, rowsize, scroll, secseparators, showcurid, shownamespace, skipthispage, stablepages, suppresserrors, table, tablerow, tablesortcol, title, titlegt, titlelt, titlematch, titlemaxlength, titleregexp, usedby, userdateformat, uses.
| 1..1011..20(243 total) |
| Issue | Description | Problem | Reply |
|---|---|---|---|
| Including Sections | Trying to include sections that have a link in their headline |
I'm trying to include particular sections with 'include' and the section headers are links. So I use {{#dpl:titlematch=%Bug Reports%Include%|include=#[[Link]]}} and I get an error. |
The problem is that the parser converts the double brackets into a hyperlink before the text is used as a search criterion within DPL. I will look if there is a way around this. Gero 23:26, 27 September 2007 (CEST) |
| Error message - undefined Index 100 | using notnamespace causes php error in line 3128 |
Getting this error 10 times for http://www.tnlc.com/wiki/index.php?title=Template:catcount : Notice: Undefined index: 100 in ../wiki/extensions/DynamicPageList2/DynamicPageList2.php on line 3128 With this query:
{{#dpl:
category={{{1}}}
|notnamespace=Template
|notnamespace=Form
|resultsheader=(%PAGES%)
|noresultsheader=(0)
|format=,
}}
—Eep² 12:09, 29 September 2007 (CEST) |
This sounds like you have an error in the namespace setup of your wiki. If you use own namespaces you should assign index pairs to them starting from '100' as is recommended in the MW documentation. I guess the query works when you leave out the "notnamespace=Form"?
|
| DPL and Glossary clashing | using the Glossary extension seems to have adverse effects on DPL result sets |
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
ReplyGlossary 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. |
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. There are several problems with Glossary. E.g. ist causes a severe error under MW 1.11. So I recommend not to use it together with DPL. I don´t think the problem is on DPL´s side...
|
| Chinese message texts are wrong | 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) |
I will try to restore the correct characters. Gero 13:53, 29 September 2007 (CEST) |
| False result count | result count is affected by the max result limit of DPL |
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) |
You are right. But I would have to do a separate "select count()" statement only to catch these constellations. This would put extra complexity and runtime cost to every DPL query. I doubt that this is a good cost benefit ratio. So I tend to leave it as it is. You could, however, put a #if statement around %PAGES% replacing '500' by '500 or more'. Or should I add the "or more" phrase automatically when the count limit is hit? Gero 23:44, 19 October 2007 (CEST) With version 1.5.2 I changed the implementation of count/offset to use SQL directly. Now DPL behaves as any SQL query would: If a limit is set the returned number of records will equal that limit (provided there more matching records in the database). Executing a second query with changed offset will deliver the next "portion" and so on. Currently there is no such thing like SELECT COUNT(*) from ... in DPL. But you could write a recursive DPL query which fetches all portions and adds up the %PAGES%.
|
| Include positional template parameter | including positional template parameters can fail depending on form of template call |
MediaWiki template parameters are by default numbered but the templates can be called by name. For example, if I have a template that takes one unnamed argument, I can call the template like {{template|arg}} but I can also call it as {{template|1=arg}}. The reason to use the second form is if arg contains an equals sign (so in general it's safer to use the second form if you don't know what arg could be. DPL does not appear to be able to handle this. If I try using include={template}:1, it doesn't find the argument correctly if I use {{template|1=arg}} to call the template. |
Thank you for the precise report. I fixed the bug. Now (Release 1.4.4) DPL treats numeric template parameters correctly.
|
| Upgraded to 1.11 Notice: Undefined variable | Notice: Undefined variable: |
I've upgraded to 1.11, and started getting this error message Notice: Undefined variable: result in /home/wikistoc/public_html/wiki/includes/Title.php on line 1112 --Rovo 23:12, 30 September 2007 (CEST) |
This is my query <DPL> resultsheader= === A === namespace = Terms shownamespace = false titlematch = A% </DPL> I did this for each letter through the alphabet. The Terms namespace is set to 100. I'm not sure how to enable the full error messages or give a full stack trace, but I will try to figure it out. Thank you. --Rovo 03:11, 1 October 2007 (CEST)
|
| Inconsistent node height | small height is handled inconsistently |
Wgraph:Demo height shows that node C appears smaller than node E although the height specifications are contrary to that. |
|
| Surprising bahaviour of forcedir layout | minor changes in atraction lead to different layouts. |
Maybe this is not a bug. But it looks unexplainable and inconsistent from a user´s point of view. Try values 45,46,47 for repulsion in Wgraph:Demo attraction. Leave repulsion empty (default is 20).
|
|
| Change alignment procedure for labels | in multi-line labels the alignment should work on a line base not on label base |
|
| 1..1011..20(243 total) |
{{#dpl:
| namespace = Issue
| uses = Template:Issue
| include = {Issue}:Description
| table = class="wikitable sortable",Issue,Description
| order = descending
| count = {%DPL_count:10%}
| dplcache = offset/{%DPL_offset:%}
| resultsheader = ²{Extension DPL scroll¦total=%TOTALPAGES%¦offset={%DPL_offset:0%}¦count={%DPL_count:10%}¦page={{PAGENAME}}}²\n
| resultsfooter = ²{Extension DPL scroll¦total=%TOTALPAGES%¦offset={%DPL_offset:0%}¦count={%DPL_count:10%}¦page={{PAGENAME}}}²\n
}}
Note the path descriptor of the dplcache which arranges all scrolled result pages withn a subdirectory of the cache.
