Extension talk:DynamicPageList (third-party)

There is a separate document for Feature Requests on the DPL demo website.

Please use that one. Putting a "mw:" prefix before your signature will link to your media wiki user page.''

See also Bugzilla for the bugs for this extension.

Existing entries with feature requests on this page have been moved. --Algorithmix 08:45, 16 February 2007 (UTC)

=2007=

Recent Changes
For putting recent changes in a given namespace or category on a wiki page, there is also Extension:News -- Duesentrieb ⇌ 13:00, 17 February 2007 (UTC)

MediaWiki Version
This page says that DPL requires v. 1.7+ of MW, but the DPL wiki says 1.8+. Would be worth changing to whichever one is correct! I tried to install with 1.7 and it didn't work, which was disappointing. --16 November 2007

Conflict with RSSReader Extension
I've noted a conflict between the RSSReader Extension and DynamicPageList Extension when both are run on the same page. See Comment on RSS_Reader Extension for details. Any idea why this might be?

--C4duser 15:26, 27 November 2007 (UTC)

=2008=

Labeled Transclusion Sections with DPL 1.6.9
We just installed DPL 1.6.9 and noticed that our section transclusions are no longer working.

For example, we have

title=Article1

include=summary

And it used to work with the previous DPL version which displayed all text in the summary section but with DPL 1.6.9 nothing is being picked up. Any ideas? -alhui

99.249.236.178 18:01, 11 April 2008 (UTC)


 * Add the following after the line with inclusion of the extension in the file LocalSettings.php

$wgParserConf['class'] = 'Parser_OldPP';


 * This will force the mw-core to use the old parser. Jeblad 15:13, 13 April 2008 (UTC)


 * Having same problem and the OldPP hack doesn't seem to solve it. (MW 1.12; DPL 1.6.9; the labeled section extension has been deactivated, and the dpl2include seems to work because the "section" tag is listed in my MW spectial:version page). A page called Test1 with the text The book is Cien anos de soledad is never transcluded in a page Test2 with the code Nothing is output. The older version 08:32, 17 January 2008 works perfectly though. --Fxparlant 09:55, 14 July 2008 (UTC)


 * Try DPL 1.7.4. It runs on MW 1.12 and 1.13 as you can see on the dpldemo website. If you still have a problem, please demonstarte the effect on that website and we will have a look at it. 84.58.229.59 09:51, 27 August 2008 (UTC)

Problem with mediawiki 1.12
It seems that message file cause error on mediawiki 1.12 (see this thread). Could author of this extension make the update for us ? -- phkoech 26 april 2008


 * The dpldemo website is now running on MW 1.13. All problems should be solved. 84.58.229.59 09:48, 27 August 2008 (UTC)

labeled section only
How to list only the labeled sections, without the pages not containing the section: will list the pages of category Book, even if they do not have. The includematch cannot be used, because the include doesn't call the whole section, but only the content of the section tags. Any idea ? --Fxparlant 11:06, 14 July 2008 (UTC)

Catch a template parameter
I am looking for a way to use DPL to catch, not the title of a page, but the parameter of a template:

if a page calls the template  , how to catch the param3 in another page, with a query on the first parameter and the second ?

--Fxparlant 13:08, 7 August 2008 (UTC)


 * You can use phantom templates for that purpose. DPL will call the phantom template instead of the original one and pass all parameters to the phantom template in the same way as they were passed to the original template. And within the phantom template you can do whatever you like - which means that you can simply output the third parameter.


 * See the DPL manual for details. 84.58.229.59 09:47, 27 August 2008 (UTC)

New pages
Is there a way to get this to only return new pages (the pages in Special:Newpages)? Thanks 193.36.230.96 12:13, 17 August 2008 (UTC)


 * Yes
 * "ordermethod=firstedit" was the parameter I needed --18 August 2008


 * if you do not have too many updates such as daily or weekly news for which the Extension:News might be worth a try you can find an example and explanations on the steps necessary to update the main page almost automatically using DPL and Extension:Inputbox on the page User_talk:Ob.helm.--Ob.helm 16:51, 11 December 2008 (UTC)

Mediawiki Version 1.6.9
Hi,

Is there a way to get DPL running on a Mediawiki 1.6.9 ? If not, why exactly ?

Best regards --193.57.156.241 11:26, 4 September 2008 (UTC)

download from subversion
Can the download used the inclued mediawiki subversion system ? Crochet.david 19:00, 14 September 2008 (UTC)

Currently the latest version is on the dpldemo page. But this will change in the near future. Mediawiki SVN repository will become the official source for distribution. Algorithmix 09:22, 21 May 2009 (UTC)

Tweak to make DPL backward compatible with DynamicPageList2 parameter
I'm one of the admins at ChoralWiki (www.cpdl.org), a free Public Domain scores library, and we use DynamicPageList2 a lot in it with parameter set to 'true'. We were doing an upgrade test to the newest version of DynamicPageList and after the upgrade all our DPL queries started showing this warning:

%DPL-1.7.4-WARNING: Unknown parameter '$0' is ignored. Help: available parameters: suppresserrors.

After a quick research we realized that parameter is no longer supported by the new DPL versions. It would be a pain to edit all pages where it appears, so we decided to tweak the DPL code to recognize it and behave as expected. We made the changes below, tested it and it worked fine. So we decided to post it here in case someone else faces the same problem. All one needs to do is to add the following lines in red to file DinamicPageList2.php:

line 682:

/**        * noresultsheader / footer is some wiki text which will be output (instead of a warning message) * if the result set is empty; setting 'noresultsheader' to something like ' ' will suppress * the warning about empty result set. */       'suppresserrors'       => array('default' => 'false', 'true', 'no', 'yes', '0', '1', 'off', 'on'), 'noresultsheader'     => array('default' => ''), 'noresultsfooter'     => array('default' => ''),

line 1157:

$bSuppressErrors = self::argBoolean(self::$options['suppresserrors']['default']); $sResultsHeader  = self::$options['resultsheader']['default']; $sResultsFooter  = self::$options['resultsfooter']['default'];

