DPL:FAQ
Contents
My article name contains underscores, but in the DPL result they don´t appear.
Normally, DPL replaces all undercores in article names by spaces when showing the result. You can replace underscores by their symbolic html name via the 'replaceintitle' statement. So DPL will no longer recognize the underscores and later the html engine will translate the symbolic name to underscores.
This wiki contains an Article_with_underscore. Normally DPL would show it as . But with {{#dpl:titlematch=%underscore|replaceintitle=/ /,_}} you will getI try to generate a table output with DPL but it looks weird - to hell with the syntax!
Indeed, complex queries can be somewhat tricky. But this is not only a problem of DPL. MediaWiki is quite sensitive to blanks and linefeeds and half of your problemss will probably come from there.
There is a simpe trick how you can DEBUG your DPL script:
Use a resultsheader and a resultsfooter to enclose all DPL output in pre/nowiki tags like this:
<dpl> resultsheader=<pre><nowiki> resultsfooter=</nowiki></pre> titlematch=A% format=,\n*[[%PAGE%|%TITLE%]] </dpl>
With this little trick you will see the output of DPL which would normally be rendered by the wiki parser:
{{Extension DPL}}{|class=wikitable
!article
!beginning
|-
[[A1|A1
[[Abc/def|Abc/def
[[A ECP-00055 test page|A ECP-00055 test page
[[Article with underscore|Article with underscore
[[Activity Page 1|Activity Page 1
[[Activity Page 2|Activity Page 2
[[A2|A2
[[Aa|Aa
[[Annotation URI|Annotation URI
[[An article which is only referenced by a DPL query|An article which is only referenced by a DPL query
[[AbC|AbC
[[Article connected by DPL category keyword|Article connected by DPL category keyword
[[Abc|Abc
[[Activity 1|Activity 1
[[Activity 2|Activity 2
[[Activity 3|Activity 3
[[A|A
[[Apache服务器架设的简单，由小P发布|Apache服务器架设的简单，由小P发布
[[Application DPL-tracker|Application DPL-tracker
When you set "debug=5" in one of your DPL queries you will see that there is a _TOC_ pragma within the text output produced by DPL. It may come from a style sheet or from the original sources of the pages you include. I recommend to embed the DPL queries within a #replace statement to eliminate these pragmas.
When doing this you have to change the dpl calls to parser function calls - otherwise the replacement statement will not work (due to the expansion logic and hierarchy of MW). I made the necessary changes in your wiki and stored the modified page under http://sunshinereview.org/index.php/The_Sunshine_Review_Gazette_2.
Unfortunately the ''references'' chapter does not work in combination with DPL. I still suspect that the problem lies within the CITE extension but do not have time for deeper investigations.
[[User:Gero|Gero]] 07:40, 7 March 2010 (UTC)
[[Applying a template to all pages of a given category|Applying a template to all pages of a given category
Sometimes you want to create a list of articles where each entry in the list points to an adress which is constructed from the article´s name. Basically, this means that you want to produce the equivalent of
<pre><nowiki>
{{some template|1st page in category}}
{{some template|2nd page in category}}
{{some template|3rd page in category}}
...
[[Allowing true caching by DPL dev page|Allowing true caching by DPL dev page
- Implemented only for Parser Function invocation.
- Automatically works when allowcachedresults is set to true for a given DPL invocation.
- Uses the mediawiki caching system (which is good because no matter if you use memcached, database storing or file storing, and squid, it will work.)
- Some things were already implemented : everytime the article in which there is a DPL invocation is touched, the cache is purged already so I did not have to deal with this. Also, everytime a template that is invoked on the DPL invocation page is modified, the cache is purged for that page, so we don't need to invent a whole new system of template memorizing, mediawiki already does it.
- A table named dpldependencies is created in the mediawiki database. It contains 2 important fields : cacheids and categorydeps. cacheids contains a list of ':' separated numbers that represents ids of article that need to be purged when an article that has categories such as those of the associated categorydeps is parsed (so this is aggressive outdating of the content, including when pages of the given categories are touched, purged, resaved, or simply when the 24 hours have been reached (and that someone refreshed the page after these 24 hours)). categorydeps contains strings such as : 1&2&NewCategory&Kitchen Stuff&Spoons. the | (or) logic is not stored in the database, it's considered to be completely different entries. Only the & (and) logic is stored.
- Additionnaly to the update rules that were already present in mediawiki, I added 1 rule : when an article is rendered (parsed), look for categories, compute all the possible combinations of those categories, and look in the database for updates rules and purge the cacheids that we need to purge.
- Works with categories set as variables because it works at the InternalParseBeforeLinks level (for example a template page that would develop : [[Category:{{{VariableCategory}}}]] etc...
[[Amethyst|Amethyst
Amethyst is a purple variety of quartz (SiO2) and owes its violet color to irradiation, iron impurities (in some cases in conjunction with transition element impurities), and the presence of trace elements, which result in complex crystal lattice substitutions.<ref>Greenwood, Norman N.; Earnshaw, Alan (1997). Chemistry of the Elements (2nd ed.). Butterworth–Heinemann. ISBN 0080379419. http://www.amazon.com/Chemistry-Elements-Second-Edition-Earnshaw/dp/0750633654.</ref><ref name="scielo.br">Fernando S. Lameiras, Eduardo H. M. Nunes, and Wander L. Vasconcelos (2009), "Infrared and Chemical Characterization of Natural Amethysts and Prasiolites Colored by Irradiation" in Materials Research, vol. 12 no. 3, pp. 315-320,</ref><ref name=Gems>Micheal O'Donoghue (2006), Gems, Butterworth-Heinemann; 6th ed. ISBN 978-0-7506-5856-0</ref> The hardness of the mineral is the same as quartz, thus it is suitable for use in jewelry.
[[Talk:Allowing true caching by DPL dev page|Allowing true caching by DPL dev page
Am quite interested in this concept -- as we have a high-traffic wiki with over 70k pages, and would like to use DPL on every page (several times over) to display news, images, etc. Caching and db load are a significant issue.
Any chance there is a status update? Anything I can do to help?
Maybe there is a simpler (temporary) solution?
--Jb 03:38, 18 February 2009 (UTC)
[[User:AssaCom|AssaCom
User:AssaCom
[[User:Alf63/C1|Alf63/C1
[[User:Alf63/C2|Alf63/C2
[[User:Alf63/RP.dpl.default|Alf63/RP.dpl.default
[[User:Alf63/SeqSize|Alf63/SeqSize
[[User:Alf63/RP|Alf63/RP
[[User:Alf63/SeqGet|Alf63/SeqGet
[[User:Alf63/RP of|Alf63/RP of
[[User:Adomjan|Adomjan
[[User:Arcandio|Arcandio
[[User:Armin.Egner|Armin.Egner
[[User:Alf63/Seq test1|Alf63/Seq test1
[[User:Aaron Overton|Aaron Overton
[[User:Awodejko|Awodejko
[[User:Alf63|Alf63
Voir plutôt: http://www.mediawiki.org/wiki/Extension:ArrayExtension
[[User:AJim|AJim
[[User:Alf63/P1|Alf63/P1
[[User:Anonguy9|Anonguy9
SIMPLE instructions for everyday usage.
I use DPL for only one thing right now, so I have complete documentation for that one activity.
[[User:Arturro|Arturro
[[User talk:Anonguy9|Anonguy9
[[User talk:Alf63/P1|Alf63/P1
[[File:Arrow-closed.png|Arrow-closed.png
[[File:Arrow-open.png|Arrow-open.png
[[File:Asking a calendar kit 2.png|Asking a calendar kit 2.png
[[File:Asking a calendar kit 1.png|Asking a calendar kit 1.png
[[Template:Amp|Amp
[[Template:Ask is a|Ask is a
[[Template:Abc/x123|Abc/x123
[[Template:Articles|Articles
[[Template:Alias Wgraph|Alias Wgraph
[[Template:African Country|African Country
[[Template:Audio|Audio
[[Template:ActivitySummary|ActivitySummary
[[Template:Activity Description|Activity Description
[[Template:About|About
[[Category:AT&|AT&[[Category:Apachetest|Apachetest
[[Category:AT&T|AT&T
[[Category:African Union member states|African Union member states
[[Category:Antwerpen|Antwerpen
[[Category:Another Topic|Another Topic
[[Allows value|Allows value
Allows value
[[Age|Age Age
[[Annotation URI|Annotation URI
[[Wgraph:Architecture|Architecture
Wgraph is based on a powerful graph layout and rendering product named aiSee.
- aiSee is developed and actively maintained by the German company AbsInt.
- aiSee is written in C++; binary versions are available for Windows and Linux.
- To use Wgraph you need a license of aiSee (non commercial use is free under certain conditions).
- aiSee uses GDL as a graph definition language.
- The WGL language of wgraph is similar to GDL but has some additional features like a general typing concept for nodes and edges.
{{#wgraph: name= wgraph_structure | thumb= 45 | svg | png |
node user { icon user }
node WGL { type code label "WGL script" color #ddffdd}
node wgraph wg { type program label "wgraph (php)" color #ddffdd }
node legend wg { label "wgraph translates WGL notation into GDL notation; it triggers aiSee in the background"
textwidth 20 fontname timI10 bordercolor white height 80 }
node html { type code }
node aiSee wg1 { type program color #99ff99 }
node wikitext { type code }
node mw { type program label "mediawiki engine" }
node GDL wg1 { type code label "GDL script" color #99ff99 }
node png wg2 { type image }
node thumb wg2 { type image }
node svg wg2 { type image }
subgraph wg { label "wgraph extension" color lightyellow state wrapped }
subgraph wg1 wg { label "layout engine" color khaki state clustered }
subgraph wg2 wg { label "graph formats" color lightgreen state boxed }
edge from user to wikitext { label "edit" color red }
edge from wikitext to mw { label "save" }
edge from wikitext to WGL { label "contains" }
edge from WGL to wgraph { label "parse" }
edge from wgraph to GDL { }
edge from GDL to aiSee { }
edge from aiSee to png { }
edge from aiSee to thumb { kind rightbentnear }
edge from aiSee to svg { }
edge from mw to html { }
edge from mw to wgraph { type call }
edge from wgraph to html { label "insert link" }
edge from html to thumb { type link label "img" }
edge from thumb to png { type link }
edge from thumb to svg { type link }
edge from wgraph to aiSee { type call }
edge from wgraph to legend { type comment }
nodetype image { title image shape hexagon color lightcyan }
nodetype code { color #ffffcc shape ellipse borderwidth 1 }
nodetype program { color #ffccff }
edgetype include { linestyle dotted }
edgetype call { color red label "call" }
edgetype link { linestyle dotted color blue label "href" }
edgetype comment { kind near linestyle dotted arrowstyle none }
node.borderwidth = 1
node.height = 40
xspace = 140
splines = yes
iconcolors = 1024
// subgraph wg {state folded}
}}
This graph was created with the help of wgraph. See the WGL source.
As you can see WGL is being translated to GDL by wgraph. Then the aiSee graph renderer is invoked in batch mode on the server and produces a png or svg image together with a small png thumb image. The thumb image is shown on the html version of the wiki page and links to the graph. The user will also find a link to the GDL code if he prefers local viewing. The aiSee rich client allows (among other features) to
- change the layout manually
- fold parts of the graph into subgraphs
- generate multipage postscript output
- interact with other local applications[[Wgraph:Ahnen|Ahnen
[[Issue:Add new option to exclude page sections|Add new option to exclude page sections
LST extension has a similar feature but it is not geared towards the visual sections. would it be possible to add this to dpl?
[[Issue:Allow vertical alignment of node labels|Allow vertical alignment of node labels
If the user specifies a fixed height for nodes he might want to define a vertical alignment rule for the positioninig of the label text. Currently the label is always vertically centered. See Wgraph:Demo valign
[[Issue:Assigning absolute position of 0-0|Assigning absolute position of 0-0
If you do so aiSee will think that no absolute position for that node has been defined. AiSee will then drop absolute layout generally.
AiSee should be able to make a difference between assigning 0/0 to a node and not making an assignment at all.
[[Issue:Ampersand fails in category names|Ampersand fails in category names
This DPL:
<dpl> category=Any category with a & character in its name </dpl>
always produces empty results, even if the category exists and contains articles.
This is in MediaWiki 1.20.
The categorymatch keyword does not have this problem.
[[Issue:Allow includereplace or ability to ignore included section headers|Allow includereplace or ability to ignore included section headers
Example: includereplace=/^=\+.*=\+//
The above would remove any section headers before the wikicode of each include is sent to the Parser.
or just an includesectionheaders=false to 'automagically' do that.
[[Issue:Addlasteditor crashes new article|Addlasteditor crashes new article
Edit a new article and add a DPL query that contains addlasteditor. Save. The page will crash on save, probably because there is no last editor yet. error_log says:
- [Mon Mar 15 16:12:26 2010] [error] [client nn.nn.nn.nn] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/w/extensions/Cite/Cite_body.php on line 658, referer: http://mysite/w/index.php?title=Template:Lasteditor&action=edit&redlink=1
Test case:
{{#dpl:
|namespace={{NAMESPACE}}
|titlematch={{PAGENAME}}
|skipthispage=no
|addlasteditor=true
|mode=inline
}}
Take away "addlasteditor=true" and the save works. Then add "addlasteditor=true" again, and everything is fine. It's only for new articles.
[[Issue:AddContribution missing prefix|AddContribution missing prefix
addcontribution on a wiki that uses a table prefix results in:
The DPL extension (version 1.5.0) 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 `lw_page`.page_namespace as page_namespace, ... LEFT OUTER JOIN (`lw_categorylinks` AS cl_gc) ON (page_id=cl_gc.cl_from) ... ORDER BY sortkey ASC LIMIT 500
Error message is:
Unknown column 'page.page_id' in 'where clause' (localhost)
To fix:
Change line 2332 in DynamicPageList2.php from:
$sSqlWhere .= ' AND page_id=rc.rc_cur_id';
to:
$sSqlWhere .= ' AND ' . $sPageTable .'.page_id=rc.rc_cur_id';
[[Issue:AddContribution missing prefix regression|AddContribution missing prefix regression
The bug Issue:AddContribution missing prefix has returned in DPL 1.8.9.
{{#dpl:
|namespace={{NAMESPACE}}
|titlematch={{PAGENAME}}
|skipthispage=no
|addcontribution=true
}}
On our system this produces:
The DPL extension (version 1.8.9) 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 `vpw_page`.page_namespace as page_namespace,`vpw_page`.page_title as page_title,`vpw_page`.page_id as page_id, SUM( ABS( rc.rc_new_len - rc.rc_old_len ) ) AS contribution, rc.rc_user_text as contributor FROM `vpw_recentchanges` AS rc, `vpw_page` WHERE 1=1 AND page.page_id=rc.rc_cur_id AND `vpw_page`.page_namespace IN ('202') AND (`vpw_page`.page_title LIKE 'Lasteditor') AND `vpw_page`.page_is_redirect=0 GROUP BY rc.rc_cur_id ORDER BY page_title ASC LIMIT 0, 500
Error message is:
Unknown column 'page.page_id' in 'where clause' (localhost)
However, on http://followthescore.org which is running 1.9.0, the bug doesn't seem to happen. Has it been fixed in 1.9.0?
[[Issue:An Error of conbime using of StringFunctions extension and Simple Form|An Error of conbime using of StringFunctions extension and Simple Form
Hi Greo:
When I make this change. The top of the page shows the following message:
Warning: preg_replace() [function.preg-replace]: Unknown modifier 'z' in /www/htdocs/w0057617/dpldemo/extensions/StringFunctions/StringFunctions.php on line 285
Could you give a hand?--Roc michael 03:51, 12 April 2008 (CEST)
[[Issue:Adduser|Adduser
I created a list of recent changes using:
<DPL> ordermethod=lastedit order=descending count=5 namespace= shownamespace=false adduser=true redirects=exclude </DPL>
I expect to see the last 5 edits with the names of the users that made these edits. I do see the last 5 edits with the names of the initial creators of these pages. Is this a bug or am I doing something wrong? Please help.
Regards, Paul.
[[Issue:Add "minimum-number-of-revisions" like Criteria for page selection|Add "minimum-number-of-revisions" like Criteria for page selection
For our German Wiki at http://www.thomas-krenn.com/de/wiki/Hauptseite I would like to generate a box with 'recent changes' content which does not list newly generated pages (pages that have only a single revision/version). Reason: we already have a box with 'newest articles' ("Neueste Artikel"), so new articles would show up in both boxes.
I can get a 'recent changes' content with the following code, but I would need an additional criteria like "minimum-number-of-revisions=2" to avoid new pages of being listed:
<DPL> namespace= columns=1 ordermethod=lastedit minoredits=exclude order=descending count=5 shownamespace=yes nottitlematch=Hauptseite|Produkt-News:% addeditdate=true userdateformat=(d.m.Y) format=,\n* [[%PAGE%|%TITLE%]] %DATE%,, </DPL>
btw: thank you for this great Mediawiki extension!
[[Issue:Article Titles/content added as sub bullets|Article Titles/content added as sub bullets
calling DPL like this:
<dpl> ordermethod=firstedit order=descending category=test notnamespace=Template | Category nottitlematch=%_test noresultsheader = Sorry, no results yet includepage= #Description[500 ...more] addpagecounter=true </dpl>
and get output like this sometimes:
- Test_article1 (41 views)
- some info
- further info ...more
- Test_article2 (40 views)
[[Issue:Asking a parser "replace " demo|Asking a parser "replace " demo
Hi Gero.
Could you give me the samples on using parser "replace" (or using other way) with following cases. for exapmle {{#replace: [[User:Michael|Roc Michael]] | from | to }}
| Item | From (Before) | To (After) |
|---|---|---|
| Case 1 | [[User:Michael|Roc Michael]] and |
Roc Michael and 張小三 |
| Case 2 | [[User:Michael|Roc Michael]] and |
Michael and 張三 |
Please give me a hand.--Roc michael 02:33, 20 December 2007 (CET)
[[Issue:Article count is wrong|Article count is wrong
I have a mediawiki site at superdelegates.org. Its goal is to track superdelegate endorsements in the US Democratic presidential race, and having a dynamically updated list of the number of endorsements was my goal - DPL seems to be perfect for this goal.
I installed the extension without a problem, and it's returning results. The problem is that it's returning the wrong number of articles in one of the categories. (The other two categories are properly counted.) You can see here where DPL says there are 107 articles in the category "Delegates who have endorsed Hillary Clinton". The problem is that if you click through to that category, you'll see that there are 260 articles in that category.
Have I done something wrong? Is there something I need to do to ensure DPL returns the proper article count?
Thanks,
Rick
[[Issue:Add a template in the pages automatically by DPL|Add a template in the pages automatically by DPL
Hi Gero.
Could it be possible that we can add DPL query in a template page. Then, the pages which match the DPL query will include the template into themself.--Roc michael 00:42, 9 May 2008 (CEST)
[[Issue:AiSee crash due to several near edges|AiSee crash due to several near edges
The following graph definition causes a memory violation:
graph: {
title: "A"
rightnearedge: { source:"A" target:"B" }
leftnearedge: { source:"A" target:"C" }
rightbentnearedge: { source:"A" target:"D" }
}
There are more constellations which have the same effect. The following piece of php code tries to identify all dangerous constellations:
foreach ($edges as $edgeId => $edge) {
$n=$ln=$rn=$b=$lb=$rb=0;
$edgeKind = $edge['kind'];
if ($edgeKind == 'near') $n++;
else if ($edgeKind == 'leftnear') $ln++;
else if ($edgeKind == 'rightnear') $rn++;
else if ($edgeKind == 'bentnear') $b++;
else if ($edgeKind == 'leftbentnear') $lb++;
else if ($edgeKind == 'rightbentnear') $rb++;
foreach ($edges as $nEdgeId => $nEdge) {
$from = $edge['source'];
if ($nEdgeId <= $edgeId || $nEdge['source'] != $from) continue;
if ($nEdge['target'] == $edge['target']) {
$this->error("near edges at '$from' point to the same other node '".$edge['target'],'');
}
$nEdgeKind = $nEdge['kind'];
if ($nEdgeKind == 'near') $n++;
else if ($nEdgeKind == 'leftnear') $ln++;
else if ($nEdgeKind == 'rightnear') $rn++;
else if ($nEdgeKind == 'bentnear') $b++;
else if ($nEdgeKind == 'leftbentnear') $lb++;
else if ($nEdgeKind == 'rightbentnear') $rb++;
//$this->parser->errorText .= "checking $edgeKind edge $edgeId against $nEdgeKind edge $nEdgeId at $from: $n,$ln,$rn $b,$lb,$rb:\n";
if (($rn+$ln>=2 && $rb+$lb>=1) ) $this->error("too many near (bent) edges at '$from'",'');
}
}
[[Issue:Allow multiple surrogate templates, add/change syntax|Allow multiple surrogate templates, add/change syntax
I would like to be able to pass arguments/parameters from more than one template invocation that is on a page and format the output using a single template. If the parameters of the included templates have the same name, there could be a way to recognize from which template they came or if that's not possible, then the last parameter of the same name should override prior calls. I think this works best by adding a new syntax (I don't like the current syntax to begin with since it forces you to have surrogate templates with extra long and possibly confusing names). My suggestion is as follows:
{{#dpl:category=<category forming a list of articles to reference>
|passfrom={template1},{template2},{template3},...
|passto={templateX}
|passdefault={templateY}
}}
This would help when some parameters you want are on a page's infobox template invocation and some parameters are on the navbar template invocation. Also, it could allow you to use the same template for multiple purposes, and not just to receive a surrogate call from a single DPL template.
[[Issue:Articlecategory doesn't work in 1.6.8|Articlecategory doesn't work in 1.6.8
This example produces no output on MediaWiki 1.11.x and 1.12.0 on Windows 2003 Server.
<dpl> namespace = Talk articlecategory = My category </dpl>
even if there are articles in "My category" that have talk pages. I would expect to see a bulleted list of all Talk pages whose main article is in "My category".
This problem exists in DPL 1.6.5 as well.
This is with PHP 5.2.5 and Apache 2.2.8 and mySQL 5.0.45-community-nt-log.
[[Issue:A problem in the conbination DPL 1.7.4 and MW1.3 using Chinense interface|A problem in the conbination DPL 1.7.4 and MW1.3 using Chinense interface
Hi Gero.
Following code can work fine in MW1.13 with English interface (using $wgLanguageCode = "en"; in the Localsetting.php ):
{{#dpl: namespace=Category | format=,\n*%TITLE%,,}}
But if I change $wgLanguageCode = "en"; to $wgLanguageCode = "zh-tw";, the result of the code above will change to following:
%DPL-1.7.4-??: ??? '$0' ??: 'namespace'! ??: $0= ???? (?)?
[[Issue:Arbitrary adding of empty paragraph|Arbitrary adding of empty paragraph
I noticed a very strange behavior of DPL (1.8.9) on one of my wikis. The following tag version always produces an extra empty paragraph between the heading and the list, whereas the parser function does work alright, even with all those whitespace added to it. On my test installation (same provider, version - 1.15.3) both versions fail!
== DPL Test - Tags == <dpl>category=Dateiformate</dpl>
== DPL Test - Parser Function ==
{{#dpl:
| category = Dateiformate
}}
I wonder if anyone else has noticed a similar behavior and has an idea what might be the cause.
I have already had a look at Issue:DPL extension inserts a blank line headline but think this problem is unrelated.
tia Frank
- I have the same issue (I think). The dpl works fine, but a blank line is added at the beginning of the list. I noticed this when I tested some functions with StringFunctions to replace some characters from the list produced by my DPL query. It works OK on my MW1.15.1 installation which used DPL version 1.7.6. However, the same statements failed on MW1.16 with DPL 1.8.9.
- The only difference is that DPL 1.8.9 produces the extra blank line. I have not yet tried the BOM removal procedure described elsewhere, but will do so and report back.
[[Issue:Asking a calendar kit|Asking a calendar kit
Could you give me a more useful calendar with using DPL like the description. The date format of the extension is not good for DPL now. We can use it with Preloader Extension if it can create new pages with a specific namespace.--Roc michael 16:55, 1 December 2007 (CET)
|}</nowiki></pre>
