From MediaWiki.org

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)

[edit] 2007

[edit] 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)

[edit] 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

[edit] 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)

[edit] 2008

[edit] 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

<dpl>

title=Article1

include=summary

</dpl>

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 <section begin=title />Cien anos de soledad<section end=title/>

is never transcluded in a page Test2 with the code

{{#dpl:debug=1|title=Test1|include=title}}

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)

[edit] 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)

[edit] labeled section only

How to list only the labeled sections, without the pages not containing the section:

{{#dpl:debug=1|category=Book|include=title}}

will list the pages of category Book, even if they do not have

<section begin=title />

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

[edit] 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 {{Temp|param1|param2|param3}}, 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] Tweak to make DPL backward compatible with DynamicPageList2 <suppresserrors> 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 <suppresserrors> 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 <suppresserrors> 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 <suppresserrors=true> is used in the query and 0 pages are returned, it won't show any warning message; if <noresultsheader='text'> 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)

[edit] 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)

[edit] 2009

[edit] 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 <dpl></dpl> -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

 {{Index|keyword}}

For the output of the whole Index I have an article with:

<dpl>
  uses=Vorlage:Index
  include={Index}:1
  table=,articletitle,keyword
</dpl>

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)

[edit] 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 <DynamicPageList></DynamicPageList>, 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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:

<DPL>
titlematch=Zazaza/Troubleshooting/%
notnamespace=Image
notnamespace=Image_talk
notnamespace=Template
notnamespace=Template_talk
replaceintitle=/.......Troubleshooting./,
</DPL>

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

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

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:

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

<DPL>
   titlematch=Basis:Mike3
   include    = *
</DPL>

or

{{#dpl:
   |titlematch=Basis:Mike3
   |include    = *
}}

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

<dpl>
count=50
namespace=Image
...
</dpl>

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

{{#dpl:
   |titlematch=%
}}

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)

[edit] 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:

{{Hot_issues
|<DPL>category=Application
category=Hot_issues
format=,|,[[%TITLE%]],
notnamespace=Category
noresultsheader=Nothing found...</DPL>}}

...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 <DPL> where you can use pipes with impunity). --Bsmithme 21:29, 18 July 2009 (UTC)

Dunno your template but shouldn't it be {{Hot_issues<DPL> 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
| DPL result 1
| DPL result 2
| and so on
}}

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)

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:
|notnamespace=Category
|category=Application
|category=Hot_issues
|format=²{Hot_issues,¦%PAGE%,,}²
}}

Thank you so much for your assistance, Subfader. --Bsmithme 23:56, 18 July 2009 (UTC)

[edit] 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

[edit] 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 <DynamicPageList> whereas Dynamic Page List (DPL) uses the tag <DPL>.

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:

There should be only ONE extension.
It should be called DynamicPageList (short name DPL).
It should listen to the tags DynamicPageList and DPL for compatibility reasons.
Its sources should be in the mediawiki SVN
It should be strictly downward compatible with Intersection.
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:
- LoF = 0 is exactly identical with Intersection as of today.
- LoF = 1 offers additional features which do not affect performance (mainly related to output formatting)
- 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
- 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
- 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)

[edit] 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:

<dpl>
namespace=Article
shownamespace=false
mode=category
ordermethod=category,title 
</dpl>

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)

[edit] 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 to switch to the old behaviour.

84.59.226.244 07:01, 22 October 2009 (UTC)

This worked perfectly Thank You.

[edit] DISPLAYTITLE and DYNAMIC PAGE LIST

is it possible to tie this to DISPLAYTITLE to sort pages by their DisplayTitle?

[edit] 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/DynamicPageList2.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)

[edit] DPL extension inserts a blank line headline

Blank line in 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:

MediaWiki - 1.15.0
PHP - 5.2.8 (appache)
MySQL - 5.1.30-community-log

Can you tell me how to solve the problem, please. Thanks!

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)

[edit] Having DPL Maintain #section Links

If the pages I'm building my DPL from have links like [[#section|A Section]], 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? — Cosmotron 18:56, 8 November 2009 (UTC)

[edit] Template:DPL_Extension creation as potential redirect loop

There is a DPLSetup.php routine, commonSetup(), which attempts to create an {{Extension DPL}} template using the userid of the first user to visit the wiki after the extension is installed:

private static function commonSetup() {
 
        if (!isset(self::$createdLinks)) {
            self::$createdLinks=array( 
                'resetLinks'=> false, 'resetTemplates' => false, 
                'resetCategories' => false, 'resetImages' => false, 'resetdone' => false , 'elimdone' => false );
        }
 
        // make sure page "Template:Extension DPL" exists
        $title = Title::newFromText('Template:Extension DPL');
        global $wgUser;
        if (!$title->exists() && $wgUser->isAllowed('edit')) {
            $article = new Article($title);
            $article->doEdit( "<noinclude>This page was automatically created. It serves as an anchor page for ".
                              "all '''[[Special:WhatLinksHere/Template:Extension_DPL|invocations]]''' ".
                              "of [http://mediawiki.org/wiki/Extension:DynamicPageList Extension:DynamicPageList (DPL)].</noinclude>",
                              $title, EDIT_NEW | EDIT_FORCE_BOT );
            die(header('Location: '.Title::newFromText('Template:Extension DPL')->getFullURL()));
        }
 
    }

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)

Extension talk:DynamicPageList (third-party)