line 2095: case 'noresultsheader': $sNoResultsHeader = $sArg; break; case 'suppresserrors': if( in_array($sArg, self::$options['suppresserrors'])) { $bSuppressErrors = self::argBoolean($sArg); if( $bSuppressErrors ) $sNoResultsHeader = ' '; }                   else $output .= $logger->msgWrongParam('suppresserrors', $sArg); break; case 'noresultsfooter': $sNoResultsFooter = $sArg; break;

After the change, if is used in the query and 0 pages are returned, it won't show any warning message; if  is also used, it will show the 'text' supplied. Capmo 13:40, 18 September 2008 (UTC)


 * Since release 1.7.5 suppresserrors is part of the official DPL distribution. Algorithmix 09:20, 21 May 2009 (UTC)

Licence
http://semeb.com/dpldemo/index.php?title=Main_Page says that "All extensions are under GPL license". So this page could be updated regarding the license.
 * Yes, has been done. Algorithmix 09:23, 21 May 2009 (UTC)

= 2009 =

Index (List of index-terms) for a book
I am experienced in editing wikipedia-articles. Now I want to use mediawiki on my server to write a book (around 1.000 articles). I want to mark index-terms in articles and have one page with a sorted index. The book will exist of 1.000 articles. So it is no problem to generate the article dynamicaly when I will open the index. Is DPL the right extension to do the job?

How to mark the index-terms in articles? Which -code do I need?

Or is there a better solution than DPL? Regards, jan--89.52.155.34 23:55, 13 January 2009 (UTC)

I made a beginning:

I have a template template:Index and call it in articles with with

For the output of the whole Index I have an article with: uses=Vorlage:Index include={Index}:1 table=,articletitle,keyword It works!

How can I get an output in an alphabeticle order like this? keyword-1 ..... articletitle 1 ..... articletitle 2 ..... articletitle 3 ..... articletitle ...

keyword-2 ..... articletitle 4 ..... articletitle 5 ..... articletitle 6 ..... articletitle 7 ..... articletitle ...

keyword-3 ...... ...

Regards, Jan--89.52.190.71 10:32, 14 January 2009 (UTC)


 * For me the answer is no longer important. I now use Semantic Mediawiki - takes longer to understand but is the future.
 * I don't delete the question - maybe someone else is interessted in the answer.
 * Regards, Jan


 * Hello Jan, creating a permuted index is a challenge because DPL normally walks sequentially through all articles which match the selection criteria and collects the desired information (in your case template invocations). In your case one would have to store the collected data (using the arrays extension ), re-arrange the order and then produce the output in a final step. With less than 10 lines of code all this is possible:
 * see     http://semeb.com/dpldemo/index.php?title=DPL_Example_017 
 * I know SMW and think it is powerful for expert users. The idea of DPL is to use MW as it is without introducing new syntax for those users who write articles.
 * Is your book publicly avaialable? If yes, please give a link. Algorithmix 09:32, 21 May 2009 (UTC)

Problems
Hi. I have a problem with labeled section transclusion, the section tags show up along with the transcluded text. This problem only showed up recently; the page was doing fine four months ago when I left it. When I came back a few days ago, no changes have been made to the articles but the DPL pages have broken formatting. It is a Wikia page and I asked the Wikia staff about it too, but they haven't recognized something from their end being the source of the problem either. So here's the problem. Instead of this:

http://img.photobucket.com/albums/v59/daarklord/ForumGraphics/DplWtf01.gif

I get this instead:

http://img.photobucket.com/albums/v59/daarklord/ForumGraphics/DplWtf00.gif

My wiki can be found here. The formatting error can be seen here.

Please help. Thank you.

-Daarklord 03:50, 16 April 2009 (UTC)

I installed the extension on a private wiki according to the notes on the page (#include("$IP/extensions/intersection/DynamicPageList.php");), but it doesn't work. When I disable (commtenting out) the extension in the localsettings.php, I can see the page. If I enable the extension I only get a white page displayed on pages with , all other pages can be edited and shown. (Setup: Mediawiki 1.13.2, Php 5.1.2 (apache2handler), MySql 5.0.26 und folgende Extensions ExpandTemplates (Version 2008-01-09) BugzillaReports (Version 0.9.8) Cite DynamicPageList Inputbox LabeledSectionTransclusion ParserFunctions (Version 1.1.1) SimpleSecurity (Version 4.2.14, 2008-09-12) SyntaxHighlight (Version r37495) AWC`s MediaWiki Forum )

Thanks for helping -- Joergens.mi 07:33, 2 February 2009 (UTC)


 * Can you please download the latest version and test again? There was a major problem in the logic of DPL which dealt with the inclusion of "labelled sections" ... Algorithmix 09:34, 21 May 2009 (UTC)

Documentation?
This article would be more helpful if it actually explained how to use this extension, rather than simply listing what it's capable of.


 * The article gives a link to the manual. I bet that the manual contains more information than you ever will want to read about DPL ;-)
 * Algorithmix 09:37, 21 May 2009 (UTC)

License for DPL
The wiki page for DPL says 'no license specified' the source code of the program has one file without any license, another with GPLv2+ and another that just says GPL. Could this please be made consistent? I would like to package DPL for Fedora.
 * --stahnma at fedoraproject dot org
 * It has always been GPL. Now it is mentioned in the info box. Algorithmix 09:16, 21 May 2009 (UTC)

Undefinde Variable
Wiki: 1.13.5

PHP: 5.0.5

Apache: 2.0.54

I have installed MediaWiki version 1.13.5 and included the extension dpl. Now I got on my main page this notice notes:

Notice: Undefined variable: result in D:\xampp\htdocs\Lukas\wiki113\includes\Title.php on line 1161

It's a liitle bit strange, because the extension works, but the notes are little bit annoying. What can I do now, has got someone an idea?

Greatz Lukas

171.24.253.44 08:42, 2 April 2009 (UTC):--


 * This should not happen! Are you sure that the error comes from DPL? I have never heard anyone reporting something like that. I suggest the following: Make a clean new test installation of Mediawiki, use DPL as the ONLY extension and then try to reproduce the error. If it still shows up, write a bug report and I will look after it.
 * BTW: Sometimes new MW versions introduce new errors. The dpldemo wiki runs on 1.13.0 Algorithmix 09:44, 21 May 2009 (UTC)

