Difference between revisions of "DPL:Requests for new features"

From FollowTheScore
Jump to: navigation, search
(Temporary Code)
 
(138 intermediate revisions by 17 users not shown)
Line 1: Line 1:
__TOC__
+
----
 +
<big>
 +
This page is no longer in use. If you think one of the issues mentioned below is still relevant, go to [[:Category:Issue]] and create a new Issue (with type=''Change Request'' and status=''open'') there.
 +
</big>
 +
----
 +
 
 +
 
 +
__TOC__ __NEWSECTIONLINK__
 +
 
 +
::''Old requests (which have been resolved) can be found in the [[DPL:Requests for new features Archive]].
 +
----
 +
<!-- Please do not add/edit above this line ----------------------------------------------------------->
 +
 
 +
 
 +
==Include other wiki pages==
 +
I want to include parts of Wikipedia articles on my wiki. Can DPL be expanded to do this? -[[User:Eep²|Eep²]] 10:22, 20 August 2007 (CEST)
 +
 
 +
:I don´t think so. Every wiki has its own categories, templates, images,.... So just transcluding the raw text (if it is available via &action=view) would not make much sense. And transclusion of rendered html text is not possible nor desirable either. [[User:Gero|Gero]] 14:28, 20 August 2007 (CEST)
 +
 
 +
