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 mediawiki.org 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

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

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:

{{#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)

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)

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

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

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)

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:

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

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)

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

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:
   • 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)

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)

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.

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

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)

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 [[#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)

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)

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

<DPL>
  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=
{{#dpl:
 |ordermethod=lastedit
 |order=descending
 |category=Projects
 |include = #Project steward, #Need
 |includetrim=true
 |table=class="sortable", Project, Steward, Need
}}

=Completed projects=
{{#dpl:
 |ordermethod=lastedit
 |order=descending
 |category=Projects, completed
 |include = #Project steward, #Final accounting
 |includetrim=true
 |table=class="sortable", Project, Steward, Final Accounting
}}

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 DynamicPageList (third-party)/[^/]*$ however, if used on a page with a space in the name, DynamicPageList (third-party) 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 (Extension:Cite). A <ref>asdf</ref> reference won't show up in the <references/> section if any DPL query is run in between. Dug into the code a bit and it seems like DPL clones the parser and does a clearState(), maybe that clears the active cite object as well for some reason? Anyone else have this problem? Is there a workaround? I'm running MediaWiki 1.15.1, DPL 1.8.9 with PHP 5.2.6. --Shadowie 15:02, 27 February 2010 (UTC)

Found an active bug about this now as well. --Shadowie 15:07, 27 February 2010 (UTC)

Great and easy: Searchable Tables

I use the TableTools (Firefox-Extension) to search the tables generated with DynamicPageList (Mediawiki-Extension); see here [1]

With the Firefox-Extension installed you can right-click into a table and choose

1. show Filter (german: Filter anzeigen)
2. show Searchfilter (german: Suchfilter anzeigen)

With the first you get lists where you can choose an item in the table-heading and get all the rows matching this item.

With the second you get searchfields in the heading to use for a wildcard-search.

Both functions are very (!) usefull for the DynamicPageList-tables. But it is not userfriendly for less sophisticated users to right-click to get the function. I would like to put such functionality with an easy dpl-command into the heading, similar to the magicword "wikitable" or "sortable": "searchable". Now I wonder if it would be possible to integrate such a great feature directly into DynamicPageList??

I hope that others are also interested in such a feature.

Jan, --87.186.27.10 20:58, 1 March 2010 (UTC)

Bug found in Mix/Max revisions

Lines 2376 - 2381 of DPLMain.php should be modified as follows to use the abstract table names:

if ($iMinRevisions != NULL) {
 $sSqlWhere .= " and ((select count(rev_aux2.rev_page) from $sRevisionTable as rev_aux2 where rev_aux2.rev_page=$sPageTable.page_id) >= $iMinRevisions)";
}        
if ($iMaxRevisions != NULL) {
$sSqlWhere .= " and ((select count(rev_aux3.rev_page) from $sRevisionTable  as rev_aux3 where rev_aux3.rev_page=$sPageTable.page_id) <= $iMaxRevisions)";
} 

86.54.80.245 15:17, 19 March 2010 (UTC)

Setting parameter without using template?

Hi, it seems that all parameters are set in a template. In my wiki, there is a pretty standardized section and i would like to implement DPL on it. It's not a template but just a list of 1....2....3...list. Is there any markup tag that i can tell DPL that item01 = 1..  ; item02 = 2... ; item03 = 3.... ?

The current method is like this. It's actually good but in a FCKeditor-based Wiki, it may be too difficult to ask laymen to learn it.

{{ Country
|capital=Bamitogoo
|name=Republic of Nigunda
|dial=237

}}

--Dullmau 12:57, 19 June 2010 (UTC)

MediaWiki 1.17alpha and bug 22675

I downloaded the daily build of MW 1.17 alpha (12:13, 20 June 2010 - revision: r68310) core code and extensions and this seems to be broken. Symptoms are the same as reported in bug 22675 four months ago, the output appears on-screen as an HTML source code dump (<a href="...) instead of as hyperlinks in their clickable form. The Wikimedia (intersection) version of the extension still works normally with no other change to configuration. --Carlb 23:03, 20 June 2010 (UTC)

This applies to MW 1.16 beta3 as well. Thorncrag 02:47, 29 June 2010 (UTC)

The same problem with MW 1.16 beta1 EduRam 09:41, 1 July 2010 (UTC)

Oops. I just downloaded r68608 and it works with 1.16 beta3. I imagine it will with 1.17 as well. Should have done that before. :) Thorncrag 01:36, 30 June 2010 (UTC)

Er, now it appears I was somewhat incorrect. It appears as though some DPL statements are functioning and some are not, in r68608. Continuing to investigate. Thorncrag 22:31, 30 June 2010 (UTC)

Actually,this issue fixed in r68812 completely.You can download the new DPLMain.php to solve this problem.--Xlsoul 07:43, 21 July 2010 (UTC)

imagecontainer

Hi, I'm using DPL and imagecontainer, but I'm not sure what the problem is.

<DPL>
imagecontainer=Constructed items (1-24)
</DPL>

Shouldn't this give a list of all of the images used on the page? It's blank. 24.41.43.85 21:37, 1 July 2010 (UTC)

imagecontainer might be disabled - it needs the functionalrichness parameter to be at least 2. (if that is the case, I have no idea if there would be an error of some sort. this is just a guess, I don't know much about DPL2). Also check your version. imagecontainer was added in 1.7.4, some sites use older versions (wikia for example uses 1.6.4) Bawolff 23:06, 1 July 2010 (UTC)

Well, that would probably be the problem (the version; I'm using wikia). Is there any other way to make a list of all the images on the page? 24.41.43.85 00:51, 2 July 2010 (UTC)

You can use the api - http://runescape.wikia.com/api.php?titles=Constructed_items_(1-24)&action=query&prop=images&imlimit=max (if you need pretty output you can use either javascript or xslt) Bawolff 07:44, 2 July 2010 (UTC)

Thank you very much. I ended up using a mix of DPL and AWB to figure it out :). 24.41.43.85 06:16, 9 July 2010 (UTC)

PHP error since moving host

Hello,

Anyone got an answer for this PHP error, which has been appearing ever since I switched to a new web host? DPLs have stopped appearing on the pages, seems this error is to blame.

Parameter 3 to ExtDynamicPageList::dplTag() expected to be a reference, value given in /[snip]/includes/parser/Parser.php on line 3243

I've tried upgrading DPL, no luck. Is it a permissions problem perhaps? 87.194.148.160 17:14, 6 July 2010 (UTC)

You have to change the signature of the method dplTag() in line 865

public static function dplTag( $input, $params, $parser )

190.107.36.184 15:30, 30 July 2010 (UTC)

Thank you, it works (I've had this problem since I'd upgraded to PHP 5.3.x. ;)

Image inside a template

Is there by chance a way to make a list of all of the images that are used in a template? For instance, on this page, I'd like to have it add File:New Rune Scimitar.png . It's a parameter on the template, not part of the template itself. Is there a way to do so? 24.41.43.85 06:19, 9 July 2010 (UTC)

Anyone? 24.41.43.85 22:10, 10 July 2010 (UTC)

Parser function after a backup

I seem to have a strange issue after restoring a backup of my wiki on another computer. Both computers are using DPL version 1.8.9. I have a bunch of pages that use the parser function variant ({{#dpl: ...}} through some templates. For some reason, they display incorrectly on the new computer. Basically they just show the function then all of the parameters in what looks like a PRE tag.

The parser tag works fine. I can take the same queries and change them to the tag variant on a test page and they work great. The trouble is I need these to work in templates, so the function is needed. Anybody have any ideas what would cause this? - Glycerine102 14:50, 19 July 2010 (UTC)

No idea whats causing your original issue, but you can also try {{#tag:DPL - see Help:Magic_words#Miscellaneous. Bawolff 01:42, 20 July 2010 (UTC)

Parser versus Hook change?

Does anyone know what might have changed in the code to cause the following statement to no longer include the category here, as seen below:

{{#dpl:category={{PAGENAME}}|category=Application Error|notcategory=Subtopic-topic|replaceintitle=/{{BASEPAGENAME}}\//,|format=,\n*,[[{{BASEPAGENAME}}/%TITLE%{{pipe}}%TITLE%]],|notnamespace=Category|noresultsheader=There are no symptom entries for this application.[[Category:Articles with no symptom entries]]}}

The odd thing is that it is actually working for one of my templates. I resolved the issue by converting to the <DPL> 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 <DPL> tag as a parser function which should have the exact same behaviour as <DPL> (compared to {{#dpl: which has slightly different behaviour compared to <DPL>). 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#Big Job Queue/Import bug solved in 1.3 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 rev: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 <DPL>. If there's something that works for <DPL> but not {{#tag:DPL, that's probably a bug in mediawiki (core) not the extension, since converting {{#tag:DPL to <DPL> 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:

{{#dpl:category=Foo|format=,**,%PAGE%\n,}}

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

ExtDynamicPageList::$options['RunFromProtectedPagesOnly'] = "NO DPL FOR YOU!"; 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.

{{#tree:id=ToolsMenuTree|openlevels=0|root=Tools, Tips and best practice|
* Overview (Introduction Page)
{{#dpl:category=Tools and Tricks|format=,**,%PAGE%\n,}}
}}

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 split() call with preg_split(), 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

Better write of the (meanwhile deleted) 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)

Deleted the ramble, better read the extended version ;-) --Nakohdo 17:56, 8 February 2011 (UTC)

Semeb.com Troubles?

The whole /dpldemo/ folder seems to have disappeared from semeb.com. Is there somewhere else we can go to get to the manual? –DamnedScholar 20:51, 4 February 2011 (UTC)

Seems to be back: http://semeb.com/dpldemo/ --Nakohdo 17:48, 8 February 2011 (UTC)

So it is. –DamnedScholar 03:48, 14 February 2011 (UTC)

Issue with replaceintitle

I'm having an issue with replaceintitle when attemtping to do a replacement on a title which includes an apostrophy.

Here is my dpl call:

{{#dpl:
|shownamespace=false
|suppresserrors=true
|titlematch={{PAGENAME}}/%
|replaceintitle=/{{PAGENAME}}\//
|format=,\n* [[%PAGE%|%TITLE%]],,
}}

The above works perfectly on, for example, "John Smith", but "John O'Shea" fails to return any results. I've tried a number of ways to escape the apostrophy with no success, so any help would be greatly appreciated.

-AerosAtar 20:04, 19 February 2011 (UTC)

Extension:StringFunctions#.23replace:, Extension:MultiReplace --Subfader 00:29, 20 February 2011 (UTC)

I've tried using a #replace call from ParserFunctions (running 1.16.2), but it fails under the same circumstances. It is possible I wasn't writing the regexp correctly though. What would you suggest I try within the #replace call?

-AerosAtar 22:37, 21 February 2011 (UTC)

Its because the ' in {{PAGENAME}} is outputted as a &#39; to avoid making italic/bolding. You need to somehow use the replace parser function to replace the &#39; with a ' (And hope replace doesn't similarly replace ' character). Bawolff 03:58, 26 February 2011 (UTC)

Using {{#replace:{{PAGENAME}}|'|'}} or {{#replace:{{PAGENAME}}|'|%27}} doesn't seem to make any difference. Could there be something else causing this? It does only seem to be the one page with a ' in the title that is having a problem, which is why I have made the assumption that is the problem. -AerosAtar 16:37, 27 February 2011 (UTC)

Probably something to do with at what stage the &#39; is getting converted to a '. Perhaps using the tag version (aka <dpl> instead of {{#dpl:...) might work better since tpyically tag extensions have the content passed unmangled to the extension hook. (thats a bit of a long shot though). Bawolff

On a related note, this issue isn't limited to DPL, see bugzilla:16474. Bawolff 00:50, 1 March 2011 (UTC)

Unfortunately, for some reason that I have been unable to fathom, the <DPL> tag doesn't work on my wiki. Or on my 1.16 test wiki. So something has changed between 1.15 and 1.16 which has broken that (but my PHP knowledge is far too limited to even attempt to figure out what). Even Using {{#tag:DPL doesn't work... Oh well, guess I'll have to live with it for the moment. --AerosAtar 20:26, 3 March 2011 (UTC)

Breaks when using ordermethod pagesel

I've run into an interesting problem. When attempting to generate a list using "linksfrom" and setting ordermethod to "pagesel", the parser breaks with the following error:

SELECT DISTINCT `page`.page_namespace as page_namespace,`page`.page_title as page_title,`page`.page_id as page_id, pagesrc.page_title as sel_title, pagesrc.page_namespace as sel_ns, CONCAT(pl.pl_namespace,pl.pl_title) AS sortkey FROM `pagelinks` as plf, `page`as pagesrc, `page` WHERE 1=1 AND `page`.page_is_redirect=0 AND `page`.page_namespace = plf.pl_namespace AND `page`.page_title = plf.pl_title AND pagesrc.page_id=plf.pl_from AND ((plf.pl_from=0)) ORDER BY sortkey ASC LIMIT 0, 500

Error message is:
Unknown column 'pl.pl_namespace' in 'field list' (localhost) 

What's interesting is that this error does NOT occur if I change "linksfrom" to "linksto". What's also interesting is that on a cursory check of DPLMain.php for malformed code and found that the column pl.pl_namespace isn't even referenced in the "linksfrom" section, but is referenced in the "linksto" section, but I may not be looking at it right.
   Thorncrag   20:50, 22 February 2011 (UTC)

I forgot to post that I believe I found the issue causing this. On line 2088 of DPLMain.php the pagesel function is referencing the pagelink when it should be referencing pagefrom:

$sSqlSortkey = ", CONCAT(pl.pl_namespace,pl.pl_title) " . $sOrderCollation . " AS sortkey";

I changed pl.pl_namespace,pl.pl_title to plf.pl_namespace,plf.pl_title - and this seems to have resolved the issue.    Thorncrag   22:13, 16 March 2011 (UTC)

Show images of a category including links to pages using these images!

Hi all,

I have a difficult question. I would like to create a gallery like that:

{{#dpl:

  |category=Oneofmycats
  |namespace=Image
  |format=«gallery»,%PAGE%¦%NR%. %TITLE%\n,,«/gallery»

}}

That works great. But now I would like to have the name of the page (all of my images are at least only used on one page!) which makes use of the image as image text (not TITLE). In addition to that the name of the page should be a linkt to the page! So it would be possible to show all Images of a certain category including linkt to each page using this image (there is only one page!).

Found this code here:

{{#dpl:

  |imageused=myimage.jpg
  |format=,%PAGE%\n,,

}}

But I don´t know how to merge this two operations to one big thing!

Hope you understand what I mean :-).

Thanks in advance.

DPL for category page – order by second name?

I'm using DPL for a personalized category page because I didn't like the MediaWiki-own view. Everything works fine but there is one point I despair of. For the category of persons I want the list to be ordered by second name. In the standard category view this issue is solved by a tag on every page that tells MediaWiki how to order, e.g. on the page "Angie Gielach" [[Kategorie:Personen|Gielach]] to have it listed under "G" instead of "A".

In DPL I use the following code to display the pages of my category "Personen" alphabetically:

===A===
<DPL>
category = Personen
format   = ,\n* [[%PAGE%|%TITLE%]],,
title<=B
</DPL>

Has anyone a solution for this? --188.110.236.197 20:57, 2 May 2011 (UTC)

ordermethod=category,sortkey - IIRC it does't work well. --Subfader 21:25, 2 May 2011 (UTC)

Compatibility with the Collection extension

This extension is great but when you try to export to a pdf with the book/collection extension nothing gets printed. Is there a way to solve this?--Tsouchon 13:50, 6 May 2011 (UTC)

This is an issue with several extensions. See bugzilla:21653 for example. Bawolff 20:05, 24 May 2011 (UTC)

Selecting Articles based on template parameter value

--Riveraea 20:10, 23 May 2011 (UTC) Hi, I am new to DPL. I have articles with a template named ProjectInfo, that contains parameters named ProjectName, ProjectOwner, ProjectDate. I want to use DPL to create a list of projects that are recent (ProjectDate less than 3 years old).

I am testing this code:

<dpl>
 category=PendingProjects
 include={ProjectInfo}:ProjectName:ProjectOwner:ProjectDate
 includematch = (Here I want ProjectDate > 3 years)
 table=,,ProjectName:ProjectOwner:ProjectDate
 resultsheader=Number of data = %PAGES%\n
 noresultsheader= no matching projects were found.\n
</dpl>

Thanks for any help!

You have to use a subquery which will result in all pages with the temnplate being returned but hiding those which do no match your age criteria (for which you'll need Extension:ParserFunctions for the check). A very dirty solution tho. --Subfader 19:04, 24 May 2011 (UTC)

--Riveraea 19:36, 24 May 2011 (UTC) The logic I may use to evaluate the date is :

{{#ifexpr:{{#time:U}} > {{#time:U| {{{ProjectDate}}} + 3 year}}|Older than 3 years|Less than 3 years}}

Do you mean that all the records may be selected, then format the output to hide not wanted records? Please provide an example of the format expression. Thanks!

Intercept a list of articles by alphabetic character

I have a list of articles on people, sort by last name (via sortkey). To make it easier for users to find a name in the list I want to intersect the list with subheadings showing the alphabetical character:

A

• Otto Ader
• Anton Albers

B

• Chris Bill

...

Any ideas? --188.98.11.250 20:42, 1 June 2011 (UTC)

It works this way

{{#dpl:
|category=...
|ordermethod=sortkey
}}

Should also work with mode=category

{{#dpl:
|category=...
|mode=category
|ordermethod=sortkey
}}

but I get a blank page on that (old DPL version here). http://semeb.com/dpldemo/index.php?title=Mode#mode --Subfader 18:26, 5 June 2011 (UTC)

Thanks for your answer. I now use this:

<DPL>
category=Personen
mode=category
ordermethod=sortkey
</DPL>

Together with the setting ExtDynamicPageList::$categoryStyleListCutoff = 400; it outputs a list separeted by the alphabetical character but without columns. Now there is one new problem appearing: Somehow the parser doesn't change the html-tags produced by the DPL-plugin into wiki-links. Thats what I get:

A

• <html><a href="/index.php/Otto_Abetz" title="Otto Abetz">Otto Abetz</a></html>
• <html><a href="/index.php/Alma_de_l%27_Aigle" title="Alma de l' Aigle">Alma de l' Aigle</a></html>
• <html><a href="/index.php/Helmut_Amanshauser" title="Helmut Amanshauser">Helmut Amanshauser</a></html>

Of course everything works well if I set $wgRawHtml = true; in localsettings.php, but shouldn't it work without this? --188.98.11.250 19:53, 5 June 2011 (UTC)

No idea, never happened to me. But yes, it should work without $wgRawHtml = true;. For proper support you may want to start an "issue" on http://semeb.com/dpldemo/index.php?title=Extension_DPL --Subfader 19:03, 6 June 2011 (UTC)

Problems with VariableExtension

I'm having problems with using the VariableExtension together with DPL, here is an example:

 {{#vardefine:pagetitle|Main Page}}

 ==First==
 {{#dpl:titlematch={{#var:pagetitle}}}}

 ==Second==
 {{#dpl:titlematch={{#var:pagetitle}}}}

I'm using Mediawiki v1.17, Extension:VariableExtension v1.3, and DPL v1.8.9 (the MW1.17 build, DynamicPageList-MW1.17-r76531.tar.gz).

The output from the first call is not the same as the output from the second call. Shouldn't it be identical? The first call returns "Main Page" and "Talk:Main Page" as expected, but the second call instead gives this strange error message:

Extension:DynamicPageList (DPL), version 1.8.9 : ERROR: No selection criteria found! You must use at least one of the following parameters: category, namespace, titlematch, linksto, uses, createdby, modifiedby, lastmodifiedby or their 'not' variants

Please help! Amerias 13:27, 11 July 2011 (UTC)

I have reported this above already, but now I looked into it a little bit further. Seems like this is a problem ob DynamicPageList. This extension shouldn use Parser::parse(), the code Parser class documentation states that this function should NOT be called recursively! Since this function is called for page rendering, you shouldn't use it within this extension. Instead you should use Parser::recursiveTagParse(). File: DPLMain.php, line 3310, $parserOutput = $localParser->parse( $output, $parser->mTitle, $parser->mOptions ); --Danwe 00:18, 24 July 2011 (UTC)

I've tried to use recursiveTagParse as you suggested, but it doesn't fix the problem unfortunately. So far, I can confirm on 1.17 that this problem breaks Cite, Variables and Semantic Internal Objects behaviors. Everything is fine once DPL is deactivated.

sure you have changed it everywhere? Or there must be any other cause which is triggering the ParserClearState hook, thats the only event all variables getting flushed down the toilet... --Danwe 17:34, 30 July 2011 (UTC)

I indeed changed it in multiple DPL files, but no success. As I saw on bugzilla, this bug is unfortunately here since 2009. --112.136.72.214 08:41, 31 July 2011 (UTC)

It works in latest DPL, but latest DPL has different problems - "namespace" support doesn't work

Can't get a simple List to generate something other than HTML tags around the list contents

I've followed the install as stated and generated a simple test list which yields results with html tags around the list contents. I've tried it with both the DPL tag and the DynamicPageList tag and they still both output html and not wiki links.

<DPL>
  category=Vampire
count=5
</DPL>

<DynamicPageList>
  category=Vampire
count=5
</DynamicPageList>

<DPL>
namespace=Player_Page
columns=3
ordermethod=title
randomcount=5
count=5
offset=1
shownamespace=yes
</DPL>

yields

    <html><a href="/index.php?title=Category:Camarilla" title="Category:Camarilla">Category:Camarilla</a></html>
    <html><a href="/index.php?title=Category:Vampire_Character_Creation" title="Category:Vampire Character Creation">Category:Vampire Character Creation</a></html>
    <html><a href="/index.php?title=Category:Vampire_Commentaries" title="Category:Vampire Commentaries">Category:Vampire Commentaries</a></html>
    <html><a href="/index.php?title=Category:Vampire_Policies" title="Category:Vampire Policies">Category:Vampire Policies</a></html>
    <html><a href="/index.php?title=Category:Vampire_Systems" title="Category:Vampire Systems">Category:Vampire Systems</a></html>

    <html><a href="/index.php?title=Category:Camarilla" title="Category:Camarilla">Category:Camarilla</a></html>
    <html><a href="/index.php?title=Category:Vampire_Character_Creation" title="Category:Vampire Character Creation">Category:Vampire Character Creation</a></html>
    <html><a href="/index.php?title=Category:Vampire_Commentaries" title="Category:Vampire Commentaries">Category:Vampire Commentaries</a></html>
    <html><a href="/index.php?title=Category:Vampire_Systems" title="Category:Vampire Systems">Category:Vampire Systems</a></html>
    <html><a href="/index.php?title=Category:Vampire_Policies" title="Category:Vampire Policies">Category:Vampire Policies</a></html>

    <html><a href="/index.php?title=Player_Page:Article_Count_Test2" title="Player Page:Article Count Test2">Player Page:Article Count Test2</a></html>
    <html><a href="/index.php?title=Player_Page:Article_Count_Test3" title="Player Page:Article Count Test3">Player Page:Article Count Test3</a></html>

    <html><a href="/index.php?title=Player_Page:PC_Census" title="Player Page:PC Census">Player Page:PC Census</a></html>
    <html><a href="/index.php?title=Player_Page:Player_Pages" title="Player Page:Player Pages">Player Page:Player Pages</a></html>

    <html><a href="/index.php?title=Player_Page:Sandbox" title="Player Page:Sandbox">Player Page:Sandbox</a></html>

I'm running MW 1.16.2 with PHP 5.2.17 (cgi) and MySQL 5.0.91mm-log

Have I forgotten something? I put in the following on my localsettings.php and downloaded from the extension page the proper package for my version of MW.

 include("$IP/extensions/DynamicPageList/DynamicPageList2.php");

I don't know where else to go for help. I've reviewed bugs and issue pages and really didn't see anything applicable. I even tried to install the Wikimedia version of this extension and that worked fine (although that version doesn't have all the function I want so I'd rather have this one.) Please help. --Thing 1 23:44, 30 August 2011 (UTC)

I am on a 1.16.2 install. I found that the trunk version worked and not the 1.16.x version. --Thing 1 04:39, 31 August 2011 (UTC)

Variables

Is there a conflict between this and Extension:Variables? In particular, it seemed that DPL was blanking variables, causing an error message like this, and it was resolved by having the DPL variable declared first before the total variable (like this). --Sigma 7 17:07, 27 September 2011 (UTC)

Question about "includematch"

I use this great extensions in two of mine wikis. In the last times, i have some problems with includematch. My Wiki is about Final Fantasy XIV Online, for info ;)

NPCs are selling some Items, the item goes in the category:example sells from NPC. Now, some NPCs sells example-head, examplefeed, example-earring. If i create now the Article examlpe, i use this DPL:

{{#dpl:
|category = {{SUBPAGENAME}} sells from NPC
|namespace =
|includepage = {Sellsrow}:Price, {NPC} dpl Zones
|includematch =  /\s*Item\s*{{=}}\s*{{fixapos|{{fixtick|{{fixparen|{{SUBPAGENAME}}}}}}}}/si
|format      =,,\n
|table       =class="SE-Heaventable sortable" style="width: 100%;",Name,Preis,Region
|columns=1
|rowcolformat= style="background-color: transparent; width: 100%;"
|tablerow = %%,%%
|suppresserrors=true
}}

Here i use the _Template:Sellsrow to get the Price and the Template:NPC dpl Zones to get all other datas. In the Template:Sellsrow, i define Item. Thats why my includematch say get where Item = {{SUBPAGENAME}}. So, my Articles shows me now in the Table all sellinginformations about:

• example
• example-head
• examplefeed
• example-earring

i try'd some other includematch variations like this:

{{#dpl:
|category = {{#if: {{{Name|}}}|{{{Name|}}}|{{PAGENAME}}}} sells from NPC
|namespace =
|includepage = {Sellsrow}:Price, {NPC} dpl Zones
|includematch =  /\s*Item\s*{{=}}\s*{{#if: {{{Name|}}}|{{{Name|}}}|{{PAGENAME}}}}/si
|format      =,,\n
|table       =class="SE-Heaventable sortable" style="width: 100%;",Name,Preis,Region
|columns=1
|rowcolformat= style="background-color: transparent; width: 100%;"
|tablerow = %%,%%
|suppresserrors=true
}}

but at least, i have allways the Same problem. It shows me all what that NPC have, where example is in :\ The only what i want to see, is the Data for example >.< Someone knows how i can fix it? Yukii 12:52, 17 October 2011 (UTC)

Warning about $maxResultCount

Just as a heads-up, $maxResultCount is not a limit on DPL's results, but a limit on the amount of rows pulled from the database. That is not the same thing. For example, the DPL query...

<DPL>
includematch=/\|\stemplate-attribute\s=\svalue/s
titlematch=Foo%
category=Foos
</DPL>

...will first pull all pages beginning with "Foo" in the category "Foos" from the database, and only then check for the includematch pattern. In other words, if $maxResultCount is 500 and you have 800 Foo% pages in the Foos category, even if just ten of those match your includematch pattern, you will probably not get all ten.

Our solution was to remove the limit entirely ($allowUnlimitedResults = true), because our wiki is private and we have a strong control over authorship.

Your mileage may, of course, vary. -pinkgothic 13:32, 30 November 2011 (UTC)

Does not work with mediawiki 1.18

On upgrade from mediawiki 1.65 to 1.18, DPL stopped working. I downloaded the latest version from Semeb website. But still does not work. The error is:

Fatal error: Call to a member function addMessages() on a non-object in xxxxxx/extensions/DynamicPageList/DPLSetup.php on line 1163

Help! Jonathan3 00:49, 11 December 2011 (UTC)

Try this... find the error line and it should be this piece of code or something similar:

        foreach( DPL2_i18n::getMessages() as $sLang => $aMsgs )
        {
            $wgMessageCache->addMessages( $aMsgs, $sLang );
        }

In MW 1.18 $wgMessageCache is deprecated so just comment out all those lines. It should work ok after that. --Paracelsus 22:50, 12 December 2011 (UTC)

But that won't add the messages to the cache... --Subfader 08:04, 13 December 2011 (UTC)

Better question is wtf is the extension doing messing around with the message cache by hand... Bawolff 19:21, 13 December 2011 (UTC)

I commented out those lines. Now it gives me the following error: Fatal error: Call to private method Title::prefix() from context 'DPLMain' in xxxxx/extensions/DynamicPageList/DPLMain.php on line 2631. What next? :-) Jonathan3 22:34, 18 December 2011 (UTC)

I also commented out the following lines:

            if ($bShowNamespace)
                //Adapted from Title::getPrefixedText()
                $sTitleText = str_replace( '_', ' ', $title->prefix($sTitleText) );

I'm not sure if everything works fine now, but at least the error message disappeared --82.57.155.239 21:34, 25 December 2011 (UTC)

*FIXED* Removing the lines above fixed it. I also found the following page which may be of interest (and which includes a replacement for the missing lines): Special:Code/MediaWiki/86335 Thanks everyone Jonathan3 23:15, 27 December 2011 (UTC)

I only saw a replacement for the second set of lines you had comment out, is that correct? Also, does this them restore the adding messages to the cache? Thanks! Ncarty97 16:36, 26 January 2012 (UTC)

2012

Null edits (or dummy edits) required for updating DPL listing

The wiki I administer makes a huge use of DPLs for constructing lists of pages and controlling workflows--very well might I add.

One problem that I have perennially run into however is the need to execute a null edit in order for pages to properly show up in a DPL when the DPL is grabbing based on, for instance, page category. What I don't understand is that when accessing the page in question the category is correct, but the DPL listing the page will not include the page in its list until executing a null edit on the page. I'm fairly knowledgebale about this extension but I have not come up with a solution to this problem. I've even tried using updaterules to "touch" the page when the list is built, but that feature does not seem to be usable at this point.

Since the page shows the correct category, and the job queue is empty, I can't actually figure out why this is happening. The only thing that I can think of is that the DPL is stored in a cache; however, that should not be causing this since cached results are supposed to be disabled by default. I do have MediaWiki parser cache set to enabled as well as file cache, but disabling these seems to have no effect on the symptom. Any thoughts on this?    Thorncrag   18:40, 12 January 2012 (UTC)

I may have posted too soon; I completely disabled caching across the wiki and this seems to have resolved the problem altogether. This works for now, although from a scalability perspective I'm not sure.    Thorncrag   19:20, 12 January 2012 (UTC)

I think I posted too soon again. I think disabling cache only caused an update, but null edits are still required. I can't seem to find a way around this.    Thorncrag   16:39, 1 February 2012 (UTC)

"skipthispage" - not bolded when created by DPL

Hi! I'm working through the book MediaWiki and Beyond. Great book, but I've run into something that doesn't seem to be working. In the book it says that if you use the 'skipthispage' variable and set it to false, not only will the page you are on show up in your list (in this case a navigation list), but since its pointing to itself, it will default to bolded text rather than a link. I don't seem to be able to get that behavior though. If I put a link to the page within itself, that will bold and present just as text, but not when it comes through the dpl command. Any ideas why? Thanks! Ncarty97 20:41, 1 February 2012 (UTC)

Confirmed. Never worried about it tho. --Subfader 23:39, 1 February 2012 (UTC)