Section inclusion does not work
I noticed that section inclusion does nothing. In my wiki, as well as on the DPL demo wiki. See the section inclusion test page: it does not output the contents of the sections. It this broken? Using latest MediaWiki and latest DPL. My test page: http://www.jacmoe.dk/wiki/index.php?title=Conditional

Stavrosdr 23:05, 24 April 2009 (UTC) I have exact same problem MediaWiki (Version1.12.0) DynamicPageList2 (Version 1.7.4) ParserFunctions (Version 1.1.1) LabeledSectionTransclusion (Version ?)

I also have this problem with LabeledSectionTransclusion Stavrosdr 00:19, 25 April 2009 (UTC) I am using PHP 5.2.6-2ubuntu4.2 (apache2Handler) MySQL 5.0.67-0ubuntu6


 * Sorry, yes, there was a major bug in DPL which concerned the inclusion of labeled sections. It should be resolved with the latest version now. Please download and test. Algorithmix 09:46, 21 May 2009 (UTC)

Warning message
How can I remove the %DPL-1.7.6- in front of a warning message? The problem is this added in front of the MediaWiki message and I can't find it in the core code. When there are no results I want it to display nothing. --Subfader 12:02, 28 April 2009 (UTC)
 * Found it: return ' %DPL-' . ExtDynamicPageList2::VERSION . '-' . --Subfader 12:49, 28 April 2009 (UTC)
 * Yes, you can remove the prefix in the php source code. It is hard-coded there.
 * You could use suppresserrors=true to suppress the error message complaininig about an empty result set. Algorithmix 09:48, 21 May 2009 (UTC)
 * Yep, I found out about suppresserrors=true later which is the better solution, nontheless I think the %DPL- in fron of the messages are useless. Maybe remind the user that a DPL code is there. --Subfader 11:08, 21 May 2009 (UTC)

A Bug?
I use DPL together with MediaWiki 1.14.0, SMW 1.4.2, DPL 1.7.9 If I follow a link, that is done by the Call-Extension, the CSS-File of SMW is not included. What can I do? The main problem: The field “smwsortkey” is not more hidden, because the style for it is not included. Christian Weiss 14:44, 27 May 2009 (GMT+2)


 * Please give more details. I assume that the problem has nothing to do with DPL; this means that it also occurs if you use the Extension:Call from the browser's URL-line or within a normal document like this Special:Call/:Mypage,a=b . I don´t understand your remark about a "style". Are you talking about css? Can you reproduce the error on the dpldemo website? It has DPL 1.7.9 and SMW 1.0 installed. Algorithmix 16:11, 27 May 2009 (UTC)


 * The name of the extension is changed and this will create a lot of confusion about which extension infact has the bug. Jeblad 04:03, 31 May 2009 (UTC)


 * It's like you said: I call a Template by the Call-Extension, the DPL-Calendar ":Current events" for example. If it's included the normal Way in a Page, in the HTML-Source the "SMW_custom.css" and the "SMW_sorttable.js" are included. If the Template ist called by the "Call"-Extension those files are not included in the HTML-Source. A workaround ist to include those files in the Common.css and Common.js for Skins, so it is included everytime. For the SMW_sortable.js I get then 2x sortbuttons :-) I think, the Call-Extension ist part of your Pakage, so I write my Problem to you. Christian Weiss 10:06, 06 Jun 2009 (GMT+2)

LoF
I sthe LoF ment to be set as global in LocalSettings? I'd prefer it as option per DPL call. So I want to use a complex DPL call I would set LoF = 3 or sth inside the call. But if I want to run a very simple call I would set LoF = 0 to save some ressources. --Subfader 15:15, 17 June 2009 (UTC)


 * Currently the Level of Functionality is a configurable option which is global for the whole use of DPL in a wiki. It is meant to be a "protection belt" against abuse. I try to anticipate the aguments of those people who must be convinced to run DPL on a website lime WIKIPEDIA. Any suggestion which opens this path is welcome. I guess there will be some user rights administration component in the end - although I do not like this idea very much. --84.58.224.247 21:43, 1 July 2009 (UTC) (Algorithmix)


 * kk, thanks for the explaination. I thought it's mainly to make it faster. --Subfader 05:52, 2 July 2009 (UTC)

DPL Doesn't Work after MW Upgrade from 1.13 to 1.15.1
Hi, I have a private wiki we use as a content Management system at work. I updated the wiki from MW.1.13 to MW.1.15.1, and suddenly DPL doesn't work. For example, I have a page for each of our main applications, with a supbage called 'Troubleshooting'. Below that are more subpages, one for each troubleshooting document. The '/Troubleshooting' subpage consists entirely of DPL to list the child subpages for a user to browse and jump to.

For example (changing the page names to protect proprietary information):

We have a set of pages like so:

* Main:Zazaza * Main:Zazaza/Troubleshooting * Main:Zazaza/Troubleshooting/Error 51 - File not Found * Main:Zazaza/Troubleshooting/Can't Save Configurations * Main:Zazaza/Troubleshooting/App Crashes if User Chews Bubble Gum

The top page, Main:Zazaza, describes the application and has a link to Main:Zazaza/Troubleshooting.

Main:Zazaza/Troubleshooting consists entirely of DPL code that will list the three 'troubleshooting' child subpages with links. This page's DPL Code is as follows:

 

titlematch=Zazaza/Troubleshooting/%

notnamespace=Image

notnamespace=Image_talk

notnamespace=Template

notnamespace=Template_talk

replaceintitle=/.......Troubleshooting./,



Previously, the DPL worked, and a user browsing to the Zazaza/Troubleshooting page would see a list of clickable links:

Error 51 - File not Found Can't Save Configurations App Crashes if User Chews Bubble Gum

Now, since the 1.15.1 upgrade, all that shows up is the following:

Extension:DynamicPageList (DPL), version 1.8.6 : 

Before you ask, no, there is no log being generated or updated anywhere within my wiki home that provides me with a clue as to why DPL isn't working.