::And yet many websites (like http://encyclopedia.thefreedictionary.com/) do it all the time without any apparent problems (and there's even a [http://dev.wp-plugins.org/wiki/GetWIKI WordPress plugin])... All I really want to pull in is the first paragraph; I don't need templates, categories, or even images. Links can obviously be pulled in easily enough that go to the correct place (Wikipedia or external links). See http://www.killertux.com/pages/Wikipedia_Simple_API.php?q=node/44 too for a "screen scraper" with PHP code you may be able to implement in DPL. -[[User:Eep²|Eep²]] 15:19, 20 August 2007 (CEST)
  
::''Please add requests for new features <font color=red> to the beginning</font> of this document. If possible make syntax suggestions and give an example for the desired behaviour!''
+
:::Using the killertux API you can yourself include a whole wikipedia article into your wiki (as html or text). I can´t see what DPL should do in that context. DPL cannot and will not parse such scraped contents. You would have to build a completely separate and different mediawiki extension for that purpose. [[User:Gero|Gero]] 20:17, 22 August 2007 (CEST)
  
::maybe we should move the ''[[Test calendar|calendar application]]'' to a separate article ?
 
 
 
.
 
.
 
.        The following requests are  O P E N
 
.
 
.
 
  
 +
== Most active page? ==
 +
ordermethod=activity
 +
 +
Most number of edits or biggest diffs in the last t units of time???
 +
 +
--[[User:Dmb|Dmb]] 18:11, 10 August 2007 (CEST)
 +
 +
:The sheer number of edits is not very meaningful; and as soon as 'significance of change' comes into play, I see no way to implement such a feature without having to calling diff3 on every document. And that is definitely too resource consuming. [[User:Gero|Gero]] 14:55, 15 August 2007 (CEST)
 +
 +
== Add 'contributors'? ==
 +
 +
addcontributors = TRUE
 +
contribthresh = x Kb
 +
 +
Instead of listing one page author or the last editor, addcontributor would add the users who had made significant diffs to the article, where significant is determined by contribthresh. The multiple names are listed separated by commas.
 +
 +
Woop!
 +
 +
--[[User:Dmb|Dmb]] 18:11, 10 August 2007 (CEST)
 +
 +
That´s a pretty good idea. Maybe I will add that somewhen. [[User:Gero|Gero]] 23:56, 10 August 2007 (CEST)
 +
 +
I also thought of another idea... List users by total contrib size. Its a bit 'lets see who has the biggest penis' - but could be useful to see who has contributed most to a certain page or category. --[[User:Dmb|Dmb]] 08:21, 14 August 2007 (CEST)
 +
 +
:After some investigation I feel that it would be very slow and resource consuming to build that feature. '''If somebody can come up with a SQL statement''' which delivers the basic data we want to show: fine (I don´t know how to do it with pure SQL). Otherwise one would have to call diff3 for each document. That´s a show stopper. [[User:Gero|Gero]] 14:52, 15 August 2007 (CEST)
 +
 +
:: Hello Gero, and sorry for taking so long to reply. Here is the SQL that I have come up with. I think that it does the job (more or less).
  
== Inverting "includematch" ==
 
=== Question ===
 
It is easy with regex to match pages "which contain some word".(ie. /.*abc.*/s -> page which contain word "abc").
 
But it become complicated for generating list of "which page which doesn't contain word 'abc'".
 
=== Proposal ===
 
How about adding new parameter "excludematch". So we can specify like
 
 
<pre>
 
<pre>
includematch=/.*abc.*/s
+
SELECT
excludematch=/.*def.*/s
+
  rc_title, rc_cur_id, rc_user_text, rc_user,
 +
  GROUP_CONCAT(rc_new_len - rc_old_len) AS DEBUG,
 +
  SUM(ABS(rc_new_len - rc_old_len)) AS CONTRIB
 +
FROM
 +
db_prefix_categorylinks  cl
 +
INNER JOIN
 +
  db_prefix_recentchanges rc
 +
ON
 +
  cl.cl_from = rc.rc_cur_id
 +
WHERE
 +
  cl_to='Some_category'
 +
GROUP BY
 +
  rc_cur_id, rc_user
 +
;
 
</pre>
 
</pre>
which should result a list of pages that contain word "abc" but doesn't contain word "def".
 
=== Temporary Code ===
 
For some one who need quick resolution, I just put some code here: [[:Image:20070718 DynamicPageList2.zip|Invertion of includematch]].
 
Cause this is a quick fix, rather than adding new parameter (excludematch), it work with special char preffix. For the sample on proposal, used this instead
 
<pre>
 
includematch=/.*abc.*/s,~/.*def.*/s
 
</pre>
 
The character "~" will convert the meaning of includematch to "which doesn't match".
 
(BTW it also include a temporary fix for counter. see "List Counter doesn't work correctly" on [[DPL:Bug Reports Archive]])
 
  
== Add a parameter to SpecialPage to just show the output (without the DPL edit window)==
+
Using the above we get to see which user has done the most 'editing' of a page in the given category. The notion of 'editing' implemented above is quite crude, but I can't think of any better systematic way to do it (SQL or otherwise). The contributors option would take a threshold parameter to delineate the valid list of 'significant contributors' - that parameter could even be a fraction of the page size! Anyway, lemmy know if this is what you were looking for, and if not why not.  
===Request===
+
 
*The functionality below is great to insert links to the DPL special page, but it lacks an option for "dummy" users that just click on the link and want to see the output, not the DPL edit window.
+
Thanks for the brilliant extension!
*A parameter just for the SpecialPage called "showDPLeditbox" would help getting that to work. Here is a fast crack at the functionality, but I am not really a PHP guy:
+
 
<pre>
+
P.S. I wonder if we could apply a modified version of the above to look at the 'most active pages' request above?
$edit = 1;
+
 
$wikitext .=      $wgRequest->getText('wikitext1') ? $wgRequest->getText('wikitext1') : str_replace( "&&", "\n", $par );
+
::--[[User:Dmb|Dmb]] 13:53, 14 September 2007 (CEST)
    $wikitext .= "\n".$wgRequest->getText('wikitext2');
+
 
    $wikitext .= "\n".$wgRequest->getText('wikitext3');
+
==Table row/column header switch==
    $wikitext .= "\n".$wgRequest->getText('wikitext4');
+
Can the table headers be used as the beginning of rows instead of at the top of columns? I would like to duplicate my [http://tnlc.com/eep/compare/table.html game comparison table] and need this functionality. -[[User:Eep²|Eep²]] 05:43, 29 July 2007 (CEST)
    $wikitext .= "\n".$wgRequest->getText('wikitext5');
+
:Please give more details: How should the new switch be named, which values be allowed? In which modes should it have an effect and how should the result be affected?
    $wikitext .= "\n".$wgRequest->getText('wikitext6');
+
:For information: There will be no changes to the DPL sources within the next three weeks. [[User:Gero|Gero]] 08:13, 29 July 2007 (CEST)
    $wikitext .= "\n".$wgRequest->getText('wikitext7');
+
 
    $cmds = split("\n",$wikitext);
+
::I'm not a programmer, Gero...I just have ideas and what I want to do programmatically that I can already do (and have done for years) manually. Perhaps creating a "table" mode that deals with all table-related parameters like <tt>header</tt> (and <tt>column</tt>/<tt>row</tt> types). <tt>resultsfooter</tt> could have an option to be the last row or column of the table and include parameters for totals of a specific header (# articles in table, etc), a number field (like a "sum" function), etc. <tt>cellseparators</tt> could be used instead of <tt>listseparators</tt> (or at least as an alias) and. of course, support for specifying normal/regular non-suffixed template fields. Essentially, DPL needs more table-specific support to move it beyond just lists, per se. -[[User:Eep²|Eep²]] 08:28, 29 July 2007 (CEST)
    $wikitext='';
+
 
    foreach ($cmds as $cmd) {
+
:::Still need this too... -[[User:Eep²|Eep²]] 05:40, 11 September 2007 (CEST)
    if ($cmd=="") continue;
+
 
    if (preg_match('/=\?/',$cmd)) continue;
+
==Template field output==
    if (preg_match('/^debug/',$cmd)) $wikitext=  $cmd."\n".$wikitext;
+
Is it possible to output the unescaped wikimarkup (so it actually works as on pages that use the template) in DPL output? I want to create a DPL table that has same links as articles do that use the template in them which is also called in the DPL table. -[[User:Eep²|Eep²]] 06:56, 26 July 2007 (CEST)
    if (preg_match('/^noeditbox/',$cmd)) $edit=0;
 
    else     $wikitext .= $cmd."\n";
 
    }
 
        $action = $mytitle->escapeLocalUrl();
 
    if ($wikitext) {
 
    $wgOut->addHtml("<table><tr><td>\n");
 
    if ($edit) {
 
        $wgOut->addHTML("<form method='post' action=\"{$action}\">" .  
 
                        "<textarea rows=8 name=wikitext1>$wikitext</textarea>" .
 
                        "<input type='submit' value='" . wfMsg('dpl2_createreport')."' >" );
 
$wgOut->addHtml("&nbsp; &nbsp; <a href=../index.php/Special:DynamicPageListSP>reset</a>" .
 
                        "</form>\n"); }
 
</pre>
 
  
=== Reply ===
 
A good idea. It will find its way into Release 1.2.2. [[User:Gero|Gero]] 00:12, 22 June 2007 (CEST)
 
  
== Invoke SpecialPage with Multiple Parameters ==
+
==User-friendlines==
=== Request ===
+
[[DPL talk:Manual - DPL Special Page with Parameters#User-friendliness]] -[[User:Eep²|Eep²]] 11:42, 25 July 2007 (CEST)
You might consider integrating the patch I propose in [[DPL:Manual - DPL Special Page with Parameters]].
 
  
=== Reply ===
 
Thank you for this good idea! Your proposal will find its way into the next release. [[User:Gero|Gero]] 08:31, 26 May 2007 (CEST)
 
  
 
== Be PostgreSQL compliant ==
 
== Be PostgreSQL compliant ==
Line 87: Line 106:
 
I'd be curious if you consider this a feature request or a bug report&hellip;
 
I'd be curious if you consider this a feature request or a bug report&hellip;
  
== Returning categories only ==
 
=== Request ===
 
Somewhat related to the "Multiple columns with headingmode" question: I would like to be able to return only the categories that a set of pages belong to and not the pages themselves. That is, I would like to get behavior similar to ordermethod=category,sortkey and headingmode where all the categories that a set of pages is returned as the list itself (and the pages thrown away). Ideally, it would be possible to format the list of categories returned. Perhaps if a headingmode=userformat was created, that would be sufficient as you could throw away the rest of the data with mode=userformat without a defined listseparators. (Example application: Of all pages in a certain given category, what are all the other categories those pages are in?)
 
 
=== Answer ===
 
This is really a very interesting idea! Although it adds another portion of complexity to the code of DPL I tried to implement this feature. By setting "goal=categories" you state that you are going for a result which consists of the category set which is referenced by the pages this report would normally produce. I hope this is a very elegant solution as it allows you to use most of the existing selection criteria to define the (intermediate) page set which is then used to look for the categories. Some options do not make sense in that context but modt of them still are applicable. What do you think about this approach? Could you please test it (release 1.1.8)?
 
:[[User:Gero|Gero]] 10:53, 12 May 2007 (CEST)
 
 
* Looks good! I've been able to successfully nest calls to DPL (e.g. return the categories for a set of pages and then pass those categories back into another DPL call). Thanks. --Austin
 
 
== Multiple columns with headingmode ==
 
===Request===
 
Maybe this is doable already but I couldn't figure it out: I want to use ordermethod=category,sortkey and headingmode but I want it in multi-column form (or have more user control regarding the output format). There's a column parameter but it doesn't seem to work with headingmode. Another possibility is if I could use mode=userformat and somehow simulate the behavior of multi-column headingmode. I realize that the columns might not be all the same length as there could be different number of pages in each category. I think the simplest implementation would be to put one category heading in each column and ignore the list under each category.
 
 
== Test against MW 1.10 ==
 
=== Request ===
 
MW 1.10 is just out. Is there a way that this website gets upgraded so that DPL supports the latest MW version ?
 
  
 
== rss feed from dpl ==
 
== rss feed from dpl ==
Line 128: Line 130:
 
That should certainly help with the details. Unfortunately I cannot do the integration myself or I would happily do it immediately. Thanks for the brilliant product and keep up the good work! --[[User:Dmb|Dmb]] 11:24, 1 June 2007 (CEST)
 
That should certainly help with the details. Unfortunately I cannot do the integration myself or I would happily do it immediately. Thanks for the brilliant product and keep up the good work! --[[User:Dmb|Dmb]] 11:24, 1 June 2007 (CEST)
  
==Create a special page for searching pages with DPL==
+
=== nudge ===
===Request===
+
Rss rss rss rss rss rss!!!
*It could be interesting to have a special page that does a search based on a DPL. The DPL parameters would be set in a form (that could be enhanced in time with some common values).
 
*The current search functionality in Mediawiki is quite limited, and DPL adds much power here.
 
*Example: I want all the pages edited by user X in category Y and category Z, etc...
 
*This is just a random idea, as I sometime had to query by editing a page and doing a preview without saving. Being able to do a DPL search and get a result set on a page without having to edit a page would be nice.
 
--[[User:Ycombarnous|Ycombarnous]] 14:55, 10 April 2007 (CEST)
 
===Reply===
 
*I created the base frame for such a "specials" page. But I will not have time to work on it. See the source archive, and feel free to start coding. -- [[User:Gero|Gero]] 19:44, 21 April 2007 (CEST)
 
  
*I know it's quite a lot of work. I will try and make a static proposal for the page, and work on it as time allows. thanks. --[[User:Ycombarnous|Ycombarnous]] 10:32, 23 April 2007 (CEST)
 
 
* I also thought this would be useful so I implemented something very simple and more general. It's a special page that is a generic wikitext parser (and so works with DPL and any other parser extension). It lets you bookmark a link to a search query via DPL for example. See [http://openwetware.org/wiki/Special:Parse here] for an example. The source code is [http://openwetware.org/wiki/User:Austin/Extensions/SpecialParse here]. --Austin
 
 
----
 
 
* This looks interesting, Austin! Maybe we can build a simple solution based on your extension --Gero 20:17, 26 April 2007 (CEST)
 
 
* Well, there is a first trial version of DPL-special-page available with version 1.1.4. I started with the code from Austin and added my ideas. Have a look! --Gero 14:48, 30 April 2007 (CEST)
 
 
----
 
 
* It's a good start, but I was actually thinking more to someting like Bugzilla boolean charts (go to a bugzilla install, in "advanced search", and see the section at bottom (called Advanced Searching Using Boolean Charts). Basically, you have per line:
 
**the field you want to set a value on
 
**the type of matching you look for (would correspond to match / in / not in for DPL)
 
**and finally your value
 
**in addition, you can add as many lines as you want
 
*It would require some javascripting telling for each field the corresponding matching available, plus if several lines use the same field with different criteria, a concatention would be needed. What do you think? --[[User:Ycombarnous|Ycombarnous]] 17:07, 30 April 2007 (CEST)
 
 
::What you described would certainly be a much better way to implement it. I was only looking for a "developer´s help tool" which offers the big variety of available parameters and allows a quick trial&error-cycle. I will not find time to do anything beyond that, I´m afraid.
 
::Gero 20:10, 2 May 2007 (CEST)
 
 
=== Simple Forms extension ===
 
[http://www.mediawiki.org/wiki/Extension:Simple_Forms Extension:SimpleForms] can work very well with DPL, it's still under development, but the DPL example on the page works and is a basis for making more complex query forms/reports. [http://www.organicdesign.co.nz OrganicDesign] main page shows the example working. --[[User:Nad|Nad]] 03:31, 29 April 2007 (CEST)
 
  
 
== display Table of Contents for an article ==
 
== display Table of Contents for an article ==
Line 167: Line 138:
 
the incudepage feature could be enhanced to include the TOC only; a %TOC% variable would ebe useful ...
 
the incudepage feature could be enhanced to include the TOC only; a %TOC% variable would ebe useful ...
  
 +
==Putting delimiters between results==
  
==PostgreSQL==
+
::Will this solve a related formatting problem - putting delimiters only ''between'' results? Ideally I'd like to have a single result returned inline, but multiple results in an ordered list. It could be I misunderstood the documentation, but there doesn't seem to be a way to avoid a leading bullet or whatever in a list. [[User:Frank|Frank]] 14:35, 20 August 2007 (EDT)
does not work on PostgreSQL. maybe there's somebody here who can and is interested in adding of postgresql support... [[User:89.178.255.5|89.178.255.5]] 04:30, 24 March 2007 (CET)
 
  
 +
::: There is a mode called 'inline' which does what you want. You can define the 'inline' tag contents. [[User:Gero|Gero]] 07:50, 10 September 2007 (CEST)
 +
:::{{#dpl:category=Country|mode=inline|inlinetext= &nbsp; my separator &nbsp;}}
  
 +
== Hook based data exchange between extensions ==
 +
Would it be possible to add a 'hook' (i.e. wfRunHooks) to DPL? Once a 'query' is finished executing, the result could be signaled to other interested extensions. A 'context id' would be required as potentially many queries could co-exist on the same page. I would suggest adding a parameter such as 'context=' OR just a linear incremental counter.
  
.
+
A 'no output' option would be great also - this way, if the query is really meant to be consumed by another extension, the user isn't distracted by the result from DPL directly.
.
+
[[mw:user:jldupont]]
.        The following requests are  C L O S E D
 
.
 
.
 
  
 +
=== Reply ===
 +
I do not have experience with creating hooks. There is a point in the code where the sql result set is ready. But be warned: The columns contained in the result set may vary depending on the options used. Generally speaking, DPL is a beast that has reached its saturation level of complexity ;-). I would more be in favour of a way where DPL produces some kind of csv output which is then fed into another extension. With '''mode=userformat''' this is fairly easy because you have '''complete control''' over the output. You can create csv or whatever format suits your own extension. This need not be wikitext nor need it be html or plain text - any kind of grammar is possible. For example you can use the result of one DPL statement as a parameter for another one, i.e. you can ''nest DPL calls''. There is a good example for this: [[Wgraph:Example 4]]. Here the inner DPL query produces a pipe-separated list for the outer one.
  
== Add option to allow caching ==
+
So, the 'no output' you are looking for is already there. It´s called mode=userformat -- and it will take you some time to understand its power. Being the author I am still myself learning what you can do with DPL ;-)
=== Request ===
 
I'd like to use DPL to build a lot of my page content without incurring as much of a performance hit with regards to caching. Since my generated content will rarely need to be updated (compared to many many views), it would be really nice if I could somehow keep page caching on and rely on action=purge to update the lists when needed.
 
 
 
My request/suggestion is to add something like an "allowCachedResults=true" option that simply causes DPL to skip any calls to disableCache for that particular tag evaluation.
 
 
 
=== Question ===
 
There is only one call to parser->disableCache() and it is easy to switch it off via some parameter setting. But how can I test that it works? Which settings do you use in your LocalSettings.php? When I manually deactivated that call I could not see a faster delivery of normal pages, so I guess currently there is no caching in the dpldemo repository at all. What would one have to do to ENABLE caching? Gero 17:11, 30 April 2007 (CEST)
 
:This site seemed to have caching on when I did some testing earlier. With this kind of change, you should be able to test by getting it to render outdated results versus up-to-date results. Have a page that uses DPL to list all articles that are in Category:Test, with "allowCachedResults=true". Then modify some other random page to add it to Category:Test, and view the first page again. If the cache is not disabled nor invalidated, you should see the outdated list without the additional page, and doing action=purge should give the up-to-date list. If it still appears that the cache is disabled, here are some things to check:
 
:*Go to [[Special:Preferences]]->Misc and make sure that "Disable page caching" is unchecked, or just log out of your user account while testing.
 
:*Make sure that your first page is not doing anything else that would naturally disable its caching (making other DPL calls without allowCachedResults=true, transcluding other pages with disabled caching).
 
 
 
=== Resolved ===
 
Now there is such an option and it works as explained above. Gero 20:06, 2 May 2007 (CEST)
 
  
 +
The problem of multiple contexts is also solved by extension nesting. Maybe you do a little exeprimenting and then come up with another comment?
 +
:[[User:Gero|Gero]] 21:05, 24 July 2007 (CEST)
  
==Include for a template could let you choose a single parameter to extract from the template==  
+
== DPL API ==
===Request=== 
 
Re-injecting a template inside another template is great, but sometimes cumbersome if all you need is one parameter from the template. Couldn't there be just a simple way to extract '''ONE''' parameter from a template, without having to create a template a do so? 
 
===Reply=== 
 
This is available with version 1.1.4. You can use "include={template}:name" or "include={template}:number" --Gero 13:59, 30 April 2007 (CEST)
 
  
 +
I'd like to see more of an API structure to the code.  The [[DPL:Manual|manual]] lists all the parameters and groups them by functionality, but no such break-up exists in the code (at least not that I could tell).  At minimum, I'd like there be one function that processes the search criteria to get the results or groups of results in the form of an array of Title objects (or an array of arrays of title objects), and another function to display the results in a specified or default format.
  
== suggestion: cleaner way to implement wfDynamicPageList4() ==
+
I'd like to be able to build my own extension that uses the DPL2 extension as an API without having to hack the DPL2 code—[[User:Sledged|Sledged]] ([[User talk:Sledged|talk]]) 01:03, 10 September 2007 (CEST)
=== Request ===
 
The function wfDynamicPageList4() is preceded by this comment:
 
 
 
// enumerating a fixed list of 20 parameters looks awkward but there seems to be no other way
 
function wfDynamicPageList4(&$parser, $p1='' ,$p2='' ,$p3='' ,$p4='' ,$p5='' ,$p6='' ,$p7='' ,$p8='' ,$p9='' ,$p10='',
 
                              $p11='',$p12='',$p13='',$p14='',$p15='',$p16='',$p17='',$p18='',$p19='',$p20='') {
 
 
 
In fact, there is a better way. :) http://us2.php.net/manual/en/function.func-get-args.php
 
 
 
Maybe this is all you need?
 
  function wfDynamicPageList4(&$parser)
 
{
 
$params = array();
 
$input='';
 
 
$numargs = func_num_args();
 
if ($numargs < 2) {
 
  $input = "#dpl: no arguments specified";
 
  return str_replace('§','<','§pre>§nowiki>'.$input.'§/nowiki>§/pre>');
 
}
 
 
// fetch all user-provided arguments (skipping $parser)
 
$arg_list = func_get_args();
 
for ($i = 1; $i < $numargs; $i++) {
 
  $p1 = $arg_list[$i];
 
  $input .= str_replace("\n",'',$p1) ."\n";
 
}
 
// for debugging you may want to uncomment the following statement
 
//return str_replace('§','<','§pre>§nowiki>'.$input.'§/nowiki>§/pre>');
 
return DynamicPageList( $input, $params, $parser );
 
}     
 
 
 
[[User:Madkangas|Madkangas]] 03:01, 26 April 2007 (CEST)
 
  
 
=== Reply ===
 
=== Reply ===
Thank you very much! Help on the code is most welcome. Your suggestion will become part of the next release.
 
:Gero 20:10, 26 April 2007 (CEST)
 
 
 
==Statistics: Count articles in category or template inclusions==
 
===Request===
 
Instead of listing the articles a simple counter would be helpful sometimes. Similiar to <nowiki>{{NUMBEROFARTICLES}}</nowiki>, but customisable. Example: "There are XX articles in Category:Example". This might be nice for statistics. I don't know if that's not already possible somehow. --[[User:Matthias|Matthias]] 15:54, 21 April 2007 (CEST)
 
===Reply===
 
I think you can do that already: See [[Test numberOfArticles]].
 
--[[User:Gero|Gero]] 19:21, 21 April 2007 (CEST)
 
  
==Including sections by number==
+
Why don´t you just go ahead with DPL as it is? You can put any call of a parser function into the output loop of DPL. And you can use DPL in a way that it does not produce any single byte of output on its own. You can easily create ''title objects'' within your code from the first parameter which is passed to ''my working template''. You might say that this is less efficient than an integration on php level but before trying to optimize you could build your extension right now without any change to DPL and without any code interference. '''What kind of application do you have in mind, by the way?.'''
===Request===
+
For example:
It would be useful if the includepage option could take a numbered section instead of a labeled section. That is, I might have a page where I don't know the name of the sections (and they aren't labeled) but I want to get a particular section (probably most commonly either the first or the last section).
 
===Reply===
 
Does it really make sense to show the 3rd paragraph of an article without even knowing the name of the headline?
 
How should we count? Only level-2-headings? Or would we have to use TOC numbering like "3.4.7"? I doubt such a featrue would make a lot of sense as it would be very unstable in case somebody inserted a chapter somewhere in the article.
 
Note that for example something like
 
 
<pre><nowiki>
 
<pre><nowiki>
<dpl>
+
{{#dpl:
   category=xyz
+
   |resultsheader=²{my envelope template¦%PAGES%}²
   include=*
+
   |category=some category
   includemaxlength=300
+
   |namespace=some namespace
   mode=userformat
+
   |... etc
   listseparators=,\n=[[%PAGE%]]=\n,,,
+
   |format=,²{my working template¦%PAGE%¦%TITLE%}²
</dpl>
+
}}
 
</nowiki></pre>
 
</nowiki></pre>
will give a list of articles together with the first 300 characters of each article.
 
:--[[User:Gero|Gero]] 19:42, 21 April 2007 (CEST)
 
 
* Here's a concrete example of the use for this feature. Suppose you have a discussion page or even easier consider this very page with requests. Suppose you wanted to return the newest feature request (so basically the section at the top). You might have a lot of pages like this one and you want to have a page that shows the newest requests (first section) from across many pages. How can you do that without knowing what the name of section is (you can't predict what people will want to request)? You could have a label but then anytime someone added something, the label would have to be moved manually. In terms of specifying a section and levels, I would envision the easiest would be to use what MediaWiki already does. It appears to collapse all section levels and just count from the top. For example, if you hit the edit section link and look at the wpSection value, that's how the sections appear to be counted (also see the function Parser::getSection()). Returning the first n characters from a page might work in some cases but doesn't necessarily directly solve the example problem above. For example, even if the newest request was directly at the top of the page, if the newest request is < 300 characters, you only want to return that section rather than the first 300 characters of the page. So in terms of syntax, I'd think something like includepage=%1,%2 to include the first 2 sections of a page would be the simplest and most straightforward.
 
 
::I am still not fully convinced - but you should have your chance ;-), Version 1.1.2 provides that feature, see the manual and [[Test include sections by number]]. Now it is up to you to come up with a brilliant website ... --Gero 21:57, 23 April 2007 (CEST)
 
 
 
==Subcategories==
 
===Request===
 
Not sure if this is possible with DPL or not. On my wiki, I've used DPL to create lists on city pages:
 
http://mographwiki.net/Category:Melbourne
 
(You can see it lists "Companies" and "Freelancers"). I'd like to do the same thing for countries listing
 
all the Companies and Freelancers in that country. For this to work, I'd need a list that requires the pages to be in a certain category (like Companies)
 
and also be in a category which is a subcategory of the country in question (for example, Melbourne is a
 
subcategory of Australia). Any ideas? Thanks!--[[User:Weakmassive|Weakmassive]] 00:46, 17 April 2007 (CEST)
 
 
===Question===
 
Could you - in principle - achieve your result by listing all the subcategories of Australia as an alternative besides Australia, i.e. "category=Australia|Sydney|Melbourne|Adelaide"? If the answer is yes one could maybe create a new option which explodes a category tree branch and replaces the name of the parent by the "parent plus all its children plus its (grand-)children etc.". --[[User:84.58.225.63|84.58.225.63]] 23:11, 17 April 2007 (CEST)
 
::Ya, adding all the subcategories would achieve the same result - only lots more work. Your idea sounds like it would work, if someone could write it up. Thanks.--[[User:Weakmassive|Weakmassive]] 23:53, 17 April 2007 (CEST)
 
 
===Simple (preliminary) Solution===
 
As a quick solution I added the "*" to category=; see the manual. The "*" currently covers only ONE level of hierarchy. More is hard to do ...<br>
 
Please let us know if it works.
 
--[[User:Gero|Gero]] 22:08, 18 April 2007 (CEST)
 
 
::Awesome, thanks for adding that. I initially had problems with using "magic words" but figured out that you need to use the parser function syntax. All is well! Thanks again.--[[User:Weakmassive|Weakmassive]] 00:28, 19 April 2007 (CEST)
 
 
 
==Allow caching when using the title parameter==
 
===Request===
 
Is it feasible to avoid invoking disableCache whenever the title parameter is used? (and rely on the cache being invalidated when the transcluded page is edited) --[[User:24.6.249.241|24.6.249.241]] 21:45, 14 April 2007 (CEST)
 
===Reply===
 
An interesting suggestion. I uploaded release 1.1.0 which disables the cache only if 'title=' is NOT set. Could you please report your experience? I do not understand enough about mediawiki caching to make a thorough test.
 
 
--[[User:Gero|Gero]] 06:52, 16 April 2007 (CEST)
 
 
:I am no expert myself, but it seems correct to me after reviewing mediawiki caching code. Basic testing also works as expected so far. --[[User:64.186.172.227|64.186.172.227]] 22:58, 16 April 2007 (CEST)
 
 
 
==Returning non-existing pages==
 
===Request===
 
I would like an option to return pages that don't necessarily exist. For example, via linksfrom=Mypage. If Mypage has a wikilink to a non-existing page, the pagelinks table contains that link information but DPL does not return it because it does a join with the page table.
 
===Response===
 
Now we have a new parameter called "openreferences". If set to "yes" a "linksfrom" will also show open references. Due to the missing target page we do not perform a join; as a consequence, however, there are several restrictions on which other parameters can be used together with this new option. See [[Test linksfrom]].
 
:[[User:Gero|Gero]] 18:53, 11 April 2007 (CEST)
 
 
==General inversion==
 
===Request===
 
Is there a reason there isn't a notlinksfrom option (there's a notlinksto and I would assume it'd be basically the same)? More generally, why isn't there a 'not' version for all of the selectors? The main other one I don't see is nottitle (I can certainly imagine cases where I want to exclude a specific page).
 
===Reply===
 
Of course the concept of negation is general.
 
# The 'notlinksfrom' option is indeed missing. It will be supplied in one of the next releases (1.0.8).
 
# The 'title' option is different. We already have 'nottitlematch' and 'nottitleregexp' which allow to exclude articles based on simple name matching or even based on regular expressions. The 'title' option is a very special thing which allows DPL to be used as a (more flexible) substitute for another mediawiki extension named LabeledSectionTransclusion. See the description in the [[DPL:Manual - DPL parameters: Criteria for page selection#title|manual]].
 
:[[User:Gero|Gero]] 06:49, 9 April 2007 (CEST)
 
 
==Extend the uses parameter to article headings and sections (like include)==
 
===Request===
 
It would be nice to be able to extend the "uses" criteria for page selection to whether or not an article contains a specific heading or section (lst). Another way would be to have a parameter that would be a strict about "includepage": if any of the required inclusions are missing, do not select the page. --[[User:Ycombarnous|Ycombarnous]] 12:03, 30 March 2007 (CEST)
 
 
===Answer===
 
There is an experimental new feature which allows to define regular expressions which must match included contents (parameter ''includematch''). Please test and report your experience. Which behaviour would you expect if a page contained multiple chapters with identical name and only some of them match the condition? What happens if a chapter does not appear at all in the included page? Currently a regexp is applied to the OUTPUT of the DPL template (if you use template based inclusion). Would it be better to match the input (i.e. the calling location in the source file)?
 
 
--[[User:Gero|Gero]] 23:02, 31 March 2007 (CEST)
 
 
== Template variable value filter ==
 
 
I think this one is hard to code, but here is what I would need:
 
  
On the [[interface list]] I would like a filter "Quellsystem=SAP", all other lines are not of interest.
+
--[[User:Gero|Gero]] 07:28, 10 September 2007 (CEST)
  
Today I am using categories, which works fine, but this would be more flexible. --[[User:GunterS|GunterS]] 15:47, 30 March 2007 (CEST)
+
:I've been toying around with DPL a bit with some of the examples on this site, and I see now that it can do what I want it to do.  Excellent!  I'm trying to be able to take user-supplied information from a page. In fact, the table on the [[Main Page|main page]] with the headers "Country", "Area", "Population", "Text", and "#hits" is a perfect example of what I want to do. (The answer was in front of me all along.)
  
===Answer===
+
:I still would definitely like to see an API layout to the code, even more so now. There are some really nice nuggets of functionality that would be useful as a suite of API tools and/or could be made into extensions in their own right, and if the code were in such a format, it'd be easier to pull out those bits of interest.
There is an experimental new feature which allows to define regular expressions which must match included contents (parameter ''includematch''). Please test and report your experience. Which behaviour would you expect if a page contained multiple chapters with identical name and only some of them match the condition?
 
  
I applied a "SAP" pattern to your test example. Does it now do what you had in mind?
+
:In fact, I'd like to see the mechanic in the aforementioned example in a form I can use outside of DPL.  Also, I'd like to get my hands on that bit of code that utilizes the character escapes to prevent templates, magic words, tags, and other parser functions from being parsed before they're ready to be. —[[User:Sledged|Sledged]] ([[User talk:Sledged|talk]]) 00:25, 15 September 2007 (CEST)
  
--[[User:Gero|Gero]] 23:02, 31 March 2007 (CEST)
+
::I understand. In fact I had to solve a couple of hairy problems to offer the full power which DPL has right now. I suggest the following: You create one or more modular pieces by lending code from the current source. Thus we have one or more independently usable extensions/modules. Once they are tested and their interfaces have stabilized I will refactor the current DPL code to make use of the new module(s). Although this will create dependencies BETWEEN extensions I think it is the right way to go for. Before you start extracting pieces of the code you should wait for version 1.4.2 as it will have some interesting new features regarding table handling. Internally it tries to solve some really hard problems regarding interaction with the mediawiki parser and its book-keeping on references. [[User:Gero|Gero]] 09:12, 22 September 2007 (CEST)
  
:: Thanks for your fast work. It is not exactly what I was hoping for, as the string only needs to appear in any of the output fields, not the exact field Quellsystem.  
+
:::Here's my first installment:  [[mw:Extension:Character Escapes|Character Escapes]]. I'm appalled at how simple that solution is and that no one has applied it to [http://meta.wikimedia.org/wiki/ParserFunctions ParserFunctions].  It doesn't use the escapes you've defined [[DPL:Manual - General Usage and Invocation Syntax#Characters with special meaning|here]], because it doesn't work well with heavy nesting. So instead of trying to find a workaround with what you've defined, I used the convention commonly used in programming languages (i.e. the backslash). —[[User:Sledged|Sledged]] ([[User talk:Sledged|talk]]) 06:50, 25 September 2007 (CEST)
:: I can make an easy workaround by defining a new includepage, which adds an "_" (or any other character) before the value Quellsystem and than search vor "_SAP", which will find all relevant entries. So I say: good enough!
 
--[[User:GunterS|GunterS]] 20:47, 2 April 2007 (CEST)
 
  
===Reply===
+
==<tt>redirects</tt> include pages that ''link'' to redirects==
 +
See [[DPL:Discussion#Redirects to include pages that link to them?]] -[[User:Eep²|Eep²]] 05:07, 13 August 2007 (CEST)
  
I changed the matching procedure to comply with your original reuqest as this is much more elegant.
+
:My final statement regarding this topic is in the [[DPL:FAQ|FAQ}}. [[User:Gero|Gero]] 10:31, 23 September 2007 (CEST)
Now templates are checked against the code which invokes them. So you can write
 
includematch=Quellsystem=SAP
 
But be careful: You normally will have to write something like
 
includematch=Quellsystem\s*=\s*SAP/s
 
which means that you allow whitespace around the '=' and that you extend your matching beyond newline charcters.
 
:[[User:Gero|Gero]] 13:16, 9 April 2007 (CEST)
 
  
== Allow selections based on users who created or modified a page ==
+
::Can't you just add a simple parameter to <tt>redirects</tt> (like "<tt>strict</tt>") that does this automatically without requiring complicated nested queries? -[[User:Eep²|Eep²]] 10:39, 23 September 2007 (CEST)
It would be nice to restrict selections based on the authors of pages.
 
  
=== Answer ===
+
==<tt>linksto</tt> and other parameter case-insensitivity option==
With version 1.0.5 we introduce a powerful set of such parameters.
+
I need this without having to manually specify lower-/upper-case versions of every page... -[[User:Eep²|Eep²]] 13:29, 2 September 2007 (CEST)
  
--[[User:Gero|Gero]] 06:27, 31 March 2007 (CEST)
+
:Mediawiki is case-sensitive by nature. So I can´t see what this should be good for ... Abc is the same as abc but is different from aBc and abC. DPL works on internal page_id numbers and these only exist for existing articles. [[User:Gero|Gero]] 14:31, 2 September 2007 (CEST)
  
 +
::Why must you fight me at every point in getting new features in DPL to make it easier to use, Gero? Geez. "Abc" is ''not'' the same as "abc" if <tt>$wgCapitalLinks = false;</tt> is set in localsettings.php, as I have it set in my wiki. I use DPL to list redirects but it requires a lot of variations on the page and support for multiple manually-entered parameters:
  
==Calendar application based on DPL / parserfunctions / inputbox extension==
+
<pre><nowiki>
Finally got it done!! You can test the application at [[Test calendar]]. There is a basic documentation on how to get it to work on any wiki.
+
|linksto={{FULLPAGENAME}}{{!}}{{FULLPAGENAME}}s{{!}}{{FULLPAGENAME}}es{{!}}{{FULLPAGENAME}}ies{{!}}{{FULLPAGENAME}}ing{{!}}{{FULLPAGENAME}}ed{{#if:{{{2}}}|{{!}}{{{2}}}{{!}}{{{2}}}s|}}
 +
</nowiki></pre>
  
Also added the page to the "test" category. --[[User:Ycombarnous|Ycombarnous]] 22:54, 28 March 2007 (CEST)
+
::This query doesn't have any problem if any of these pagename variations don't exist so why would <tt>linksto</tt> have a problem with pagename case variations either??
 +
::Is this like how you couldn't see what "on"/"off" and "1"/"0" for boolean operators is good for? Or why someone would want to create table columns vs. rows (as I want for each game in my [http://tnlc.com/eep/compare/table.html comparison table])? It's like the [[#redirects include pages that link to redirects|<tt>redirect</tt> issue]] you have been resisting and how MediaWiki devs resist adding suffix index ([[Special:Prefixindex]] in reverse) despite DPL being able to do it easily enough using a simple wildcard <tt>titlematch</tt> query (see http://www.tnlc.com/wiki/index.php?title=fire for an example). Enhancements like these make MediaWiki (and DPL) easier (and less frustrating) to use... -[[User:Eep²|Eep²]] 15:38, 2 September 2007 (CEST)
  
'''Update:''' I simplified the calendar so that twice less DPL calls are necessary. So it requires at most 31 DPL calls per month calendar (these are "light" calls). --[[User:Ycombarnous|Ycombarnous]] 14:09, 4 April 2007 (CEST)
+
::I really need this functionality, since trying to create case variations for all of the above redirect variations (PLUS creating the actual redirects!) is a tad big annoying... -[[User:Eep²|Eep²]] 05:40, 11 September 2007 (CEST)
 
 
==Documentation for using DplLst as standalone parser ?==
 
===Request===
 
I would be interested to use your implementation of lst, in order to benefit from template parameter parsing in particular.
 
If possible, could you make a small doc / examples on how to do an lst on a section or template ?
 
  
--[[User:Ycombarnous|Ycombarnous]] 13:50, 11 March 2007 (CET)
+
::Hello? -[[User:Eep²|Eep²]] 12:40, 22 September 2007 (CEST)
  
===Answer===
+
:::Version 1.4.2 will have an 'ignorecase' switch. It will have an effect upon 'linksto', 'titlematch', and 'uses', but due to technical reasons not upon 'linksfrom' or any other DPL parameter. [[User:Gero|Gero]] 10:34, 23 September 2007 (CEST)
Feel free to reuse the code. I added some remarks in the code but do not have time for thorough documentation. You only have to add the tag definition (I wouldn´t use "lst" to avoid conflicts with an installed version of LabeledSectionTransclusion). I deleted these definitions to avoid such interference (you could make a diff with Steve´s source code ...).
 
  
An alternative is to use DPL as a very thin interface to the inclusion functionality. I could add a parameter for the article name which would do an exact comparison instead of a SQL LIKE match (this is more efficient). This could also implicitly switch to mode=userformat with all separators being empty. The result would be a fairly slim call, I think.
+
::::OK, thanks--better than nothing. ;) -[[User:Eep²|Eep²]] 10:39, 23 September 2007 (CEST)
  
What exactly do you want to achieve?
+
== DPL doesn't respect $wgNonincludableNamespaces ==
 +
I'm using the [http://www.mediawiki.org/wiki/Extension:Lockdown Lockdown] extension to restrict read access to a certain namespace to one group of users only. Part of restricting read access is preventing page inclusion by namespace. DPL allows one to bypass this.
  
--[[User:Gero|Gero]] 19:15, 12 March 2007 (CET)
+
As a suggestion, if you're able to fix this, could you make it so that with DPL it'd be possible to include / transclude pages ''within'' a nonincludable namespace, but not ''across'' namespaces? E.g. if I set NS_PROJECT to be non-includable, it'd still be possible to include NS_PROJECT content on NS_PROJECT pages, but not on main namespace etc. pages.
  
===Question(2)===
+
Thanks. [[User:212.149.229.126|212.149.229.126]] 15:48, 11 September 2007 (CEST)
Well, I would like to replace all the sections I have in my page by templates (much more flexible), and then use something like:
 
<pre><nowiki>
 
{{#lstt: article name|template_name|template_out}}
 
</nowiki></pre>
 
So basically, this is in DPL, but having it available for a single article with a compact call format would be great. I have to admit that template parameter re-injection is just a great thought!
 
  
===Proposal===
+
:Do you think that DPL is wide-spread enough so that it is worth the effort? Is Mediawiki as a whole going to offer consistent support for such protection mechanisms and more elaborated access rights? --[[User:Gero|Gero]] 22:07, 11 September 2007 (CEST)
We could have a parameter named "title" which accesses an article directly (quite efficient compared to SQL LIKE) and which implicitly sets "mode=userformat". And we could use "include" as an alias for "includepage" (just to make the notation shorter).
 
You could then write:
 
<pre><nowiki>
 
{{#dpl:title=MyPage|include={template}suffix}}
 
{{#dpl:title=MyPage|include=#My Chapter}}
 
</nowiki></pre>
 
  
The advantage of this approach is that you could still use full dpl functionality, e.g. "multisecseparators" in case the same template is called more than once. Regarding the naming concept for the "alternate templates" I think the current mechanism of adding a suffix is quite natural and should stay as it is.  
+
::I have no idea how much effort would it take :) DPL's been actively developed for some time, so I thought I'd ask. I do realize Mediawiki isn't supposed to be a proper CMS with proper read access rules and so forth, so the private information wouldn't be ''that'' sensitive. In any case, it seems a bit too easy if it's accessible simply by using DPL. At the moment, there's no reason why I absolutely must use DPL, nor is there a reason why I absolutely must have read protected wiki pages. If the feature's very difficult to add, I'll just figure out which of the two, using DPL or having read restricticted wiki pages, save me more time. Thanks. [[User:212.149.229.126|212.149.229.126]] 22:58, 11 September 2007 (CEST)
  
--[[User:Gero|Gero]] 10:03, 13 March 2007 (CET)
 
  
I agree on all line, that would be perfect. It would provide a replacement/enhancement to lst without conflict. --[[User:Ycombarnous|Ycombarnous]] 13:52, 13 March 2007 (CET)
+
== Integrating templates==
 +
Hi Gero! By this time, if we want to collect data in many articles using a template, like [[Example 1]], we have to use the descriptions like followed:
 +
includepage={Country} dpl,#History,#Religion[20],revolution
 +
Could it be possible we could use them like followed:
 +
includepage={Country} __,name,capital,dial__,#History,#Religion[20],revolution
 +
or
 +
includepage={Country} {{{,name,capital,dial}}},#History,#Religion[20],revolution
 +
Then we would use [[Template:Catlist|Catlist]] to collect data.
 +
Because I am trying to develop the GUI of Catlist. Please see [[template:Catlist/test]]. I've added some elements like offset, include, table class and Title of column in it. But I still want to integreat all the templates in the one. The change which I ask for is come from new command [[Test table|table]].
  
===Solution===
+
By the way, I am afraid that [[template:Catlist/test]] use Get instead of Post. Could it be possible it would be disabled by passing too many data?
O.K., the feature is available with version 1.0.1 as agreed. See [[Test title]]. Happy testing!
+
Thank you!
If you find it useful and if it works stable could you please add a remark to the mediawiki.org page of the "LabeledSectionTransclusion" extension?
+
--[[User:Roc michael|Roc michael]] 04:32, 16 September 2007 (CEST)
  
--[[User:Gero|Gero]] 14:50, 14 March 2007 (CET)
+
::Gero, sorry! I'v seen the Eep²'s case like followed:
 +
|includepage={game}:year,{game}:genre,{game}:publisher,{game}:developer,{game}:engine,{game}:character
 +
::It also seems to be great!
 +
--[[User:Roc michael|Roc michael]] 13:39, 16 September 2007 (CEST)
  
==DPL could have a parameter to choose the maximum date of revision of pages to include==
+
:::Not really. As I've mentioned to Gero before (though I can't find where it's documented), it would be better if it could be declared like <tt>|includepage={game}:year,genre,publisher,developer,engine,character</tt> (or perhaps with colons vs. commas) without having to duplicate <tt>{game}</tt> for ''every'' parameter. -[[User:Eep²|Eep²]] 15:10, 16 September 2007 (CEST)
===Request===
 
If we want a dynamic page list such as : "new articles on Berlin up to November 2005", it would be nice to have DPL search the latest revision of articles before date YYYY-MM-DD.
 
  
This is especially useful for people storing specs and interested into revisions of some articles at some point in time (like your source code for DPL stored on this site).
+
::::I have a tendency towards the following syntax:
 +
|include={myTemplate}:parm1:parm2:parm3
 +
::::it could behave like the parameter list in the 'table' statement. It would deliver each parameter as acolumn of a row. What do you think? [[User:Gero|Gero]] 17:30, 16 September 2007 (CEST)
  
--[[User:Ycombarnous|Ycombarnous]] 10:23, 9 March 2007 (CET)
+
:::::Sounds good. Would there be a way to optionally deliver each parameter as a row of a column too? I still want to have the option of column entries vs. row entries for [http://www.tnlc.com/wiki/index.php?title=Comparison_table my game comparison table] (so it doesn't become unnecessarily wide due to the amount of parameters--I'd rather have longer vertical scrolling)... -[[User:Eep²|Eep²]] 07:32, 17 September 2007 (CEST)
  
===Answer===
+
== You have %USER% and adduser=true, what about %AUTHOR% to go with addauthor and %EDITOR% to go with addlasteditor ? ==
DPL 1.0.0 comes with four different possibilities for revision-related selection of pages. One of them does exactly what you proposed.
 
  
--[[User:Gero|Gero]] 10:42, 11 March 2007 (CET)
+
I realize that if addauthor = true, then %USER% is set to the author, but I want to create a table of data per page that includes both the most recent editor and the page author (first editor). For this we need the %AUTHOR% 'magic workd'.
  
Fabulous! Thanks.  
+
Man ... so many things about DPL are confusing! I think the [[adduser]] option (first/last editor depending on ordermehtod) should be clarified wrt. [[addauthor]] and [[addlasteditor]]. The description of adduser actually talks about dates!
  
--[[User:Ycombarnous|Ycombarnous]] 13:23, 11 March 2007 (CET)
+
:-D --[[User:Dmb|Dmb]] 01:49, 17 September 2007 (CEST)
  
===Request===
+
== Specific enhancements for 'table from template' DPL ==
Would it be possible to include date ranges? Using the above example, "New articles on Berlin in 2005". The problem that I'm encountering currently with combining allrevisionsbefore and firstrevisionsince is that it ''appears'' that the firstrevisionsince is not being considered. [http://www.haunted-memories.net/wiki/index.php/Dpl Example] ie: <nowiki>{{#dpl: category=random|firstrevisionsince = 2007|allrevisionsbefore = 2008}}</nowiki> returns everything in 'random', not just things in 'random' for the year 2007.
 
  
--[[User:Ratio|Ratio]] 12:14, 12 June 2007 (CEST)
+
I think a very commonly needed and natural use of the DPL is the 'table from template' DPL. I would like to suggest the following syntax to make it easier to generate such DPL output...
 
 
=== Reply ===
 
 
 
I changed the code to allow simultaneous conditions to be applied to revisions.
 
Now you should be able to get the desired result. How do you think about this?  [[User:Gero|Gero]] 08:10, 22 June 2007 (CEST)
 
<dpl>
 
debug=3
 
titlematch=Bug%
 
allrevisionssince= 2007-05-15
 
allrevisionsbefore= 2007-06-01
 
</dpl>
 
 
 
==Linksto parameter could have "AND/OR combinations" functionality as categories do==
 
===Request===
 
I am looking for articles that belong to 2 categories, and link to "link 1 or link2 or link3". I would like the order method to be linksto.
 
===Answer (1)===
 
Yes, a good idea, but this will take some time. One should be able to use logical expression with AND/OR/NOT/GROUPING for
 
* category
 
* linksto
 
* uses
 
* matches
 
The "not..." variants of these parameters could then become deprecated.
 
Is anybody willing to help with implementing that functionality?
 
-- [[User:Gero|Gero]] 10:53, 1 March 2007 (CET)
 
 
 
===Answer (2)===
 
For the moment I added "OR" grouping based on pipe separation for linksto, notlinksto, matches, notmatches, uses, notuses. Note that you cannot have more than one line for each of these parameters, i.e. there is no AND so far.
 
-- [[User:Gero|Gero]] 09:51, 4 March 2007 (CET)
 
 
 
==Allow other symbol for union of categories==
 
=== Request ===
 
It would be convenient to allow e.g. "\" for "|", so that in the case of using the parser function version, the "|" does not have to be written as "<nowiki>{{!}}</nowiki>". The "\" seems better than "/", which may occasionally occur in a category name.--[[mw:User:Patrick|Patrick]] 16:53, 15 February 2007 (UTC)
 
 
 
=== Response ===
 
I will consider to use a general alias symbol for the pipe symbol which looks very similar : ¦
 
--[[User:Gero|Gero]] 09:28, 16 February 2007 (CET)
 
 
 
:For readibility of wikitext that is better than <nowiki>{{!}}</nowiki>, but on many keyboards it is not available. There is often a key labeled like that, but giving "|".--[[User:Patrick|Patrick]] 09:52, 16 February 2007 (CET)
 
 
 
:: I implemented "¦ aka |" in version 0.9.3 (the current version on this website) as an alternative for <code><nowiki>{{!}}</nowiki></code> and although I can see the problem of [[DPL:Manual#Using_DPL2_as_a_parser_function|confusing]] "¦" with a standard "|" , I think it could be quite useful, even for wikipedia in general..<br>What do you think? --[[User:Gero|Gero]] 11:41, 16 February 2007 (CET)
 
 
 
:::Thanks. On my own installation I also added
 
  
 
<pre>
 
<pre>
// use the \ as a general alias for |
+
...
$input = str_replace('\\','|',$input);
+
incude = {Some template}:parameterOne
 +
incude = {Some template}:parameterTwo
 +
incude = {Some template}:parameterThree
 +
tablehead =  Title,           One,           Two,            Three
 +
tablebody = %TITLE%, %parameterOne%, %parameterTwo%, %parameterThree%
 +
...
 
</pre>
 
</pre>
:::for easy typing. A backslash does not seem to conflict with anything, as long as category names do not contain a backslash, which does not seem wise anyway.--[[User:Patrick|Patrick]] 09:54, 17 February 2007 (CET)
 
  
::::Did you check if \n still works as an alias for a newline character? If not there would still be the paragraph symbol ..
+
The above would generate a table of data for the named parameters passed to 'Template:Some template' in the included pages. I really really love the functions provided by DPL, I just find them hard to master! --[[User:Dmb|Dmb]] 18:53, 18 September 2007 (CEST)
::::--[[User:Gero|Gero]] 12:20, 17 February 2007 (CET)
 
 
 
:::::You are right, that does not work. Perhaps #or is a good extra possibility instead, with the code:
 
  
 +
=== Reply ===
 +
That´s almost exactly what will be in the next version! But The syntax will look like this:
 
<pre>
 
<pre>
// use #or as a general alias for |
+
...
$input = str_replace('#or','|',$input);
+
include = {Some template}:parameterOne:parameterTwo:parameterThree
 +
table  = ,, One, Two, Three
 
</pre>
 
</pre>
 +
Creating pseudo variables for each column would add new complexity which I try to avoid.
 +
:[[User:Gero|Gero]] 20:13, 18 September 2007 (CEST)
  
:::::[[User:Patrick|Patrick]] 15:00, 17 February 2007 (CET)
+
:: I understand why keeping complexity to a minimum is important, but the above solution (clean though it is) is very rigid compared to the flexibility afforded by the use of pseudo variables. Imagine the following, parameterOne is information about the category of the page that I would like to wrap <nowiki>[[:Category:%p1%]]</nowiki>, parameterTwo is an logo pointer that I would like to wrap <nowiki>[[Image:%p2%|200px]]</nowiki> and parameterThree is a website link that I would like to wrap <nowiki>[%p3% homepage]</nowiki>. None of this funn stuff is available via the above syntax (unless I am wrong). I can think of tons of examples where you just want the parameter, just like %TITLE% (or even %AUTHOR% or %EDITOR%). I am really enjoying watching DPL develope, and I realise that it is very easy for me to make suggestions without any clue regarding the underlying complexity, so sorry for sounding critical. The above is just an idea about what could be nice. All the best. --[[User:Dmb|Dmb]] 01:34, 19 September 2007 (CEST)
 
+
::: No comment? --[[User:Dmb|Dmb]] 21:04, 19 September 2007 (CEST)
::::::We could also look for mathematical symbols for intersection / union etc. and provide a more powerful syntax in general. But the problem with the '''pipe character''' must still be solved in a general way as it occurs also at other places, e.g. in ''listseparators='' when you want to use wiki syntax to create a table layout in your DPL result.
+
:::: I´m afraid of the work ;-). The idea is very good, no doubt. Could you help with implementation? [[User:Gero|Gero]] 12:52, 20 September 2007 (CEST)
::::::--[[User:Gero|Gero]] 15:08, 17 February 2007 (CET)
+
::::: Sorry to hassle you about it, but I was keen to hear your opinion. I can certainly have a look at the source and let you know what I think. I am glad you like the idea :-D --[[User:Dmb|Dmb]] 21:10, 20 September 2007 (CEST)
 
+
:::::: That was a real challenge but I think I can come up with a good solution. The next version will contain the following new feature:
=== Status ===
 
resolved.
 
 
 
== date formatting ==
 
===Request===
 
addeditdate et al. would be more versatile if they accepted not just "true", but actual date formating as options. e.g.
 
addeditdate="("F d")"
 
would give "(October 23)", per the relatively standard date formatting functions, ParserFunctions and php's date.
 
 
 
=== Status ===
 
resolved; there is a new feature called "userdateformat" which gives you complete control over date formatting. It works as suggested. -- [[User:Gero|Gero]] 16:01, 26 February 2007 (CET)
 
 
 
== search & replace for article titles ==
 
===Request===
 
article titles could be changed in a systematic way (not the link target but the link label9
 
=== Status ===
 
resolved with 1.0.0, see "replaceintitle" parameter --[[User:Gero|Gero]] 18:49, 12 March 2007 (CET)
 
 
 
== repeated display if template is used multiple times in a page ==
 
===Request===
 
 
 
When you use "includepage={MyTemplate} dpl" DPL only evaluates the first occurance of that template in the article.
 
 
 
We use repeated lists of the same template within one page. It would be nice if in this case the output table could repeat the article name and list the corresponding entries of the templates.
 
 
 
===Answer (1)===
 
 
 
This is a good suggestion. But there arise some questions: What should happen if you specify two or more expressions in the "includepage=" parameter? Producing a second result line would be confusing in this situation I think (and is general not the best approach as we have ordinal numbering for the result lines according to the number of articles found). Maybe it would be better just to paste all occurencies of your template together. In your template you could care for proper optical separation by putting a horizontal bar at the end... (This bar would also appear if there happens to be only one occurence of the template, but maybe you could add a variable in your template call to the FIRST occurence of the template; this variable could be ignored in your noirmal template an could be used to decide whether you have to output a separation line or not in the template which you use in the DPL report).
 
 
 
I am willing to find a good solution and suggest that you define an example on this website and describe the desired output. --(Gero) [[User:217.111.20.10|217.111.20.10]] 17:29, 23 February 2007 (CET)
 
 
 
===Answer (2)===
 
 
 
Version 0.9.6 now has the ability to cope with multiple template calls and multiple identical chapter headings. A new parameter ("multisecseparators") can be used to define a separator which will be used for multiple identical sections. An example is [[Example multi|available]]. -- [[User:Gero|Gero]] 16:23, 26 February 2007 (CET)
 
 
 
Thank you so much. I prepared another [[Interface list|example]]. As you can see, it would be helpful on sorted tables if the <nowiki>[[%PAGE%]]</nowiki> parameter could be used as well. --[[User:GunterS|GunterS]] 19:54, 6 March 2007 (CET)
 
 
 
It was only two lines of code that had to be changed. See patch 2 of DPL 0.9.9. Now your example looks much better...
 
b.t.w: I always thought of software development repositories as a possible application field for DPL --[[User:Gero|Gero]] 20:35, 6 March 2007 (CET)
 
 
 
===Answer (3)===
 
 
 
In version 1.0.0 of DPL there is an additional possibility ("dominantsection") which does what you originally may have expected. It is not easy to understand but can be very useful sometimes, especially when creating sortable tables ... --[[User:Gero|Gero]] 10:42, 11 March 2007 (CET)
 
 
 
== Make the Namespace optional ==
 
 
 
=== Request ===
 
Thanks for updating DPL
 
 
 
Could you create a switch to disable the display of the namespace in <nowiki>%PAGE%</nowiki> as my ''category cloud'' looks a bit odd with category:item1 . category:item2 . category:item3 ......
 
 
 
Thanks
 
 
 
=== Response ===
 
I introduced with 0.9.6 a new variable called %TITLE% which contains the title of the page but not the namespace. So you can write <nowiki>[[%PAGE%|%TITLE]]</nowiki>. -- [[User:Gero|Gero]] 16:18, 26 February 2007 (CET)
 
 
 
 
 
== Global Background-color ==
 
 
 
=== Request ===
 
When I use the <code>column</code> or <code>row</code> parameters, the program will return tables by
 
the number of column/row I set.
 
May I set the global background-color to hide the table margin?
 
Thank you very much.
 
 
 
==== Example ====
 
 
<pre><nowiki>
 
<pre><nowiki>
{|width="100%" style="vertical-align:top;background-color:#f58ffa"
+
include  = {template}:parm1:parm2:parm3,#some headline
! <p style="margin:0; background-color:#cef2e0; font-size:120%; font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">Random Personal Pages</p>
+
table    = (tableclass),(articlelink),colheader1,colheader2,colheader3,chapter title
|-
+
tablerow = [[%%|''%%'']],[[Image:%%|200px]],[%% homepage],'''%%'''
|style="color:#000"|
 
<dpl>
 
  namespace=
 
  ordermethod=size
 
  randomcount=6
 
  mode=userformat
 
  listseparators={|style="background-color:#f5fffa;" cellpadding=2 cellspacing=10, \n|-\n|width=30%|\n* [[%PAGE%]],, \n|}
 
  columns=3
 
</dpl>
 
|-
 
|}
 
 
</nowiki></pre>
 
</nowiki></pre>
 +
:::::: You will have access to transcluded contents via "%%". This will also be possible for transcluded paragraphs.
 +
:::::: [[User:Gero|Gero]] 08:13, 22 September 2007 (CEST)
  
{|width="100%" style="vertical-align:top;background-color:#f58ffa"
+
==Could I use DPL to collect all the parameters of a template in a list==
! <p style="margin:0; background-color:#cef2e0; font-size:120%; font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">Random Pages</p>
+
HI! Gero.I want to use DPL to collect the parameters defined in a template ,by using a argument of DPL that would be called "temppar" or some what, with the result like followed:
|-
+
{| width=100%
|style="color:#000"|
+
|width=50% align=center|
<dpl>
+
<pre>
  namespace=
+
*param 1
  ordermethod=size
+
*param 2
  randomcount=6
+
*param 3
  mode=userformat
+
*param 4
  listseparators={|style="background-color:#f58ffa;" cellpadding=2 cellspacing=10, \n|-\n|width=33%|\n* [[%PAGE%]],, \n|}
+
*param...
  columns=3
+
</pre>
</dpl>
+
|align=center|
|-
+
{{#input: type = select
 +
| name = cars
 +
| multiple = 1 |
 +
*param 1
 +
*param 2
 +
*param 3
 +
*param 4
 +
*param 5
 +
}}
 
|}
 
|}
 +
Them I would use the result to make a multi-select in the [[Template:Catlist/test]] 'like followed' in the future. Do you think it is possible?--[[User:Roc michael|Roc michael]] 13:46, 19 September 2007 (CEST)
  
==== Example (correct) ====
+
=== Reply ===
 +
I assume that you have many articles which use the same template (t1)? And you want to collect all values for one parameter (xx) of t1 which are used in the template invocations? You can do that with <tt>uses=Template:t1</tt> and <tt>include={t1}:xx</tt>. If it is not a named parameter you can use a number like this <tt>include={t1}:2</tt>. The <tt>format=,,\n,</tt> can be used to output only the values of 'xx' in the calls for 't1', not the article names. The problem is that your list will not be unique; it will contain the same entries as often as they occur in the template calls. Maybe you can find another extension which produces a unique list from a list with multiple identical entries. Probably you also want the paramneter values sorted by their value and not by the occurence in the template calls ...
 +
:[[User:Gero|Gero]] 18:50, 19 September 2007 (CEST)
  
The code for constructing columns and rows can now be influenced by the user via "rowcolumnformat="; with this new parameter you get control over cellpadding, background-color etc.;
+
:Gero, Yes, I want to use the parameters of DPL like <tt>uses=Template:t1</tt> and <tt>include={t1}:xx</tt>. But what I really want to do is to make a GUI to produce the code above. when users ,who don't know DPL Skill or who want to use  DPL function in convenient way, can dependent on it to query the results what they want directly or produce the different kind of DPL-query-strings. Maybe what I want is like followed not the above.
 
+
{| width=100%
with <code>rowcolformat=style="background-color:#f58ffa;"</code> you get the desired result.
+
|width=50% align=center|
Note that you need to download patch 1 of DPL 0.9.9.
+
<pre>
 
+
*param name1 of t1
{|width="100%" style="vertical-align:top;background-color:#f58ffa"
+
*param name2 of t1
! <p style="margin:0; background-color:#cef2e0; font-size:120%; font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">Random Pages</p>
+
*param name3 of t1
|-
+
*param...
|style="color:#000"|
+
</pre>
<dpl>
+
|align=center|
  namespace=
+
{{#input: type = select
  ordermethod=size
+
| name = cars
  randomcount=6
+
| multiple = 1 |
  mode=userformat
+
*param name1 of t1
  rowcolformat=style="background-color:#f58ffa;"
+
*param name2 of t1
  listseparators={|style="background-color:#f58ffa;" cellpadding=2 cellspacing=10, \n|-\n|width=33%|\n* [[%PAGE%]],, \n|}
+
*param name3 of t1
  columns=3
+
*param...
</dpl>
+
}}
|-
 
 
|}
 
|}
 +
:You are right. On the other hand, I really forget the existence of parameters like <nowiki>{{{1}}},{{{2}}}}</nowiki>, because I don't use them in a template for definition items very often. And they will be a hole of the selection items in my GUI. But since it is popular to definition items with named parameter in a template, I think it's worth to create a function to collect all the parameter names of a template. How do you think?
 +
::--[[User:Roc michael|Roc michael]] 01:44, 20 September 2007 (CEST)
 +
----
 +
I am still not sure whether I understand what you want:
 +
* Do you want to write a DPL query which extracts documentation (like parameter names) from templates?
 +
* Or do you want to analyse actual invocations of templates and find the values used for parameters?
 +
In the first case your template could use a NOINCLUDE section where it calls another template (maybe named 'tpldoc') to describe its parameters. That would be really nice but would require some effort from the authors of templates. 'tpldoc' together with the dpl query could work a little like javadoc..<br>
 +
Analysing the source code of a template just to find which parameters it uses would only give you parameter names, not their semantics. And the names could even be dynamically constructed like <nowiki>{{{{{{name}}}}}}</nowiki>.
 +
[[User:Gero|Gero]] 13:04, 20 September 2007 (CEST)
  
 +
== Most popular page ==
  
::btw: could you please add your site to the [[DPL:Websites using DPL]]? --[[User:Gero|Gero]] 17:35, 5 March 2007 (CET)
+
'''Select by number of views during last n days.'''
  
'''reply'''
+
This could be either used to generate most popular pages or in conjunction with other conditions to draw attention to not so often wisited pages from certain category etc.
Thank you for your big big help.
 
My site using the great DPL is in a LAN and never be linked from outside. Should I add a new item without link to the [[DPL:Websites using DPL]]? --Jessie
 
  
::It would be nice if you gave us an example here, e.g. like GunterS has done; see [[Interface_list]]. --[[User:Gero|Gero]] 07:08, 8 March 2007 (CET)
+
:a) Please sign your contributions.
 +
:b) Is there a way to find out when a page has been visited via a SQL statement in wiki database?
 +
:[[User:Gero|Gero]] 10:37, 23 September 2007 (CEST)
  
==Ancestry Function==
+
== regex for category ==
  
DPL does a great job of listing all of the children of a category - all of the elements that belong to that category.  It would be nice, however, to be able to determine the "parents", "grandparents", "greatgrandparents", etc of an element - the categories that the element belongs to.
+
Is it possible to use regular expressions for categories? A lot of my categories have highly structured names. [[User:Tobias Conradi|Tobias Conradi]] 21:08, 27 September 2007 (CEST)
  
I use categories, subcategories, sub-subcategories to help my users drill down into the content.  A "reverse DPL" would let me put crumbs on each page to help the users find their way back out.  Even if the function could only find one level of parents, it could be nested to find the next level. For instance, if
+
:See [[categoryregexp]].
<nowiki>{{#dpl:</nowiki>''element=current page|mode=reverse''}}
+
:[[User:Gero|Gero]] 14:25, 3 October 2007 (CEST)
gave the parent category of the current element, then
 
<nowiki>{{#dpl:</nowiki>''element='' <font color='blue'><b><nowiki>{{#dpl:</nowiki>''element=current page|mode=reverse''}}</b></font> |''mode=reverse''}}
 
would give the grandparent category of the current element, and so on.
 
  
[[User:Furboy|Furboy]] 04:17, 15 March 2007 (CET)
+
== headings ==
  
=== Answer ===
+
I am trying to use DPL as a more flexible version of [[mw:Extension:Labeled_Section_Transclusion|Labeled Section Transclusion]]. As such my request may not be of broad interest but here it is.
  
DPL has the possibility to show all categories of a page, see the ''addcategories'' parameter. To demonstrate this feature I created a template called "Way up" which shows the category/categories of a page passed to the template. For "Fictitious country" a call will return {{way up|Fictitious country}}.
+
I found no easy way to include the heading as part of the chapter include (i.e. the include=#... feature). The only way that worked for me was to wrap the section with <section begin="foo"/> and <section end="foo"/>. But then, the edit doesn't take the user to the correct place. I'd like the edit to take the user to edit the actual text seen--not the page where the transclusion code shows. --[[User:Matthew|Matthew]] 07:20, 9 October 2007 (CEST)
  
So, if you pass the category of your page to this template you will get the ancestor. But you can do even better. If you put a call to that template into another template which assigns the "real" category to your page (called "is a", maybe), notation becomes very short:
+
:If you know the heading you can put it into the output stream yourself (using the <tt>format</tt> statement). If you include the chapter by its position the built-in variable %SECTION% will contain the section title. There is an [[Test include sections by number|example for this]].
<nowiki>
+
:[[User:Gero|Gero]] 20:56, 9 October 2007 (CEST)
{{is a|Country}}
 
</nowiki>
 
would be sufficient to assign an article to the given category ("Country") and output a link to its ancestor category. Note that it is not possible to call dpl recursively using its output as an argument for another call. There are many technical reasons for that. So you have to live with one level of grandparents.
 
  
--[[User:Gero|Gero]] 20:40, 17 March 2007 (CET)
+
== No More Globals ==
  
==Wildcard Categories==
+
Since MediaWiki is slowly moving away from globals (see [http://www.mediawiki.org/wiki/Manual:Global_variables Manual:Global variables]), I recommend that DPL also migrate from both global variables and functions.  Static class members and methods are a reasonable alternative.  —[[User:Sledged|Sledged]] ([[User talk:Sledged|talk]]) 06:18, 10 October 2007 (CEST)
  
It would be nice to be able to use wildcard characters in the category parameter.  So, something like,
+
----
<nowiki>{{#dpl:</nowiki>category = Ethiopia<font color='blue'><b>*</b></font>}}
+
You are absolutely right. The code is not very well structured. It grew from an old simple implementation to a rather big piece of code. Although I think it is still maintainable I would prefer some restructuring. Quality of open source products comes from several authors contributing to the same source (ideally ..). Would you want to start the restructuring effort? You could download the current sources, make the appropriate changes and then upload again within a time frame of, say four weeks...
would produce results for a category named Ethiopia, as well as for categories named Ethiopia<font color='blue'><b>n</b></font>, Ethiopia<font color='blue'><b>ns</b></font>, etc.
+
[[User:Gero|Gero]] 08:39, 10 October 2007 (CEST)
 
 
Similarly, something like,
 
<nowiki>{{#dpl:</nowiki>category = (800) <font color='blue'><b>###-####</b></font>}}
 
would produce results for categories like (800) <font color='blue'><b>555-1212</b></font>, (800) <font color='blue'><b>555-1234</b></font>, and so on.
 
 
 
[[User:Furboy|Furboy]] 04:40, 15 March 2007 (CET)
 
 
 
=== Reply ===
 
 
 
I think it is not too complicated to add something like "categorymatch=" and "notcategorymatch=" for traditional wildcard matching (SQL LIKE). For users with MySQL 5.x one could offer "categoryregexp=" and "notcategoryregexp=" in addition, which would allow to match numeric digits like in your (0800) example.
 
 
 
[[User:Gero|Gero]] 14:39, 15 March 2007 (CET)
 
 
 
Well, it´s already there. See [[Test regexp]]. [[User:Gero|Gero]] 15:32, 15 March 2007 (CET)
 
 
 
==Labeled Section Transclusion Syntax==
 
 
 
I understand that you adopted code for labeled section transclusion from the Labeled Section Transclusion extension, and that DPL uses the same LST syntax.  Is it possible to revise the hooks in DPL to accept the same anchoring syntax that MediaWiki uses? LST and DPL currently look for hooks with syntax like:
 
<nowiki><section begin=chapter1 />this is a chapter<section end=chapter1 /></nowiki>
 
 
 
For linking, MediaWiki uses either of the following:
 
<nowiki><a name="Section_linking" id="Section_linking"></a></nowiki>
 
<nowiki><span id="anchor_name"></span></nowiki>
 
 
 
Using the same conventions as MediaWiki is better for clarity (I don't have to keep track of what my anchor is for and whether I'm using the right syntax) and is better for economy (I don't have to include both MediaWiki anchors AND DPL anchors in a section that I want to both link to and transclude).
 
 
 
[[User:Furboy|Furboy]] 06:38, 15 March 2007 (CET)
 
 
 
:With the latest modifications DPL can more or less be used as a full substitution for LabeledSectionTransclusion, see [[#Documentation for using DplLst as standalone parser ?]] --[[User:Gero|Gero]] 07:15, 31 March 2007 (CEST)
 
 
 
===Question===
 
DPL parses the WIKI text of articles which are transcluded, not their generated HTML output. Are you talking about users who write something like
 
<nowiki><a name="Section_linking" id="Section_linking"></a></nowiki>
 
<nowiki><span id="anchor_name"></span></nowiki>
 
into their documents?
 
 
 
--[[User:Gero|Gero]] 13:58, 15 March 2007 (CET)
 
==islinkedto or linksfrom==
 
I suggest a method islinkedto or linksfrom, ie  <tt>islinkedto=foo</tt> only returns pages that [[foo]] links to. If Foo is a protected page, such as "Published" or "Approved" material, the resulting DPL will ensure some kind of quality control. I would really like it for my plan to run a collaborative podcast. I can't think of a better way to (a) provide some quality control and (b) provide some topic control, than to use DPLs. Thanks (Wikimedia user:pfctdayelise) [[User:59.167.184.59|59.167.184.59]] 16:04, 28 March 2007 (CEST)
 
 
 
Perhaps a more intuitive name would be whatlinkshere . [[User:59.167.184.59|59.167.184.59]] 16:06, 28 March 2007 (CEST)
 
 
 
:I didn´t believe that this could be a useful feature. But, well, there it is ([[Test linksfrom]]). Try Version 1.04 and let us know whether it works. Is your site publicly available? --[[User:Gero|Gero]] 21:19, 28 March 2007 (CEST)
 
 
 
 
 
== Dumb request ... ordered list 'offset' parameter? ==
 
===Question===
 
I am integrating DPL with the inputbox extension on my site to give the illusion of allowing the user to 'fill in' the title of the latest page... http://funktopia.net/index.php/Template:FilmUpdates
 
I would like the DPL to start the ordered list at element number 2 rather than 1 ... It it possible to have an 'oloffset' parameter? --[[User:141.14.26.126|141.14.26.126]] 13:20, 29 April 2007 (CEST)
 
===Answer===
 
There is a parameter called 'offset'. Use 'offset=1' and your list will start with the second entry. Gero 07:50, 30 April 2007 (CEST)
 
 
 
== Hide the default article list on a category page ==
 
=== Question ===
 
I am using DPL to create a list of articles in each category, and pull the description of each page from the template variables in each article. This is working perfectly but now I have 2 versions of the same lists, and it looks messy. A method (noCategoryList = true?) to hide the default list would be really handy.
 
=== Answer ===
 
Did you use 'mode=userformat' ? This is the general switch which switches off all default output... [[User:Gero|Gero]] 15:27, 8 July 2007 (CEST)
 

Latest revision as of 20:11, 12 October 2007


This page is no longer in use. If you think one of the issues mentioned below is still relevant, go to Category:Issue and create a new Issue (with type=Change Request and status=open) there.



Old requests (which have been resolved) can be found in the DPL:Requests for new features Archive.


Include other wiki pages

I want to include parts of Wikipedia articles on my wiki. Can DPL be expanded to do this? -Eep² 10:22, 20 August 2007 (CEST)

I don´t think so. Every wiki has its own categories, templates, images,.... So just transcluding the raw text (if it is available via &action=view) would not make much sense. And transclusion of rendered html text is not possible nor desirable either. Gero 14:28, 20 August 2007 (CEST)
And yet many websites (like http://encyclopedia.thefreedictionary.com/) do it all the time without any apparent problems (and there's even a WordPress plugin)... All I really want to pull in is the first paragraph; I don't need templates, categories, or even images. Links can obviously be pulled in easily enough that go to the correct place (Wikipedia or external links). See http://www.killertux.com/pages/Wikipedia_Simple_API.php?q=node/44 too for a "screen scraper" with PHP code you may be able to implement in DPL. -Eep² 15:19, 20 August 2007 (CEST)
Using the killertux API you can yourself include a whole wikipedia article into your wiki (as html or text). I can´t see what DPL should do in that context. DPL cannot and will not parse such scraped contents. You would have to build a completely separate and different mediawiki extension for that purpose. Gero 20:17, 22 August 2007 (CEST)


Most active page?

ordermethod=activity

Most number of edits or biggest diffs in the last t units of time???

--Dmb 18:11, 10 August 2007 (CEST)

The sheer number of edits is not very meaningful; and as soon as 'significance of change' comes into play, I see no way to implement such a feature without having to calling diff3 on every document. And that is definitely too resource consuming. Gero 14:55, 15 August 2007 (CEST)

Add 'contributors'?

addcontributors = TRUE contribthresh = x Kb

Instead of listing one page author or the last editor, addcontributor would add the users who had made significant diffs to the article, where significant is determined by contribthresh. The multiple names are listed separated by commas.

Woop!

--Dmb 18:11, 10 August 2007 (CEST)

That´s a pretty good idea. Maybe I will add that somewhen. Gero 23:56, 10 August 2007 (CEST)

I also thought of another idea... List users by total contrib size. Its a bit 'lets see who has the biggest penis' - but could be useful to see who has contributed most to a certain page or category. --Dmb 08:21, 14 August 2007 (CEST)

After some investigation I feel that it would be very slow and resource consuming to build that feature. If somebody can come up with a SQL statement which delivers the basic data we want to show: fine (I don´t know how to do it with pure SQL). Otherwise one would have to call diff3 for each document. That´s a show stopper. Gero 14:52, 15 August 2007 (CEST)
Hello Gero, and sorry for taking so long to reply. Here is the SQL that I have come up with. I think that it does the job (more or less).
SELECT
  rc_title, rc_cur_id, rc_user_text, rc_user,
  GROUP_CONCAT(rc_new_len - rc_old_len) AS DEBUG,
  SUM(ABS(rc_new_len - rc_old_len)) AS CONTRIB
FROM
 db_prefix_categorylinks  cl
INNER JOIN
  db_prefix_recentchanges rc
ON
  cl.cl_from = rc.rc_cur_id
WHERE 
  cl_to='Some_category'
GROUP BY
  rc_cur_id, rc_user
;

Using the above we get to see which user has done the most 'editing' of a page in the given category. The notion of 'editing' implemented above is quite crude, but I can't think of any better systematic way to do it (SQL or otherwise). The contributors option would take a threshold parameter to delineate the valid list of 'significant contributors' - that parameter could even be a fraction of the page size! Anyway, lemmy know if this is what you were looking for, and if not why not.

Thanks for the brilliant extension!

P.S. I wonder if we could apply a modified version of the above to look at the 'most active pages' request above?

--Dmb 13:53, 14 September 2007 (CEST)

Table row/column header switch

Can the table headers be used as the beginning of rows instead of at the top of columns? I would like to duplicate my game comparison table and need this functionality. -Eep² 05:43, 29 July 2007 (CEST)

Please give more details: How should the new switch be named, which values be allowed? In which modes should it have an effect and how should the result be affected?
For information: There will be no changes to the DPL sources within the next three weeks. Gero 08:13, 29 July 2007 (CEST)
I'm not a programmer, Gero...I just have ideas and what I want to do programmatically that I can already do (and have done for years) manually. Perhaps creating a "table" mode that deals with all table-related parameters like header (and column/row types). resultsfooter could have an option to be the last row or column of the table and include parameters for totals of a specific header (# articles in table, etc), a number field (like a "sum" function), etc. cellseparators could be used instead of listseparators (or at least as an alias) and. of course, support for specifying normal/regular non-suffixed template fields. Essentially, DPL needs more table-specific support to move it beyond just lists, per se. -Eep² 08:28, 29 July 2007 (CEST)
Still need this too... -Eep² 05:40, 11 September 2007 (CEST)

Template field output

Is it possible to output the unescaped wikimarkup (so it actually works as on pages that use the template) in DPL output? I want to create a DPL table that has same links as articles do that use the template in them which is also called in the DPL table. -Eep² 06:56, 26 July 2007 (CEST)


User-friendlines

DPL talk:Manual - DPL Special Page with Parameters#User-friendliness -Eep² 11:42, 25 July 2007 (CEST)


Be PostgreSQL compliant

Request

As of DPL 1.1.7, usage of DPL in a PostgreSQL-based MediaWiki requires further effort, which I describe in DPL:Manual - DPL with PostgreSQL.

  • I don't know if there is a common syntax between MySQL and PostgreSQL for the database functions - if not, my solution is easy to install.
  • But the need for a patch is really nasty. I think with my patch, DPL still works with MySQL as well. If so, could you kindly incorporate it.

I'd be curious if you consider this a feature request or a bug report…


rss feed from dpl

Request

A DPL might also have an according RSS feed. For example, a calendar might give a feed with the upcoming events from now on. --Eiland 09:30, 16 April 2007 (CEST).

Response

I haven´t worked with RSS generation so far. Is there a php library or a mediwiki module for that purpose? --Gero 22:08, 23 April 2007 (CEST)

Plenty of MediaWiki Extensions for RSS... should be easy to integrate with DPL :) --141.14.26.126 13:16, 29 April 2007 (CEST)
Which one would you suggest? Can you do the integration? Gero 20:12, 2 May 2007 (CEST)

Request

I have a similar request... Make each DPL into an RSS feed! --Dmb 11:20, 1 June 2007 (CEST)

Wait... that was me talking ... I just recognized my IP... (oh my memory!)

Well... you could start by looking here...

  1. http://meta.wikimedia.org/wiki/User:Mafs/RSS
  2. http://meta.wikimedia.org/wiki/RSS_into_Wiki
  3. http://www.mediawiki.org/wiki/GISWiki/RSS

That should certainly help with the details. Unfortunately I cannot do the integration myself or I would happily do it immediately. Thanks for the brilliant product and keep up the good work! --Dmb 11:24, 1 June 2007 (CEST)

nudge

Rss rss rss rss rss rss!!!


display Table of Contents for an article

Request

the incudepage feature could be enhanced to include the TOC only; a %TOC% variable would ebe useful ...

Putting delimiters between results

Will this solve a related formatting problem - putting delimiters only between results? Ideally I'd like to have a single result returned inline, but multiple results in an ordered list. It could be I misunderstood the documentation, but there doesn't seem to be a way to avoid a leading bullet or whatever in a list. Frank 14:35, 20 August 2007 (EDT)
There is a mode called 'inline' which does what you want. You can define the 'inline' tag contents. Gero 07:50, 10 September 2007 (CEST)
Nig1  my separator  Nig2  my separator  Nig3  my separator  Nig4  my separator  Category:CountryA  my separator  Category:CountryB

Hook based data exchange between extensions

Would it be possible to add a 'hook' (i.e. wfRunHooks) to DPL? Once a 'query' is finished executing, the result could be signaled to other interested extensions. A 'context id' would be required as potentially many queries could co-exist on the same page. I would suggest adding a parameter such as 'context=' OR just a linear incremental counter.

A 'no output' option would be great also - this way, if the query is really meant to be consumed by another extension, the user isn't distracted by the result from DPL directly. mw:user:jldupont

Reply

I do not have experience with creating hooks. There is a point in the code where the sql result set is ready. But be warned: The columns contained in the result set may vary depending on the options used. Generally speaking, DPL is a beast that has reached its saturation level of complexity ;-). I would more be in favour of a way where DPL produces some kind of csv output which is then fed into another extension. With mode=userformat this is fairly easy because you have complete control over the output. You can create csv or whatever format suits your own extension. This need not be wikitext nor need it be html or plain text - any kind of grammar is possible. For example you can use the result of one DPL statement as a parameter for another one, i.e. you can nest DPL calls. There is a good example for this: Wgraph:Example 4. Here the inner DPL query produces a pipe-separated list for the outer one.

So, the 'no output' you are looking for is already there. It´s called mode=userformat -- and it will take you some time to understand its power. Being the author I am still myself learning what you can do with DPL ;-)

The problem of multiple contexts is also solved by extension nesting. Maybe you do a little exeprimenting and then come up with another comment?

Gero 21:05, 24 July 2007 (CEST)

DPL API

I'd like to see more of an API structure to the code. The manual lists all the parameters and groups them by functionality, but no such break-up exists in the code (at least not that I could tell). At minimum, I'd like there be one function that processes the search criteria to get the results or groups of results in the form of an array of Title objects (or an array of arrays of title objects), and another function to display the results in a specified or default format.

I'd like to be able to build my own extension that uses the DPL2 extension as an API without having to hack the DPL2 code. —Sledged (talk) 01:03, 10 September 2007 (CEST)

Reply

Why don´t you just go ahead with DPL as it is? You can put any call of a parser function into the output loop of DPL. And you can use DPL in a way that it does not produce any single byte of output on its own. You can easily create title objects within your code from the first parameter which is passed to my working template. You might say that this is less efficient than an integration on php level but before trying to optimize you could build your extension right now without any change to DPL and without any code interference. What kind of application do you have in mind, by the way?. For example:

{{#dpl:
  |resultsheader=²{my envelope template¦%PAGES%}²
  |category=some category
  |namespace=some namespace
  |... etc
  |format=,²{my working template¦%PAGE%¦%TITLE%}²
}}

--Gero 07:28, 10 September 2007 (CEST)

I've been toying around with DPL a bit with some of the examples on this site, and I see now that it can do what I want it to do. Excellent! I'm trying to be able to take user-supplied information from a page. In fact, the table on the main page with the headers "Country", "Area", "Population", "Text", and "#hits" is a perfect example of what I want to do. (The answer was in front of me all along.)
I still would definitely like to see an API layout to the code, even more so now. There are some really nice nuggets of functionality that would be useful as a suite of API tools and/or could be made into extensions in their own right, and if the code were in such a format, it'd be easier to pull out those bits of interest.
In fact, I'd like to see the mechanic in the aforementioned example in a form I can use outside of DPL. Also, I'd like to get my hands on that bit of code that utilizes the character escapes to prevent templates, magic words, tags, and other parser functions from being parsed before they're ready to be. —Sledged (talk) 00:25, 15 September 2007 (CEST)
I understand. In fact I had to solve a couple of hairy problems to offer the full power which DPL has right now. I suggest the following: You create one or more modular pieces by lending code from the current source. Thus we have one or more independently usable extensions/modules. Once they are tested and their interfaces have stabilized I will refactor the current DPL code to make use of the new module(s). Although this will create dependencies BETWEEN extensions I think it is the right way to go for. Before you start extracting pieces of the code you should wait for version 1.4.2 as it will have some interesting new features regarding table handling. Internally it tries to solve some really hard problems regarding interaction with the mediawiki parser and its book-keeping on references. Gero 09:12, 22 September 2007 (CEST)
Here's my first installment: Character Escapes. I'm appalled at how simple that solution is and that no one has applied it to ParserFunctions. It doesn't use the escapes you've defined here, because it doesn't work well with heavy nesting. So instead of trying to find a workaround with what you've defined, I used the convention commonly used in programming languages (i.e. the backslash). —Sledged (talk) 06:50, 25 September 2007 (CEST)

redirects include pages that link to redirects

See DPL:Discussion#Redirects to include pages that link to them? -Eep² 05:07, 13 August 2007 (CEST)

My final statement regarding this topic is in the [[DPL:FAQ|FAQ}}. Gero 10:31, 23 September 2007 (CEST)
Can't you just add a simple parameter to redirects (like "strict") that does this automatically without requiring complicated nested queries? -Eep² 10:39, 23 September 2007 (CEST)

linksto and other parameter case-insensitivity option

I need this without having to manually specify lower-/upper-case versions of every page... -Eep² 13:29, 2 September 2007 (CEST)

Mediawiki is case-sensitive by nature. So I can´t see what this should be good for ... Abc is the same as abc but is different from aBc and abC. DPL works on internal page_id numbers and these only exist for existing articles. Gero 14:31, 2 September 2007 (CEST)
Why must you fight me at every point in getting new features in DPL to make it easier to use, Gero? Geez. "Abc" is not the same as "abc" if $wgCapitalLinks = false; is set in localsettings.php, as I have it set in my wiki. I use DPL to list redirects but it requires a lot of variations on the page and support for multiple manually-entered parameters:
	 
|linksto={{FULLPAGENAME}}{{!}}{{FULLPAGENAME}}s{{!}}{{FULLPAGENAME}}es{{!}}{{FULLPAGENAME}}ies{{!}}{{FULLPAGENAME}}ing{{!}}{{FULLPAGENAME}}ed{{#if:{{{2}}}|{{!}}{{{2}}}{{!}}{{{2}}}s|}}	
This query doesn't have any problem if any of these pagename variations don't exist so why would linksto have a problem with pagename case variations either??
Is this like how you couldn't see what "on"/"off" and "1"/"0" for boolean operators is good for? Or why someone would want to create table columns vs. rows (as I want for each game in my comparison table)? It's like the redirect issue you have been resisting and how MediaWiki devs resist adding suffix index (Special:Prefixindex in reverse) despite DPL being able to do it easily enough using a simple wildcard titlematch query (see http://www.tnlc.com/wiki/index.php?title=fire for an example). Enhancements like these make MediaWiki (and DPL) easier (and less frustrating) to use... -Eep² 15:38, 2 September 2007 (CEST)
I really need this functionality, since trying to create case variations for all of the above redirect variations (PLUS creating the actual redirects!) is a tad big annoying... -Eep² 05:40, 11 September 2007 (CEST)
Hello? -Eep² 12:40, 22 September 2007 (CEST)
Version 1.4.2 will have an 'ignorecase' switch. It will have an effect upon 'linksto', 'titlematch', and 'uses', but due to technical reasons not upon 'linksfrom' or any other DPL parameter. Gero 10:34, 23 September 2007 (CEST)
OK, thanks--better than nothing. ;) -Eep² 10:39, 23 September 2007 (CEST)

DPL doesn't respect $wgNonincludableNamespaces

I'm using the Lockdown extension to restrict read access to a certain namespace to one group of users only. Part of restricting read access is preventing page inclusion by namespace. DPL allows one to bypass this.

As a suggestion, if you're able to fix this, could you make it so that with DPL it'd be possible to include / transclude pages within a nonincludable namespace, but not across namespaces? E.g. if I set NS_PROJECT to be non-includable, it'd still be possible to include NS_PROJECT content on NS_PROJECT pages, but not on main namespace etc. pages.

Thanks. 212.149.229.126 15:48, 11 September 2007 (CEST)

Do you think that DPL is wide-spread enough so that it is worth the effort? Is Mediawiki as a whole going to offer consistent support for such protection mechanisms and more elaborated access rights? --Gero 22:07, 11 September 2007 (CEST)
I have no idea how much effort would it take :) DPL's been actively developed for some time, so I thought I'd ask. I do realize Mediawiki isn't supposed to be a proper CMS with proper read access rules and so forth, so the private information wouldn't be that sensitive. In any case, it seems a bit too easy if it's accessible simply by using DPL. At the moment, there's no reason why I absolutely must use DPL, nor is there a reason why I absolutely must have read protected wiki pages. If the feature's very difficult to add, I'll just figure out which of the two, using DPL or having read restricticted wiki pages, save me more time. Thanks. 212.149.229.126 22:58, 11 September 2007 (CEST)


Integrating templates

Hi Gero! By this time, if we want to collect data in many articles using a template, like Example 1, we have to use the descriptions like followed:

includepage={Country} dpl,#History,#Religion[20],revolution

Could it be possible we could use them like followed:

includepage={Country} __,name,capital,dial__,#History,#Religion[20],revolution

or

includepage={Country} {{{,name,capital,dial}}},#History,#Religion[20],revolution

Then we would use Catlist to collect data. Because I am trying to develop the GUI of Catlist. Please see template:Catlist/test. I've added some elements like offset, include, table class and Title of column in it. But I still want to integreat all the templates in the one. The change which I ask for is come from new command table.

By the way, I am afraid that template:Catlist/test use Get instead of Post. Could it be possible it would be disabled by passing too many data? Thank you! --Roc michael 04:32, 16 September 2007 (CEST)

Gero, sorry! I'v seen the Eep²'s case like followed:
|includepage={game}:year,{game}:genre,{game}:publisher,{game}:developer,{game}:engine,{game}:character
It also seems to be great!

--Roc michael 13:39, 16 September 2007 (CEST)

Not really. As I've mentioned to Gero before (though I can't find where it's documented), it would be better if it could be declared like |includepage={game}:year,genre,publisher,developer,engine,character (or perhaps with colons vs. commas) without having to duplicate {game} for every parameter. -Eep² 15:10, 16 September 2007 (CEST)
I have a tendency towards the following syntax:
|include={myTemplate}:parm1:parm2:parm3
it could behave like the parameter list in the 'table' statement. It would deliver each parameter as acolumn of a row. What do you think? Gero 17:30, 16 September 2007 (CEST)
Sounds good. Would there be a way to optionally deliver each parameter as a row of a column too? I still want to have the option of column entries vs. row entries for my game comparison table (so it doesn't become unnecessarily wide due to the amount of parameters--I'd rather have longer vertical scrolling)... -Eep² 07:32, 17 September 2007 (CEST)

You have %USER% and adduser=true, what about %AUTHOR% to go with addauthor and %EDITOR% to go with addlasteditor ?

I realize that if addauthor = true, then %USER% is set to the author, but I want to create a table of data per page that includes both the most recent editor and the page author (first editor). For this we need the %AUTHOR% 'magic workd'.

Man ... so many things about DPL are confusing! I think the adduser option (first/last editor depending on ordermehtod) should be clarified wrt. addauthor and addlasteditor. The description of adduser actually talks about dates!

-D --Dmb 01:49, 17 September 2007 (CEST)

Specific enhancements for 'table from template' DPL

I think a very commonly needed and natural use of the DPL is the 'table from template' DPL. I would like to suggest the following syntax to make it easier to generate such DPL output...

...
incude = {Some template}:parameterOne
incude = {Some template}:parameterTwo
incude = {Some template}:parameterThree
tablehead =  Title,            One,            Two,            Three
tablebody = %TITLE%, %parameterOne%, %parameterTwo%, %parameterThree%
...

The above would generate a table of data for the named parameters passed to 'Template:Some template' in the included pages. I really really love the functions provided by DPL, I just find them hard to master! --Dmb 18:53, 18 September 2007 (CEST)

Reply

That´s almost exactly what will be in the next version! But The syntax will look like this:

...
include = {Some template}:parameterOne:parameterTwo:parameterThree
table   = ,, One, Two, Three

Creating pseudo variables for each column would add new complexity which I try to avoid.

Gero 20:13, 18 September 2007 (CEST)
I understand why keeping complexity to a minimum is important, but the above solution (clean though it is) is very rigid compared to the flexibility afforded by the use of pseudo variables. Imagine the following, parameterOne is information about the category of the page that I would like to wrap [[:Category:%p1%]], parameterTwo is an logo pointer that I would like to wrap [[Image:%p2%|200px]] and parameterThree is a website link that I would like to wrap [%p3% homepage]. None of this funn stuff is available via the above syntax (unless I am wrong). I can think of tons of examples where you just want the parameter, just like %TITLE% (or even %AUTHOR% or %EDITOR%). I am really enjoying watching DPL develope, and I realise that it is very easy for me to make suggestions without any clue regarding the underlying complexity, so sorry for sounding critical. The above is just an idea about what could be nice. All the best. --Dmb 01:34, 19 September 2007 (CEST)
No comment? --Dmb 21:04, 19 September 2007 (CEST)
I´m afraid of the work ;-). The idea is very good, no doubt. Could you help with implementation? Gero 12:52, 20 September 2007 (CEST)
Sorry to hassle you about it, but I was keen to hear your opinion. I can certainly have a look at the source and let you know what I think. I am glad you like the idea :-D --Dmb 21:10, 20 September 2007 (CEST)
That was a real challenge but I think I can come up with a good solution. The next version will contain the following new feature:
 include  = {template}:parm1:parm2:parm3,#some headline
 table    = (tableclass),(articlelink),colheader1,colheader2,colheader3,chapter title
 tablerow = [[%%|''%%'']],[[Image:%%|200px]],[%% homepage],'''%%'''
You will have access to transcluded contents via "%%". This will also be possible for transcluded paragraphs.
Gero 08:13, 22 September 2007 (CEST)

Could I use DPL to collect all the parameters of a template in a list

HI! Gero.I want to use DPL to collect the parameters defined in a template ,by using a argument of DPL that would be called "temppar" or some what, with the result like followed:

*param 1
*param 2
*param 3
*param 4
*param...

{{#input: type = select

name = cars
  • param 1
  • param 2
  • param 3
  • param 4
  • param 5

}}

Them I would use the result to make a multi-select in the Template:Catlist/test 'like followed' in the future. Do you think it is possible?--Roc michael 13:46, 19 September 2007 (CEST)

Reply

I assume that you have many articles which use the same template (t1)? And you want to collect all values for one parameter (xx) of t1 which are used in the template invocations? You can do that with uses=Template:t1 and include={t1}:xx. If it is not a named parameter you can use a number like this include={t1}:2. The format=,,\n, can be used to output only the values of 'xx' in the calls for 't1', not the article names. The problem is that your list will not be unique; it will contain the same entries as often as they occur in the template calls. Maybe you can find another extension which produces a unique list from a list with multiple identical entries. Probably you also want the paramneter values sorted by their value and not by the occurence in the template calls ...

Gero 18:50, 19 September 2007 (CEST)
Gero, Yes, I want to use the parameters of DPL like uses=Template:t1 and include={t1}:xx. But what I really want to do is to make a GUI to produce the code above. when users ,who don't know DPL Skill or who want to use DPL function in convenient way, can dependent on it to query the results what they want directly or produce the different kind of DPL-query-strings. Maybe what I want is like followed not the above.
*param name1 of t1
*param name2 of t1
*param name3 of t1
*param...

{{#input: type = select

name = cars
  • param name1 of t1
  • param name2 of t1
  • param name3 of t1
  • param...

}}

You are right. On the other hand, I really forget the existence of parameters like {{{1}}},{{{2}}}}, because I don't use them in a template for definition items very often. And they will be a hole of the selection items in my GUI. But since it is popular to definition items with named parameter in a template, I think it's worth to create a function to collect all the parameter names of a template. How do you think?
--Roc michael 01:44, 20 September 2007 (CEST)

I am still not sure whether I understand what you want:

  • Do you want to write a DPL query which extracts documentation (like parameter names) from templates?
  • Or do you want to analyse actual invocations of templates and find the values used for parameters?

In the first case your template could use a NOINCLUDE section where it calls another template (maybe named 'tpldoc') to describe its parameters. That would be really nice but would require some effort from the authors of templates. 'tpldoc' together with the dpl query could work a little like javadoc..
Analysing the source code of a template just to find which parameters it uses would only give you parameter names, not their semantics. And the names could even be dynamically constructed like {{{{{{name}}}}}}. Gero 13:04, 20 September 2007 (CEST)

Most popular page

Select by number of views during last n days.

This could be either used to generate most popular pages or in conjunction with other conditions to draw attention to not so often wisited pages from certain category etc.

a) Please sign your contributions.
b) Is there a way to find out when a page has been visited via a SQL statement in wiki database?
Gero 10:37, 23 September 2007 (CEST)

regex for category

Is it possible to use regular expressions for categories? A lot of my categories have highly structured names. Tobias Conradi 21:08, 27 September 2007 (CEST)

See categoryregexp.
Gero 14:25, 3 October 2007 (CEST)

headings

I am trying to use DPL as a more flexible version of Labeled Section Transclusion. As such my request may not be of broad interest but here it is.

I found no easy way to include the heading as part of the chapter include (i.e. the include=#... feature). The only way that worked for me was to wrap the section with <section begin="foo"/> and <section end="foo"/>. But then, the edit doesn't take the user to the correct place. I'd like the edit to take the user to edit the actual text seen--not the page where the transclusion code shows. --Matthew 07:20, 9 October 2007 (CEST)

If you know the heading you can put it into the output stream yourself (using the format statement). If you include the chapter by its position the built-in variable %SECTION% will contain the section title. There is an example for this.
Gero 20:56, 9 October 2007 (CEST)

No More Globals

Since MediaWiki is slowly moving away from globals (see Manual:Global variables), I recommend that DPL also migrate from both global variables and functions. Static class members and methods are a reasonable alternative. —Sledged (talk) 06:18, 10 October 2007 (CEST)


You are absolutely right. The code is not very well structured. It grew from an old simple implementation to a rather big piece of code. Although I think it is still maintainable I would prefer some restructuring. Quality of open source products comes from several authors contributing to the same source (ideally ..). Would you want to start the restructuring effort? You could download the current sources, make the appropriate changes and then upload again within a time frame of, say four weeks... Gero 08:39, 10 October 2007 (CEST)