I confess to being confused because when I originally downloaded DPL in May or June 2008, this was during the time frame that "old DPL" was known as "Intersection" and 'this' DPL was just known as "DPL", and at the time there wasn't even a reference to the forked versions on the extension page. (I only came to learn all of this with my research this past week.) However, I have verified that I am using semeb.com's Dynamic Page List (was using v.1.6.9, now using v.1.8.6.)  I downloaded v.1.8.6 earlier in the week from http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/DynamicPageList/, and I just re-obtained the files from the ZIP archive available at http://semeb.com/dpldemo/images/f/fe/Semeb_extensions.zip and redeployed them to be certain. The behavior is still the same as above.

Any help would be appreciated. --ApostleGreen 23:12, 16 July 2009 (UTC)


 * DPL doesnt' work with MW 1.15.0 or MW 1.15.1 and DPL 1.8.6
 * DPL doesn't display anything, but I've to follow up the last Message from ApostleGreen.


 * The only output is:

Extension:DynamicPageList (DPL), version 1.8.6 : 
 * Please, this is a great extension, could anyone help us?!


 * Many thanks in advance!!! Timotheus.elias 07:43, 17 July 2009 (UTC)


 * Are you sure about all this? It worked fine for me in MW 1.14 and now in 1.16 alpha (I skipped 1.15). So you could still upgrdae to 1.16 alpha but actually I think something else is wrong on your wiki. --Subfader 10:57, 17 July 2009 (UTC)


 * Hi Subfader, I tried 1.16 alpha, but it has a conflict with an other extension, so I must use 1.15.1 for now.
 * The example DPL Code I used in my page:

 |titlematch=Basis:Mike3 |include   = * </DPL>
 * This are my used extensions:
 * GroupPermissions Manager
 * PdfExport
 * PdfBook
 * SimpleSecurity
 * wiki2xml extension
 * FCKeditor
 * Lockdown
 * Thank you!!!
 * Timotheus.elias 12:49, 17 July 2009 (UTC)

Well, your example code is wrong. It's either  titlematch=Basis:Mike3 include   = * </DPL> or Which is the other conflicted extension? --Subfader 13:28, 17 July 2009 (UTC)


 * I have the same problem. After upgrade from 1.13.3 to 1.15.1 the extension stop working. I've update extension to 1.8.6, but it doesn't help. --Dnikitin 19:11, 17 July 2009 (UTC)
 * It seems I fix my problem. Originally my code was

count=50 namespace=Image ...
 * After I replace Image with File the extension starts working again. --Dnikitin 22:22, 17 July 2009 (UTC)
 * Yep the Image namespace was renamed to File in MW 1.14. It needs to be replaced in all DPL calls. Still it works with old [[Image:...]] tags. --Subfader 23:11, 17 July 2009 (UTC)


 * Thank you very much vor your quick answer. Now, after I installed your extension correctly :), I'm able to include other pages that are not protected
 * by the extension Lockdown. Pages in the namespace I've locked with Lockdown extension are not includeable and there will be come following message:

Extension:DynamicPageList (DPL), version 1.8.6 : WARNING: No results.
 * When I call the following


 * I'll get all Article's there are not in the extra namespace "basis" and "public". Why is this so?
 * Although I don't enable Lockdown extension, there'll be the same result!
 * Many thanks! Timotheus.elias 13:41, 20 July 2009 (UTC)
 * The problem was fixed, the Wiki Parameter $wgNonincludableNamespaces was set and therefore this wasn't included. Thanks a lot for your great extension!!! Timotheus.elias 14:06, 20 July 2009 (UTC)

Parsing Pipes
I have run into a little bit of a quandary which I am trying to solve. I am trying to create a template with a set of parameters that are passed from a dynamically created list from DPL. However, when using the pipe character in the formatting for DPL like this: ...the pipe character is not parsed by the templating system, I think because of the order in which things are processed... The result is all the articles listed like this: "|Article1|Article2", and so on, instead of passing each one as a template parameter. I have been trying, but I can't think of a way around this. Does anybody have any thoughts on this? --Bsmithme 21:12, 18 July 2009 (UTC)
 * I have tried using subst:Hot_issues but that had no effect. I've also tried creating a template with "|", but that didn't work either.  I think I am approaching it wrong...--Bsmithme 21:15, 18 July 2009 (UTC)
 * Try ¦ --Subfader 21:16, 18 July 2009 (UTC)
 * No luck there. I think ¦ is only used when you are using #dpl and need a pipe in the dpl parameters, but I'm not sure (versus  where you can use pipes with impunity). --Bsmithme 21:29, 18 July 2009 (UTC)
 * Dunno your template but shouldn't it be {{Hot_issues without | cos that will be return in front of the first result already. Try

{{#dpl: }}
 * notnamespace=Category
 * category=Application
 * category=Hot_issues
 * format=²{Hot_issues,\n¦%PAGE%,,}²
 * Finds only pages in cats Application AND Hot_issues. Also %TITLE% doesn't make much sense to me when should find pages from all namespaces except subcats. If it doesn't help post your template here as I can't image what you try to do there by sending an unknown ammount of parameters (each page link) to the template. --Subfader 22:15, 18 July 2009 (UTC)
 * Think the best way to illustrate what I'm trying to do is this:

{{Hot issues }} So that the page calling the hot issue template is automatically populated based on the results of the DPL query. I'm starting to think it might not be possible to do it this way. --Bsmithme 23:45, 18 July 2009 (UTC)
 * DPL result 1
 * DPL result 2
 * and so on
 * Oh, but you are on to something with your suggestion and I think I can get it to work with some more fidgeting. --Bsmithme 23:52, 18 July 2009 (UTC)
 * Aha! I got it with this:

{{#dpl: }} Thank you so much for your assistance, Subfader. --Bsmithme 23:56, 18 July 2009 (UTC)
 * notnamespace=Category
 * category=Application
 * category=Hot_issues
 * format=²{Hot_issues,¦%PAGE%,,}²

RESOLVED: Fatal error
After upgrading my wiki to MW 1.15 I got the error message: Fatal error: Unsupported operand types in /home/schlott/public_html/wiki/includes/parser/LinkHolderArray.php on line 33 and the extension stoped working.

The solution was inside the DynamicPageList/DPL.php with the following statement in Line 36: // cloning the parser in the following statement leads in some cases to a php error in MW 1.15 // You must apply the following patch to avoid this: // add in LinkHoldersArray.php at the beginning of function 'merge' the following code lines: //		if (!isset($this->interwikis)) { //			$this->internals = array; //			$this->interwikis = array; //			$this->size = 0; //			$this->parent = $other->parent; //		}

After adding the mentioned code lines to LinkHoldersArray.php the extension works just fine. -- Flaming Moe

Comment on differing versions by Algorithmix

 * Note that the version running on Wikimedia sites was at some point in time renamed to Extension:Intersection to avoid confusion with the extension described here. But the documentation still was talking of "DynamicPageList" and the SVN path was not renamed.
 * Recently 'Intersection' claimed back its ancient name and that is why you now find the documentation of 'Intersection' under 'Extension:DynamicPageList'.
 * On the other hand the DPL extension described here was still named 'DynamicPageList' and new functions were added. At some point in time downward compatibility with the version running on Wikimedia sites was lost. The extension was renamed to 'DynamicPageList2' but the documentation was still talking of "DynamicPageList".
 * Then another bunch of functionality was added and downward compatibility (with DPL2) was lost. The name of this version was changed back to DPL (which was thought to be 'free').

''All this has created much confusion. Read below for a suggestion on how to re-unite the different variants.''

This extension Dynamic Page List (DPL) has the same roots as Extension:Intersection. Until recently DPL was almost - but not exactly - downwards compatible with Intersection. A lot of confusion comes from the fact that Intersection uses the tag &lt;DynamicPageList&gt; whereas Dynamic Page List (DPL) uses the tag &lt;DPL&gt;.

DPL offers functionality that goes far beyond Intersection. Some of this functionality might be useful also on Wikimedia sites. But the problem is that inexperienced users or people with 'not-so-good-intentions' might write DPL statements which create significant database load.

A good solution - which also puts an end to all naming ambiguities of DynamicPageList, DPL, DPL2 and Intersection looks like this:
 * 1) There should be only ONE extension.
 * 2) It should be called DynamicPageList (short name DPL).
 * 3) It should listen to the tags DynamicPageList and DPL for compatibility reasons.
 * 4) Its sources should be in the mediawiki SVN
 * 5) It should be strictly downward compatible with Intersection.
 * 6) It should offer a configuration switch (let us call it LevelOfFunctionality = LoF) which lets the administrator of a wiki decide, how much functionality will be offered to the users:
 * 7) * LoF = 0 is exactly identical with Intersection as of today.
 * 8) * LoF = 1 offers additional features which do not affect performance (mainly related to output formatting)
 * 9) * LoF = 2 offers additional features which are on the same conceptual level as Intersection like selection of pages by use of templates or by pagelinks. As the underlying table structures in the mediawiki database design are very similar to categories the performance cost of theses features are comparable in magnitude with Intersection's current features
 * 10) * LoF = 3 offers additional features which are more cost-intensive, like e.g. content transclusion from pages that occur in the DPL result; we think that a dedicated DPL cache could allow to offer these features also on high traffic sites - but this still has to be proved
 * 11) * LoF = 4 offers a last group of features which are a somewhat exotic and could create trouble if used by ignorant people (batch updates and batch deletions based on DPL query results)

--Algorithmix 17:18, 1 June 2009 (UTC)

DPL 1.8.0 made a huge step into that direction.

After some bugfixes we now have DPL 1.8.4 as a stable release which can serve as a base for re-unification of all DPL variants..

Please help testing! --Algorithmix 21:10, 15 June 2009 (UTC)


 * Moved from the main page. GreenReaper 20:02, 22 August 2009 (UTC)


 * My own thoughts on this: it's a good idea, but performance is a huge consideration. I suggest investigating ways to avoid loading DPL code unless it is required, particularly $wgAutoloadClasses. Right now APC shows that it is touching all the code on every page access, and that's a significant cost when you have a large number of pages being accessed. GreenReaper 21:51, 22 August 2009 (UTC)


 * The latest version of DPL only loads a small portion of its php code on the initial require_once. ONLY if there is a DPL call within a page the rest of the php code will be loaded. Which version did you test? Algorithmix 05:53, 23 August 2009 (UTC)


 * Ah, indeed it does - thank you! I was using 1.8.6 and it seems you made that change in 1.8.7 - I updated to 1.8.8 and now only DPLSetup.php is showing up on each load. That is a big improvement in code loaded - from 1.1Mb to 150kb. :-) GreenReaper 19:55, 23 August 2009 (UTC)

Trying to List Pages...
Trying to List Pages within a Namespace in Category Mode, Alphabatized on a non category page. Sounds ridiculous however this is the syntax that i am using: namespace=Article shownamespace=false mode=category ordermethod=category,title What i am trying to do is show all pages in the article namespace on a page in category mode alphabetized by the page title rather then the namespace. Currently all pages are organized under "A" because the pages are named Article:Page Name. I want to eliminate or mask the Article so that they are organized by Page Name.

Kevindank AT Gmail.com


 * Hmh, you aren't very clear.
 * 1) is there really a custom namespace called "Article"? Cos otherwise you mean Main: "namespace="
 * But I guess I know what you mean. Like in this example you don't want U headings but 0-Z... I dunno a solution :/ --Subfader 21:17, 21 October 2009 (UTC)

Workaround
If you apply a very small patch you can use ordermethod=titlewithoutnamespace to get the desired result:

find (near line 1860 in DPLMain.php in the latest version) case 'titlewithoutnamespace': and add the following line immediately after that line: $sSqlSortkey = ", $sPageTable.page_title ".$sOrderCollation." as sortkey";

I will add this code line to the next release. In fact, the patch will make the new behaviour the default (which is o.k., I think). Use ordermethod=title</tt> to switch to the old behaviour.

84.59.226.244 07:01, 22 October 2009 (UTC)

This worked perfectly Thank You.

DISPLAYTITLE and DYNAMIC PAGE LIST
is it possible to tie this to DISPLAYTITLE to sort pages by their DisplayTitle?

installation instruction problems
Thanks for this powerful extension. In order to help others to use it, I want to report two problems I just had in following the installation instructions in the article.

The instructions say: add include("$IP/extensions/DynamicPageList/DynamicPageList.php"); to LocalSettings.php However, the actual file downloaded for v1.14 was named DynamicPageList2.php. This modification worked: include("$IP/extensions/DynamicPageList/DynamicPageList 2 .php");

The second problem is probably due to my lack of familiarity with PHP. The instructions appear to say to add a function call in LocalSettings after the include statement above to control the richness level, like this: ExtDynamicPageList::setFunctionalRichness(3); However, this caused a fatal error, so I commented it out. Should the call be like this? DynamicPageList2::setFunctionalRichness(3);

--AJim 21:20, 30 October 2009 (UTC)

DPL extension inserts a blank line headline
Problem: DPL extension inserts a blank line in the article title (see picture). Other articles that do not use DPL, displayed without distortion.

I use the original Monobook skin and the following versions of components: Can you tell me how to solve the problem, please. Thanks!
 * MediaWiki - 1.15.0
 * PHP - 5.2.8 (appache)
 * MySQL - 5.1.30-community-log

Kabanoff 13:57, 5 November 2009 (UTC)


 * Never had this problem. But since it's also on the DPL website I guess it's not so easy to fix? --Subfader 14:35, 5 November 2009 (UTC)


 * Perhaps. The problem on this wiki appears when the user is not logged in the system. In my wiki blank line appears wherever there is DPL. Discussion of this issue is on DPL issue page --Kabanoff 08:53, 6 November 2009 (UTC)


 * The simplest way to go is to edit the main.css of your own skin. In Monobook, search p-cactions, you will see "top: 1.3em;" (or similar). Change it to "top: 2.3em". It may work. --Dullmau 20:26, 10 June 2010 (UTC)b

Having DPL Maintain #section Links
If the pages I'm building my DPL from have links like  A Section </tt>, is it possible to to have DPL maintain the url of the page with that specific section, rather than have it change it to the page that has the DPL on it? &mdash; Cosmotron 18:56, 8 November 2009 (UTC)

Template:DPL_Extension creation as potential redirect loop
There is a DPLSetup.php routine, commonSetup, which attempts to create an template using the userid of the first user to visit the wiki after the extension is installed:

Two issues with this:
 * (minor) The external link Extension:DynamicPageList (DPL) points to a disambiguation page here instead of to the actual extension info.
 * (not so minor) If creation of the template fails, the user is redirected to Template:Extension DPL regardless, and the failed attempt to create the template is repeated until the browser detects this as a redirect loop and shuts down.

I've noticed that new installs, if started with just a blank set of database tables and a LocalSettings file (without running the MediaWiki installer again for the new wiki), are prone to go into an endless HTML redirect loop because of this code. Attempts to run maintenance/update.php from the command line may also abruptly end with errors if the extension is trying to create this page during the "update.php" run and the database is not yet updated to the latest MW format (and therefore not ready for the template creation attempt).

There needs to be some error handling; if the creation of the placeholder template fails, don't just keep trying forever - at least not if this is going to return errors or redirect loops. --Carlb 14:12, 9 November 2009 (UTC)

Dynamic Pagelist vs. Semantic Mediawiki
I have started a Comparison of Dynamic Pagelist x Semantic Mediawiki. Please help to give valuable information for a good choice. --Jannis 19:19, 22 December 2009 (UTC)

=2010=

[SOLVED] White page after including Semantic Media Wiki Extension in LocalSettings.php
Hello, I installed the Semantic Media Wiki extension on a Media Wiki 1.16.0 According to the install notes on the page I appended the following two lines to the LocalSettings.php:

include_once("$IP/extensions/SemanticMediaWiki/SemanticMediaWiki.php");

enableSemantics('filerepos.de');

After that I get a blank page on every URL of the Wiki. Set error_reporting to E_ALL (in LocalSettings.php, SMW-Config-Files) but also got a blank page.

Also tried the hint from the Semantic Wiki Site with no success:

ini_set( 'memory_limit', '100M' );

When I comment the both lines out everything works again.

(Setup: Mediawiki 1.16.0, PHP Version 5.2.6, MySql 5.0.45, Semantic Media Wiki Extension 1.5.3 stable)

Would apreciate any hint.
 * This page is only for support for the DynamicPageList extension. You're more likely to get a response if you ask the SMW people. With that said, Did you add the:

error_reporting(E_ALL); ini_set("display_errors", 1); as the very first lines of LocalSettings.php (directly below the opening &lt;?php )? If that still doesn't work, try setting error reporting to E_ALL directly in your php.ini file. You can also try checking your webserver's error log as well (doesn't usually have php errors in it, but if its some sort of config problem with your webserver it might have relevant information). Bawolff 22:31, 26 November 2010 (UTC)

Thanks for the reply...think ini_set got the errorReporting working. Now there is some output I can work with: http://www.mediawiki.org/w/index.php?title=Extension_talk:DynamicPageList_(third-party)&action=edit&section=38 Call to undefined function enableSemantics in /srv/www/vhosts/filerepos.de/httpdocs/websites/semwiki/LocalSettings.php on line 138

[SOLVED] I accidently downloaded the wiki and the extension with different user...so the wiki wasnt allowed to access the extension. Changed extension files owner to the same owner as the wiki and so everything works now. Thanks for the error reporting hint which allowed me to find my mistake

Undefined index and .default
I try to make the DPL-Extension read out a category and get the parameters of a template in the articles of this category. They are meant to be used in another template. I saw another wiki which did it the same way as I did, but I get a strange Error while using the preview on this:

 category = Some Category mode = userformat includepage = {Template in articles} Kr allowcachedresults = true </DPL>

"Notice: Undefined index: tip ... EditPage.php". The line is this: "$tip = $tool['tip'],". This is strange but probably not that important. The real problem I got ist, that the extension always adds an ".default" at the end of the template. So I get a long list which just says "Template:Template in articles Kr.defaultTemplate:Template in articles Kr.default...".I don't really get the origin of the problem and couldn't find an answer anywhere. I didn't change anything in the basic code of mediawiki, except for some extra buttons i added in EditPage.php. There are also no extensions, that could affect the DPL extension.--Eski123 12:14, 2 January 2010 (UTC)


 * My five cents on this: according to doc, the DPL engine calls a template with the additional sufix ".default" when a page listed in the result does not use the specified template. Pierrem100 14:49, 26 October 2010 (UTC)

Problems with missing subheads
DPL is apparently crashing when used with a subhead that doesn't exist on one of the pages included by Category.

I have the following DPL code on a page called "Current projects":

=Projects in process= =Completed projects=

The first DPL call works if I temporarily clip out the second DPL cal, but including the second DPL call displays:


 * Fatal error: Call to a member function getPrefixedDBkey on a non-object in /Library/WebServer/EcoReality/wiki/includes/parser/Preprocessor_DOM.php on line 994

I then looked over the pages in the Category "Projects, completed" and discovered several of them did not have a subhead called "Final accounting." These are old pages, and this worked once upon a time!

For now, I've removed "Final accounting" from the second DPL call, but it seems it should behave better than this in such a case, no? Have I messed up something to cause it to misbehave this way?

See it fixed at: http://www.ecoreality.org/wiki/Current_projects.


 * If you haven't found it, this appears to be a problem with the DOM parser that has a patch on bugzilla. (I forgot to sign AND log in, awesome) --WeaverThree 20:03, 23 March 2010 (UTC)

Spaces and underscores
It seems that the "titleregexp" parameter doesn't interpret spaces and underscores the same way. In fact, since page names can't have spaces in them, any time there is a space it just flat out fails. This would ordinarily not be such a big deal, so, okay, you learn not to use spaces, however i have a template for detecting direct subpages of a page (but not sub-subpages). the regexp is /[^/]*$ however, if used on a page with a space in the name, returns a space there where dpl requires an underscore. It seems to me that spaces and underscores should be totally interchangable in dpl, as they are in the rest of MW. DeFender1031 11:22, 29 January 2010 (UTC)

MediaWiki SVN code incompatible?
The code in the mediawiki SVN does not work as per the instructions on the page. I wonder if we should remove this code to avoid confusion? JonathanWilliford 20:44, 6 February 2010 (UTC)
 * I found out that some MediaWiki users are trying to copy some of the functionality available from the zip file into the MediaWiki repository, while making sure that the code meets MediaWiki's coding standards. I created a section on the main page to comment on some of the differences in the code that is pertinent to users of the extension. --JonathanWilliford 22:24, 6 February 2010 (UTC)

DPL breaks references in Cite?
I'm having a weird problem with DPL and the Cite extension (http://www.mediawiki.org/wiki/Extension:Cite). A reference won't show up in the

The odd thing is that it is actually working for one of my templates. I resolved the issue by converting to the  hook instead. Still, it seems strange that this suddenly stopped working. Thorncrag 20:31, 18 August 2010 (UTC)
 * And I have just discovered that my workaround will not suffice because using the hook causes replaceintitle to not function the same as when using the parser call instead. Thorncrag 21:18, 18 August 2010 (UTC)
 * Note, as said in the thread above this one, you can also use {{#tag:DPL to access the &lt;DPL&gt; tag as a parser function which should have the exact same behaviour as &lt;DPL&gt; (compared to {{#dpl: which has slightly different behaviour compared to &lt;DPL&gt;). Bawolff 17:41, 19 August 2010 (UTC)
 * Even with this tag format, the noresultsheader is not honored, for some unknown reason. Thorncrag 19:45, 19 August 2010 (UTC) Due to being dyslexic I misread the suggestion... This actually might work, I shall troubleshoot further.    Thorncrag    23:31, 7 October 2010 (UTC)

Is this extension provoking an early call to ParserClearState?
On Extension talk:VariablesExtension a bug in combination with Extension:VariablesExtension was reported. It seems like DynamicPageList triggers an early call of the hook ParserClearState which could cause trouble with several extension. Do you have any idea how this happens and what would be the best solution to solve this problem between the extensions? --Danwe 04:35, 31 August 2010 (UTC)

70760 and mw 1.16+
i know it's not the most secure thing in the world, but do they still play nice together? redekopmark 18:38, 13 September 2010 (UTC)
 * I'm not sure what the number of 70760 is, however as far as i know they still play nicely together as long as the version of DPL is post 68812. However with that said, the categorylinks table changed quite a bit in 1.17 (aka current svn head). Some features might break in subtle (or perhaps not so subtle ways) because of that. It will certainly be less efficient for plain ole' category listings (but then again this is a very inefficient extension, so if you care about efficiently, I doubt you'd use it). Short answer: In my testing it still works, but no guarantees (+ the XSS issue). Bawolff 22:10, 13 September 2010 (UTC)
 * okay, thanks, the 70760 is the revision that i got when i downloaded the trunk version earlier today and i'm only planning on using it with 1.16 until 1.17 hits stable, again, thanks redekopmark 04:29, 14 September 2010 (UTC)

DPL & Nested Templates?
I may be missing something so I am posting the question here. Can DPL query variables passed to a nested template? Meaning, ...
 * You have a page named Resource1 which uses a template called ResourceType1 which is a member of the Asset Category.
 * Within template ResourceType1 you pass variables to and call the template called AssetInfo.
 * You then construct a DPL query which based on the Asset category queries all pages member of Asset and lists the variables found on the nested AssetInfo template

The rational for such a construct would be to list AsseInfo common to all resources which may use different ResourceType templates (type1, type2, etc) but are all members of Asset. Since the include/includepage line in DPL table output must be consistent, querying the nested common template seems the best approach but does not work. please advise?, thanks ahead of time for replies 208.79.244.111 23:23, 4 October 2010 (UTC)

Replace in title breaks with titles that contain parentheses
I've just discovered that an article title which contains parentheses causes the replaceintitle statement to break in that it will no longer perform any longer. In context, I have a replaceintitle which is supposed to remove the BASEPAGENAME from the title or an article that is a subpage, so that when I output title I can output only the name of the subpage instead of the entire trail. I still need to do further troubleshooting to see if it is actually BASEPAGENAME or %TITLE% which is breaking. Nevertheless, it's clearly an issue with the extension. Thorncrag   22:41, 7 October 2010 (UTC)
 * Note, per issue I reported above, I changed to #tag:DPL .... which is what bawolff had suggested. Unfortunately I misread it a long time ago... Anyhow that seems to have sufficiently worked around this issue.     Thorncrag    23:30, 7 October 2010 (UTC)
 * Well, changing to tag:DPL is till not yielding the results I need. It seems that several of the DPL options are not honored when changing to it.  So I'm back to parentheses breaking again.     Thorncrag    01:12, 8 October 2010 (UTC)
 * {{#tag:DPL Should take the exact same syntax as &lt;DPL&gt;. If there's something that works for &lt;DPL&gt; but not {{#tag:DPL, that's probably a bug in mediawiki (core) not the extension, since converting {{#tag:DPL to &lt;DPL&gt; is part of the parser. (With that said, I'm not sure how it'd help you with your issue, since the two should be exactly the same with exception of parsing the args before passing to DPL.). Bawolff 22:19, 26 October 2010 (UTC)

Use with TreeAndMenu Extension ?
Hi,

I only need this:

..To dynamically add all pages to a tree that is created by the Extension TreeAndMenu. I´ve tested it and it works great. Though I´m planning an opened wiki I´m a bit scared about the red box on this extensions main page telling me that it has a major security risk.

Is it possible to enable this extension only for a specific (admin) page or to eliminate the security risk by adding some contraints?

Thanks in advance! 87.78.238.27 18:47, 4 December 2010 (UTC)


 * The security risk will be eliminated in the next version. If you protect the the page with the DPL statement against changes, however, there should be no risk, even with the current version. 84.59.134.95 17:27, 10 December 2010 (UTC)
 * Hmm? Someone could just write a new DPL on an unprotected page. You'd also need to make it so DPL's only ran on protected pages. (I think there might even be an option for that. can't remember). Bawolff 19:09, 10 December 2010 (UTC)

Hi, thaks Bawolff, I´ll take a look at the settings soon. If you remeber please post it here.

87.78.237.140 09:33, 11 December 2010 (UTC)
 * See http://semeb.com/dpldemo/index.php?title=DPL:Manual_-_Source_and_Installation#DPL_Security (Note I haven't looked at the code implementing that, so I can't vouch for its security in any way or form, but the manual claims that it will work). Bawolff 17:09, 11 December 2010 (UTC)

Hi, thanks a lot! Have a nice christmas time! 87.78.48.253

Hi again. Sadly that was not the solution. If the option to allow DPL only on protected pages is enabled this also affects the NavTree (Extension: TreeANDMenu) that needs DPL to work propperly. What I need is DPL to only work in the sidebar :-). But I don´t know if that is easily possible?

Thanks!

195.14.207.110 19:30, 19 December 2010 (UTC)

=2011=

Tree and Menu and DPL - Advanced use
I'm currently using Tree and Menu and DPL to generate lists as shown in the Example. Works fine.

The problem is that our wiki will have a lot of pages and subpages, making the list expand really fast with similar named entries such as: Outlook Outlook/Installation Outlook/Usage

With the example structure above, is there a way to automatically create subfolders for all subpages using DPL syntax? Should be looking something like that **Outlook ***Installation ***Usage Any hints would be greatly appreciated. (Mike) dpl nested


 * For subcategories you could use nested queries. Not sure how to implent that for subpages. You may need titleparts and titlematch.
 * I once wrote a subpages script but it had some bug in the order iirc. --Subfader 19:20, 21 January 2011 (UTC)

Error on line 442
Hello, how can I solve this error? Deprecated: Function split is deprecated in /home/tibiawi/public_html/extensions/DynamicPageList/DynamicPageList2Include.php on line 442


 * Replace the   call with  , that should be equivalent. :) Make sure the line is passing the arguments as it should, though, the function headers are subtly different. -pinkgothic 14:36, 28 January 2011 (UTC)

DPL transclusion and performance tip

 * (Work in progress) better writ of the ramble below is at User:Pinkgothic/DPL, which is very layman oriented, so probably going to bore most people out of their minds, but I like having something I can link anyone to. :) -pinkgothic 15:49, 28 January 2011 (UTC)

Background:

If you're using DPL to generate lots of lists of lots of pages (that's 10-lots and 20+-lots respectively, which isn't very lots at all) and there are a lot of small changes being made constantly to your DPL-queried pages, you might notice your Wiki slowing to an unbearable crawl. If you're very lucky, you might notice this happens only after a submit of such a small (or large! let's not discriminate, here) change and then persists for a handful of pageloads, and then be on your way to finding a solution. Maybe you won't, though. Maybe you'll just be frustrated for two years until someone comes around and sinks their teeth into it for you. Oh wait, that's going into anecdote land, my bad! :)) *got to be that toothy person today*

What is happening is that DPL transcludes the pages that it lists in its table, which means that each time you change a DPL-queried page, you invalidate the DPL cache (= somewhat obvious) and you trigger a refreshLinks2 Job, which splits into  refreshLinks Jobs. In most cases, this is absolute overkill, because in most cases, you aren't changing something that is actually displayed by DPL, but in the body chunk of the page, and even then, you don't care to have your DPL-table page show up in the 'Links to this page' section of the page you put on your transcluded page.

If you're still following me now, I commend your intelligence and patience, it's a bit of a clusterfuck (that is no one's fault, by the way, it's the clean way to handle it, mediawiki just isn't an oracle).

Solution:

Find this line in your  file:

$jobs[] = new RefreshLinksJob2( $this->mTitle, $params );

Change it to this (or any arbitrary more graceful solution that's equivalent, of course, I was a bit fed up at the point in time when I finally wrote the if-statement):

if ($this->mTitle->getNamespace === 10 /* Templates */) { $jobs[] = new RefreshLinksJob2( $this->mTitle, $params ); }

There.

Note: This breaks non-template page transclusion link updating. It might also break some other 'refreshLinks' tasks, such as category linking. I'm still looking into that. If you're scared of the consequences of the if, add a cronjob for refreshLinks.php to run hourly and things should be smooth.

By the way, the reason the refreshLinks job is so unbearably slow is because it's rebuilding your DPLs. Rebuilding a DPL given an invalidated cache takes a very long time - on our Wiki, with several pairs of about 10 DPL table pages and ~100 queried pages, and a single line of content-regex per DPL call, rebuilding the table takes 3-8 seconds. Now imagine all DPLs that contain a changed page in their result set getting rebuilt during the same page load. That's the crawl.

I intend to rewrite this later to be more understandable by the layman, right now I just wanted to get this 'fix' out here as fast as possible.

-pinkgothic 14:32, 28 January 2011 (UTC)