Wgraph:Bug Reports Archive

From FollowTheScore
Revision as of 15:08, 21 July 2007 by Gero (talk | contribs) (New page: .{{subst:DPL:Bug Reports Archive}})
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

.This is an archive of old bug reports on DPL.

If you want to report a new bug, please go to the article for new DPL:Bug Reports!

Contents


URL in special page should use Localsettings parameters

You create some URLs in the special page, for instance to reset the DPL, you do
<a href=../index.php/Special:DynamicPageListSP>reset</a>

But I think this path depends on each installation, and using "$wgArticlePath" could be wiser.

Certainly, yes. Will be changed in 1.2.2 Gero 00:20, 22 June 2007 (CEST)

Returning page itself

DPL appears to never return the page that includes the DPL code. For example, {{#dpl:titlematch=%Bug%}} gives

On any other page, this page is returned. This doesn't seem to be desirable behavior.

Answer

Indeed, DPL always skips the page containing the DPL statement itself. Older versions which returned this page led to undesirable situations, to loops and to unwanted results. Maybe it could be made configurable because it depends on the discipline and design of the authors who write dpl scripts whether it seems acceptable (or even better as you pose) to include self references in the result.

You can easily comment the line out which blocks self references. 217.111.20.10 11:41, 12 June 2007 (CEST)

I can understand that there might be technical issues involving loops and such, but I can't imagine that the typical situation is where one would want to explicitly exclude the current page. It seems like it'd be easy to remove the current page using nottitlematch={{PAGENAME}} but there is no way to do the reverse and to include the current page. I don't know which line to comment out in the code and I'd rather not do it if there other issues like infinite loops. By the way, the application that I need this for is for a way to auto-summarize a page. At the top of a page, I want to auto generate a summary of the templates being used from that page. So moving the summary to a different page is not an option for this purpose.
In the main source code file (the really large one ;-) there is a comment which explicitly says : "block recursion". You can try to comment out the if statement that immediately follows.
If you want a list of templates being called from the current page you might want to have a look into the mediawiki source code. When you edit a file these templates (including those which are indirectly referenced) are shown by the mediawiki software. So there must be a functionality to calculate that list... But I don' t think it can be done without programming. Gero 18:26, 13 June 2007 (CEST)

glitch in Special:Allmessages

Your code is printing a warning upon loading Special:Allmessages. Just FYI.

Resolved

Obviously the callback needs to point to a static function. Now the error should no longer occur.

Gero 08:59, 6 May 2007 (CEST)

DPL SP hardcoded path

Apparently, the special page path in the "extension" folder is hardcoded to be "DynamicPageList". In my config, it was DynamicPageList2, see apache logs below.


[Wed May 02 11:42:28 2007] [error] PHP Warning: require_once(D:\\websites\\mediawiki/extensions/DynamicPageList/DynamicPageListSP.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in D:\\websites\\mediawiki\\extensions\\DynamicPageList2\\DynamicPageList2.php on line 116, referer: http://localhost/wiki/index.php?title=Country_code%28IATA%29&action=edit


[Wed May 02 11:42:28 2007] [error] PHP Fatal error: require_once() [<a href='function.require'>function.require</a>]: Failed opening required 'D:\\websites\\mediawiki/extensions/DynamicPageList/DynamicPageListSP.php' (include_path='D:\\websites\\mediawiki;D:\\websites\\mediawiki/includes;D:\\websites\\mediawiki/languages;.;C:\\php5\\pear') in D:\\websites\\mediawiki\\extensions\\DynamicPageList2\\DynamicPageList2.php on line 116, referer: http://localhost/wiki/index.php?title=Country_code%28IATA%29&action=edit

Reply

Indeed you can remove the path completely from the require_once statement as the SP-file is in the same directory. The next version of DPL will contain that bugfix. -- Gero 19:59, 2 May 2007 (CEST)

LoadTest B php error

LoadTest B on this site shows "Notice: Uninitialized string offset: 15 in /www/htdocs/w0057617/dpldemo/extensions/DynamicPageList/DynamicPageList2Include.php on line 348". Current version is DPL 1.1.5

Bug Fix

The bug was fixed (1.1.6). Only line 348 had to be changed. The error only happens if you use the same template for DPL as is used in the original article. --Gero 08:26, 2 May 2007 (CEST)

Cannot use variable %DATE% in 1.1.0

I installed DPL as per instructions on this site, but all I could get was the 1.1.0 release (where are the older releases?). On this version, I cannot use the variable %DATE% on listseparators (the text %DATE% appears verbatim). I will post the code I'm using here:

200.136.161.153

<DPL>
  namespace      = News
  ordermethod    = firstedit
  order          = descending
  count          = 5
  addeditdate    = true
  mode           = userformat
  shownamespace  = false
  includepage    = *
  mode           = userformat
  listseparators = ,%TITLE% on %DATE%,,
  inlinetext     = <hr class="newsSeparator"/>
</DPL>

SOLVED editing DynamicPageList2.php

I don't know if this is a problem with my own installation -- it seems the files hosted on this server (http://semeb.com/dpldemo/index.php?title=DynamicPageList2.php&action=edit) have the following lines around line 2245:

if ($article->myDate != '') $sTag = str_replace('?TE%',$article->myDate,$sTag);
else $sTag = str_replace('?TE%',$wgLang->timeanddate($article->mDate, true),$sTag);

I changed the ?TE% to %DATE% and it worked:

if ($article->myDate != '') $sTag = str_replace('%DATE%',$article->myDate,$sTag);
else $sTag = str_replace('%DATE%',$wgLang->timeanddate($article->mDate, true),$sTag);

200.136.161.153.

Comment

Thank you very much for bringing up this error.

Indeed the php source file is corrupted.

I used a procedure to upload the source code as wiki text automatically and this procedure mis-"translated" character sequences like "%CA" or "%DA" to unicode characters. This problem exists since version 1.0.1.

Please use the ZIP archive to download the source code. The above problems do not exist in the ZIP file. --Gero 21:14, 18 April 2007 (CEST)

Extra line at end of DynamicPageList2.i18n.php

There's an extra blank line at the end of DynamicPageList2.i18n.php which breaks some stuff on my wiki as it adds an extra line to the beginning of all requests and creates malformed responses. Removing the extra line fixes it.

Reply

I had noticed your comment on that issue. So I deleted these blank line already. Please verify that the most recent version (1.0.8) of the sources now works correctly when you download them (I suggest to use the ZIP archive) right as they are. Thanks for reporting that strange behaviour. 84.59.31.28 19:39, 9 April 2007 (CEST)

Someone broke "Test linksto"

Question

Apparently it's badly broken...

Answer

Somebody tried to use the FULLPAGENAME macro in combination with parser extension mode (i.e. using the <DPL> tag). As the manual explains macros can ONLY BE USED IN PARSER FUNCTION mode, i.e. if you want to use macros as arguments you will have to use the double curly braces syntax to invoke DPL, like {{#dpl:..|..|..}}.

Nevertheless this is no excuse for DPL to come up with a PHP error. Now (rel. 1.0.8) there is at least a normal error message. Besides that I restored the old version.

84.59.31.28 19:41, 9 April 2007 (CEST)

Cannot get %CATLIST% to work

Question

  • See Test calendar.
  • Btw, the variable %REVISION% is missing in the manual on listseparator.
  • FYI, in Test calendar, I am trying to get DPL handle an event list, as most of the calendar extension in Mediawiki are anyway using Article name tricks/category tricks, so DPL should be able to do that. --Ycombarnous 11:28, 25 March 2007 (CEST)

Answer

  1. Thanks for the note on %REVISION%. I added the missing piece of information.
  2. If you want to see categories or if you want to use the %CATLIST% variable you will have to set "addcategories=true"; the reason is a performance optimisation; categories will only be queried from the database if the user declares that he needs this information. I made an approprioate change to your example.
  3. Your calendar example looks quite nice. Is there something DPL could learn to make the task of creating an event list easier?

--Gero 22:43, 25 March 2007 (CEST)

Question(2)

  • Probably something that I will miss is a "mode" that just outputs a count(*) of the results of the DPL.
  • I am almost done, see Test calendar. What I cannot figure out is how to create an anchor within "listsepators", see the DPL on the page.

Answer(2)

To get the number of hits you just have to use "mode=userformat" together with "resultsheader=%PAGES%". The variable %PAGES% holds the count(*) and is substituted by its value in the resultsheader. Maybe a little too well hidden in the manual ...

What do you mean by "anchor"? Inserting native html? That would require an html tag around the anchor and you must activate that feature in the LocalSettings ...

--Gero 21:29, 27 March 2007 (CEST)

TOC issue

Question

When I include below code, I get a TOC without the heading 2 titles("my title", "my title2") included, any idea why (Mediawiki 1.9.2, DPL 0.9.6) ?

==My title==
<DPL>
  category =-category1
  category =-category2
  category =+category3|category4
  includepage=definition
  ordermethod=category,sortkey
  headingmode=H3
  mode=userformat
  listseparators=¶{|class="sortable" width=100% border=1 ¶|-bgcolor=#cccccc ¶!Report name ¶!Definition  ¶|-,¶|-¶|[[%PAGE%]] ¶,¶,¶|}
  secseparators=¶|
</DPL>
==My title2==

Answer

Could you post a link to your website or modify the above example so that it works with the demo pages which are installed here at this wiki?

Generally there is some logic in the transclusion to handle TOC generation, so there may be a reason for that behaviour. --Gero 11:05, 1 March 2007 (CET)

Answer (2)

Please see my answer to #Category display mode. Maybe this solves your problem. --Gero 11:41, 2 March 2007 (CET)

Cannot reproduce simple example with dpl parser and sections

Question

When trying to make the simple example work as a parser function on my installation, and using sections instead of template params in includepage, I do not get the expected output.

{{#dpl:category=Fictitious country
  |includepage=section1,section2,section3
  |addpagecounter=true
  |mode=userformat
  |listseparators=\n{{(!}} class=sortablewikitable id=123
    \n!Country
    \n!Official Name
    \n!Capital
    \n!Dial Code
    \n!History
    \n!Religion,\n{{!-}}\n{{!}}[[%PAGE%]] (%COUNT%),,\n{{!)}}
  |secseparators=\n{{!}}
}}

Answer

Thank you for reporting that problem. Unfortunately the transclusion of sections only worked if you had LabeledSectionTransclusion installed besides DPL. This was corrected with DPL 0.9.7. See the "revolution" column in Example 1.

Question (2)

Above feature is cool, but I actually had LST installed. I created 2 examples based on your site.

  • This one does not work
{{#dpl:category=Fictitious country
  |includepage=president,revolution
  |mode=userformat
  |listseparators=¶{¦ class="sortable wikitable" 
    ¶!Country
    ¶!President
    ¶!Revolution,¶¦-¶¦[[%PAGE%]],,¶¦}
  |secseparators=¶¦
}}
  • But this one does work
<DPL>
  category=Fictitious country
  includepage=president,revolution
  mode=userformat
  listseparators=¶{¦ class="sortable wikitable" ¶!Country ¶!President ¶!Revolution,¶¦-¶¦[[%PAGE%]],,¶¦}
  secseparators=¶¦
</DPL>

--Ycombarnous 14:27, 2 March 2007 (CET)

Answer (2)

I am afraid the situation is a bit more complicated:

Please try to put each of your queries into a separate document. Then both of them work as expected (at least that´s what I observed). If you put two copies of the same DPL statement into a separate article only the #dpl version will show the correct results twice. The version with the user tags will only show the results once. Right? Can you please confirm this before I go deeper into research ;-) btw.: It would be nice if you could use a user page with your name and put a link to your wiki/DPL-installation into the Sites using DPL article. --Gero 12:07, 2 March 2007 (CET)

Answer (3)

Meanwhile I found the reason for the bug and corrected it. The latest version 0.9.8 now behaves correctly, see Test section inclusion. -- Gero 16:37, 2 March 2007 (CET)

PHP warning

Question

Apparently allow_call_time_pass_reference is deprecated in PHP 5.2.x, but DPL makes use of it. Any plan to remove this dependency?

Answer (1)

I wasn´t aware of that. Can you tell me in which context you get the warning? Is there an option in php to check for this kind of deprecated feature? --Gero 17:50, 20 February 2007 (CET)

Question (2)

; Whether to enable the ability to force arguments to be passed by reference
; at function call time.  This method is deprecated and is likely to be
; unsupported in future versions of PHP/Zend.  The encouraged method of
; specifying which arguments should be passed by reference is in the function
; declaration.  You're encouraged to try and turn this option Off and make
; sure your scripts work properly with it in order to ensure they will work
; with future versions of the language (you will receive a warning each time
; you use this feature, and the argument will be passed by value instead of by
; reference).
allow_call_time_pass_reference = Off

Answer (2)

  • I made some changes to the source code and now the warnings should be gone.
  • Please let me know if there is still a problem.
  • I could not reach the bugzilla site (temporary problem?)
  • Version 0.9.6 of DPL contains some new features. Please try.

-- Gero 15:56, 26 February 2007 (CET)

Question (3)

(Newbie Question) I'm using 0.9.6 and observing the following warning regularly:

Warning: Cannot modify header information - headers already sent by 
(output started at /var/apache2/htdocs/wiki/extensions/DynamicPageList/DynamicPageList2.i18n.php:729) 
in /var/apache2/htdocs/wiki/includes/WebResponse.php on line 9

Is this 'normal' behaviour? Any recommendations on how to correct this? --MU 13:29, 26 March 2007 (AEST)

Answer (3)

So far I have not heart of such an error message. It sounds like a flushing problem of your webserver. I assume the problem will still be the same with the latest version, but nevertheless you should try to use that one. --Gero 11:24, 26 March 2007 (CEST)

I encountered an identical error when I set up my DPL today. I read line 9 of WebResponse.php and tried to comment out line 9, which appeared to take a header string variable and replace it. The errors went away, but pages I tried to save after that point with a DPL function in them would go blank. Subsequent pages I tried to access would also be blank. Uncomment that line, the errors come back. I read the DPL PHP file, the one with i18n at the end of it and searched for line 729. Line 729 was blank, as were two others above it. I removed those blank lines, and everything is working now. I can use DPL, pages no longer appear blank, and the errors are gone. Why that worked, I don't know, but I'm happy it did.

Syntax error

Question

I get the following error message.

from within function "".
MySQL returned error "1064:
You have an error in your SQL syntax.
Check the manual that corresponds to your MySQL server version for the right syntax
to use near 'USING utf8)), '_', '') as sortkey FROM `wikipage` INNER JOIN `w (db500.perfora.net)".
My System Information
MediaWiki v1.9
Php5
MySql 4.2

I looked at the syntax rules for my MySQL version, but couldn't find any syntax error (FYI, even though I have been reading a lot about programming lately, I am not a programmer). Is this because I need MySql 5.0 or higher? If so, is there any way I can disable the specific codes without affecting other functions? I sort of tried to disable the "empty string" sortkey, but was not successful. I would appreciate your help very much.Kohyin 00:50, 15 February 2007 (CET)

Answer

Hello Kohyin, please write down the dpl statement you have been using. Try to create a page in this dpldemo wiki (named bug-sortproblem or so ..) which demonstrates the effect. Then I will check. Gero 08:43, 15 February 2007 (CET)

Your problem should be gone with the latest version (0.9.4) as UTF8 conversion of the sortkey is no longer enforced. --Gero 07:04, 17 February 2007 (CET)

Subcategories in DPL result sets

Question

For some reason when I try to list a category that has subcategories instead of creating a list they are all added as actually categories to the page. Weakmassive 23:45, 13 February 2007 (CET)

Answer

This should be solved in the latest version. Now you will (by default) get a link to the categories´ pages in your result list. You can change this behaviour using a new parameter called "escapelinks". The same problem/feature applies to images. By default you get a link to the image; with "escapelinks=false" you will see the image directly. --Gero 16:22, 16 February 2007 (CET)

Thanks. This works now with the latest version.--Weakmassive 15:47, 16 February 2007 (CET)

Sort problem

I'm also having the same problem with sortkey as I did in previous versions. Any ideas? --Weakmassive 23:45, 13 February 2007 (CET)

Answer

Please provide an example of your DPL statement here in this wiki. I am sure we can help. Make sure you are using the latest source from this wiki (0.92) when reporting bugs.

Are you looking for something like Test headingmode? --Gero 16:07, 15 February 2007 (CET)

The page I'm having problems with is here. I want the Cities sorted alphabetically, so I want to use this code:
<dpl>
category=Cities
ordermethod=category,sortkey
headingmode=H2
mode=ordered
shownamespace=false
</dpl>

...but I get that error mentioned before. So I've resorted to using "ordermethod=category,lastedit" for now. I'm using DPL 0.92. Thanks for looking into it.--Weakmassive 15:47, 16 February 2007 (CET)

I created a similar structure as you have and could not get any error, please see my example on Regions. --Gero 20:47, 16 February 2007 (CET)
Thanks for setting that up. Ya, looks like it works fine on here. Perhaps something is messed up with my database? Do you have any idea what this error could mean?
A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "". MySQL returned error "1267: Illegal mix of collations (latin1_bin,IMPLICIT) and (utf8_general_ci,IMPLICIT) for operation 'ifnull' (internal-db.s2603.gridserver.com)".

Thanks. --Weakmassive 03:18, 17 February 2007 (CET)

I think your database was not set up in UTF8 mode (which is recommended nowadays). Version 0.9.4. (available now) does no longer insist on UTF8 conversion of the sortkey. So it should solve your problem. There are two new features in 0.9.4 which might be interesting for you: Putting a "-" before the category name(s) will prevent it/them from appearing in the headings. Thus, using categories=-Cities you can avoid to have the whole list of "Cities" amongst the country groups. See the Regions example. Setting "headingcount=true" will give you a text line with the number of entries in a heading group (as before); by default this line is now no longer shown.
--Gero 07:02, 17 February 2007 (CET)
Wow, thanks so much! It works perfectly now. I was wondering about preventing "Cities" from showing up, but figured I wouldn't bug you about it. Thanks for adding that anyways. --Weakmassive 17:26, 17 February 2007 (CET)

Performance

Question

We have a lot of definitions in a Category called "Definitions" (about 500 pages). Each definition has got labeled sections for abbreviation, example, etc... (see below).

With a small wiki and reasonably new hardware, this takes 10 secs to display. Is there anyway to go faster to you ?

We want to look at the option of fetching template values, as in your "simple example" instead of just using labeled section transclusion. Could that help on performance ?


<DPL>
  category=definitions
  includepage=definition,abbreviation,example,DB table,DB Field
  mode=userformat
  listseparators=¶{|class="sortable" width=100% border=1 id=123 ¶!Field name ¶!Definition ¶!Abbreviation ¶!Example ¶!DB Table ¶!DB field ¶|-,¶|-¶|[[%PAGE%]] ¶,¶,¶|}
  secseparators=,¶|,,
</DPL>

Answer

The extension is called dynamic page list - which means that all processing happens when you access the page containing the DPL statement. In your case the script must open all 500 articles and parse them to extract the desired chapters. I have response times around 1-2 seconds with ~50 articles of similar structure. So the 10 seconds you mention are quite plausible.

If you used the template value mechanism I would expect better performance. The wiki text is loaded also in this case, but only the very small text part containing the template call is expanded (using an alternate template). Depending on the size of your articles I would hope for some performance gain. Could you please let us know?

Is it necessary to have the list created each time a user asks for it? (That depends on the rate of changes in your application). You may want to create a daily copy automatically and store it at some place on your web server (using wget or so). Then you could create a wiki page which points to that offline copy and has a link to the page with the real report... --Gero 09:11, 15 February 2007 (CET)

Talk on DPL2 (metawiki)

Proposal

we should put a copy of Talk:DynamicPageList2 here. --Ycombarnous 11:24, 13 February 2007 (CET)

Answer

There is a lot of old stuff there which is not really necessary to read in most cases. So I think a link to Talk:DynamicPageList2 should be enough. --Gero 09:26, 15 February 2007 (CET)

Template not evaluated

Problem

When you have a blank after {{ the template is not evaluated.

Example: Nigunda Test
Result: Example 1

Possible solution: http://bugzilla.wikipedia.org/show_bug.cgi?id=9052

Answer

Yes, sad to say, spaces at the "wrong" places led to non-evaluation. Now (version 0.9.6) it should be solved. -- Gero 15:51, 26 February 2007 (CET)

Category display mode

Problem

When upgrading to the version 0.9.6 of DPL, categories were displayed with a TOC and [edit] section, is there an option to bypass this?

Sample:

Extension:DynamicPageList (DPL), version 3.2.1: Error: The paramater 'mode=category' must be used with 'ordermethod=[ sortkey | title | titlewithoutnamespace ]'


Extension:DynamicPageList (DPL), version 3.2.1: Warning: No results.

Answer

For the moment you can use a simple workaround: Use the "resultsheader" to suppress TOC generation. As expected you will not see the TOC, but you won´t get a TOC for your document either. Strangely enough, this can be compensated via a TOC statement somewhere in your document outside the DPL statement. Don´t ask me why it works like that (I had to find out this behaviour of mediawiki software by trial end error...). Interstingly you can also use the NOEDITSECTION pragma to prevent the edit buttons; this applies only to the DPL result and there is no side effect on the document as a whole as you can see.

So:

  • block the TOC within DPL
  • set a location for the TOC (if you want the TOC to be shown in the page containing the DPL query)
  • block the section edit links in the resultsheader in the same way

The following example does exactly that. Note that I had to insert a TOC statement at the beginning of this "Bug Reports" article to prevent the normal TOC from disappearing. Note that the two pragmas should be written directly after oneanother, so you have four underscores between the two words..

Extension:DynamicPageList (DPL), version 3.2.1: Error: The paramater 'mode=category' must be used with 'ordermethod=[ sortkey | title | titlewithoutnamespace ]'


Extension:DynamicPageList (DPL), version 3.2.1: Warning: No results.


Additional remarks:

  1. I plan to set these two pragmas automatically if a DPL query is using mode=category.
  2. These pragmas are also useful in combination with other DPL queries.
  3. the trick explained above has been used in Example 1
  4. The principal reason why mediawiki feels tempted to generate a separate TOC for the output of DPL is not clear to me.
  5. This mediawiki behaviour is not specific to mode=category; as soon as you use DPL to output headers (either as native html tags or in wiki syntax) you will get this effect. It is only most prominent with category listings because every "first letter" becomes a heading of level 3 in that mode.
  6. Using the NOTOC pragma has the effect that the automatic decision of mediawiki whether to generate a TOC (which usually happens only if there are more than three chapters in an article) is overwritten. So you will either get always a TOC or never (depending on whether you place a manual TOC pragma in your article outside the DPL statement or not).

--Gero 11:50, 2 March 2007 (CET)

Ok many thanks :) --83.203.42.222 14:49, 2 March 2007 (CET)

wrong text included

Question

Hello, I made a test page for the extension directory. As you can see, I would like to include text of the field "status". The Parser Extension does not have that field, but some text gets pulled. Feel free to mess around. --GunterS 20:39, 4 March 2007 (CET)

Answer

There was a small bug in DynamicPageList2Include.php which now has been fixed. NOte that the vers8ion is still 0.9.8 (patch1). -- Gero 07:52, 5 March 2007 (CET)

secseparators

Question

If I use

secseparators=¶|ABC-,,¶|DEF-,,¶|EFG-,,¶|FGH-,,

I would expect the Term ABC-, DEF- etc. to appear in the fields, which they do not.

Using

 secseparators=¶|ABC-

I would expect ABC- in all fields. (more sense makes ¶|$nbsp; to elimate not showing empty cells.

See here. --GunterS 20:39, 4 March 2007 (CET)

ok, I see. If you include a template like "MyTemplate dpl", only the first separator is take, because then the template takes over. But if the page does not contain the original template, the template dpl will not get called. In this case I need a different text to display (blanks should be eliminated, see here.

Answer (1)

As you said the secseparators correspond to the items in the includepage= list. As far as I understand you want to be able to call a template in case the specified template in the includepage directive is not used in the original article. We could

  • call the dpl template and set a special parameter indicating that this is a default call
    • this would require the handling of that parameter in each and every DPL template
  • call a default template (which could be set by another parameter)
    • we would have to pass the name of the calling page and the name of the original template as this default DPL template would have to handle ALL templarte inclusions from all templates used in your query
  • we could call a template called like the DPL template plus the suffix ".default"
    • everybody writing a DP statement with at template based inclusion would then need such a template in case it could happen that some of the articles in the result set do not include the desired template.

I have a tendecy towards the last solution. In your case it would mean that you have to provide a template called "Template:Extension double.default" which would be called in case there is no invocation of "Template:Extension" in an article. The .default template gets %PAGE%, %TITLE% (see the manual) as variables but nothing else.

How do you think about it?

--Gero 09:03, 5 March 2007 (CET)

Yes, the third and implemented solution works like a charm. I am not sure about the word ".default" itself, because it is actually not called by default. Maybe ".missing" would be clearer. --GunterS 18:57, 6 March 2007 (CET)

The new template ("*.dpl.default") gets called when there is no reason to call the real "*.dpl" template. This is close to the semantics which are normally implied with "default". But we can change it if you like (before the feature gets more widely used). --Gero 21:29, 6 March 2007 (CET)

Answer (2)

It proved to be very easy to implement the "default template approach", so I created version 0.9.9. which has that feature. If you define an empty template (just containing the pipe symbols and the non breaking spaces) your table will look properly. Do you plan to make that list avalaibel on the mediawiki website? It would be very useful ... --Gero 10:32, 5 March 2007 (CET)

Would like to, but the extension itself is missing :( --GunterS 19:00, 6 March 2007 (CET)

Maybe, you want to join in at the discussion Extension Matrix.

unpredictable result when editing an article which is included by dpl2

question

When I edit such an article, I get one of:

  • Fatal error: Maximum execution time of 30 seconds exceeded in mediawiki/includes/Revision.php on line 532
  • modification conflict
  • white page

The article is still saved, but it's quite annoying. The dpl2 code used is like:

 <DPL>
  category=Philosophie_générale_licence,_semestre2,_2006-2007
  includepage=*
 </DPL>

I use mediawiki-1.8.4 and dpl2-1.0.0 . With dpl2-0.9.9, i had similary problems, but more critical: it would freeze if I edit the page containing the dpl code if I close the dpl entity.

answer (from another user)

The timeout is probably due to your page processing being too long. I guess including a whole set of pages into one will end up in a very long processing time for mediawiki (it will need to process the wikitext of every pages included).

Why don't you rather create a table with a link to all pages, and a section describing the content of it, this will be much faster, and I would say much easier for your users to parse.

Being a French native, the title of your category suggests that the length of the article is quite large, which may confirm the diagnostic.

The biggest page in its final form is about 700 lines, included from 11 pages (so about 65 lines per page). This represent a lesson, I would let the user choose between seeing it all or just a date. Maybe it's a bit to big, but I don't think this would do the loading reaching 30 sec... (it has taken 0.886 secs. to be served when just viewing the page). I'm gonna see if I can tweak the mediawiki timeout, anyway.

I think this may be of some interest for other users as well. With DPL being used more widely we need some rough statements about what one can do and what one should better not try to do. I have experience with two-digit numbers of short articles (< 5kB); creating a table which contains some hundred bytes of two or three chapters from each of theses articles runs with acceptable performance (< 5 sec).

I suggest that we produce (or generate) some pages on this wiki which could serve as a reference perfomance test. Any volunteers? I could provide a separate namespace (Test:) for these "articles" ...

--Gero 15:06, 14 March 2007 (CET)

I'm the one who submited the former report. I'm interesting in those tests, but when the trouble mentionned happens, I have a big server load, varying from 50% to 100% in htop mesurment. Can your server afford many tests that may produce such a load in a while?

Kik 16:10, 14 March 2007 (CET)

I put up a "modest" load test, see LoadTest. I was quite happy with the response times considering the amount of processing that is needed. How do you think about it? Extracting 3 of 20 chapters from 100 documents with a total of 6 MBytes of raw text takes obviously less than 10 seconds on a cheap (8 €/month) shared server (see http://all-inkl.com/eng/index.php?cna=webhosting&cnb=privatplus )

--Gero 13:24, 16 March 2007 (CET)

hum ok, so it's not a size-related problem, because the biggest page I have (after inclusions) is 76ko. The problem happens just after saving, while the page is shown (just before, in fact), but it not happens when showing if we haven't edited it before.

The most surprising is that this happens when editing a page which not contains some dpl code, but which is included by dpl elsewhere. I may add that it not happens on articles that are not dpl related :)

Maybe somebody has the same trouble? I'm gonna use your testing namespace in order to see if I can reproduce it in here.

Kik 14:29, 16 March 2007 (CET)

solution

Hello,

I solved my problem. It's eventually not dpl related, but it can happen to dpl users, so I post it here.

The timeout error issue happened only with dpl related pages, so I thought it was a dpl issue and I wrote another plugin just to be the dpl functions I needed. And this other plugin made the same errors... -_-

I searched for a while and could finally fix the bug when using the maintenance script maintenance/rebuildall.php . This verify the integrity of the database and repair it (no loose of data).

I think the problem was that I have done lowlevel queries on the database in order to change some usernames, and maybe because I made a lot of mysqldump/restore while changing of servers.

Hope this will help.

Kik 14:17, 3 July 2007 (CEST)

Automatic show category

Question

When I create a dpl-query on a page the result shows also the categories. But I don't want them to show. How can I turn this off? This is the websitepage i put the dpl query on.

Answer

First my congratulations to your nice website! Could you put a link to our DPL:Websites using DPL page?

If you include a CHAPTER which contains a category assignment, the dpl page will become part of that assignment, too. For instance "W.H. van Leeuwenlaan" has its category assignments within the "description" chapter. On the other hand, Meeslaan has its assigments to categories in another chapter ("fountains and literature"). SO, if you create a list which only contains Meeslaan your dpl page will NOT be assigned to any category. As soon as "W.H. van Leeuwenlaan" is in the list, the dpl article will become part of the categories.

To me the bahaviour of DPL is quite logical and I would recommend that you develop a uniform style for positioning the category assignments of your articles (maybe at the top of the articles?).

--Gero 19:22, 19 March 2007 (CET)

Reply

Thanks. It's still under construction as you could have seen. I'm still experimenting with extensions but when it's online and I'm still using dpl I will certainly put it in the list!
The behaviour to me was not quite what I expected because the page I put it in is not part of the categories it shows. It's not a straatnaam but a buurtnaam. I hope you could create a parameter that switch off this behaviour? Otherwise I have to puzzle how to create a proper list. The suggestion to put categories on the top works but i have to change a lot of pages! --BB70 07:28, 20 March 2007 (CET)

I ´m afraid I don´t quite understand. Which article is a 'buurtnaam'? And if you include a chapter of such an article (where the chapter contains the assignment to buurtnaam) why should your dpl page NOT belong to that category, too? Of what kind of parameter do you think? What exactly should it do? --Gero 09:49, 20 March 2007 (CET)
The page itself is higher in hierarchy (comparable with category) and containts a view of all pages for example here street that belongs to the neighbourhood. Neighboorhood X does not belong to the category 'street in neighbourhood X' and is not a 'streetname' as is show now. It would be nice to have the option to exclude categorynames to show in the dpl-result. --BB70 11:43, 20 March 2007 (CET)

"replaceintitle" seems not to work

I tried:

<dpl>
  mode=none
  category=Test
  replaceintitle=\Test\,
</dpl>

and it seems not to work.

--Dario 05:17, 7 April 2007 (CEST)

It works at least partly

First, you must not use a backslash as a regexp delimiter (this is a tribute to PHP syntax).

Second, due to a bug 'replaceintitle' in release 1.0.7 only worked with mode=userformat.

It works as expected

With release 1.0.8 it works:

<dpl>
  mode=none
  category=Test
  replaceintitle=/Test/,
</dpl>

Now it works:

2007/04/28 my event name
Calendar
DPL:Manual - dplmatrix
Events
Listing Redirects and Location
Resultsheaderwithcolumns
[[Test|]]
addcategories
addcontribution
addfirstcategorydate
adduser
article structure
cat listing
category hierarchy
category listing
columns
createdby
date formatting
debug
escapelinks
goal
headingmode
identical chapters
ignorecase
imagecontainer
includematch
includetrim
linksfrom
linksto
matches
matrix
mode category
numberOfArticles
offset&count
onlyinclude
redirects
regexp
resultsheader
revisions
section inclusion
shownamespace
Sort order
subcategories
table
title
uses
what links here
what links here 2
Category:African Union member states
Category:Cities
Category:Countries
Category:Events

Gero 13:08, 9 April 2007 (CEST)

Error with Calendar

Question

Hi there, Been trying to debug this now, and have found where the error is occurring.... But still have no solution ???? Can anyone help ??

Calendarerror.jpg

I have fixed this, it was because, I had placed the templates in categories, when I remove from categories its now all working fine. I am running following version

call time pass reference; cannot modify header information

I've tried to install version 1.1.1, putting the folder and its six files in my extensions folder. I used the .zip file source. I modified my LocalSettings.php file, too, and am getting this:

Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /html/wiki/extensions/DynamicPageList2/DynamicPageList2.php on line 2359

Warning: Cannot modify header information - headers already sent by (output started at /html/wiki/extensions/DynamicPageList2/DynamicPageList2.php:2359) in /html/wiki/includes/WebResponse.php on line 9

The second warning is repeated 7 times. I'm running this with PHP 5 and a freshly installed Mediawiki 1.9.3. I sthere something I can do, or should I just blame Godaddy?

Gero: I swear I saw an answer to this a couple of days ago. I got the new .zip file and installed that folder, and it works fine now. Thanks!

Reply

There should be NO such warnings any more in the current release (1.1.6). As these warnings do not occur on the dpldemo server it is hard for me to reproduce them. If you get a warning about calltime reference parsing: please give us the exact version and line #. It is easy to remove the cause once you know where the warnings occur.

-- Gero 09:14, 2 May 2007 (CEST)

Mysql pre 4.1.x

You get a mysql database error when using {{#dpl: createdby=user}}

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "". MySQL returned error "1064: You have an error in your SQL syntax. 
Check the manual that corresponds to your MySQL server version for the right syntax to use near 
'select rev_user_text from `revision` where `revision`.rev_page= (localhost)".

This is caused by the version of mysql used (<4.1.x), upgrade mysql to (>=4.1.x as stated in DPL:Manual_-_Source_and_Installation#System_requirements) and dpl works.

shownamespace=false with mode=category

This categorises the titles based on their prefixes, which looks odd when they're not displayed. I think this affects sorting too, but I can't get the example I copied to work. --80.175.250.218 13:48, 5 May 2007 (CEST)

Error with runJobs.php maintenance script

Hi, I have a problem with DPL extension, it brakes the script "runJobs.php" with this error message: "Attempt to call member function of FakeTitle". If I run the script without the DPL it works nice.

Here is the backtrace of the script:

#0 /var/www/w/includes/FakeTitle.php(18): FakeTitle->error()
#1 /var/www/w/includes/Parser.php(2448): FakeTitle->getText()
#2 /var/www/w/includes/Parser.php(2847): Parser->getVariableValue('pagename')
#3 /var/www/w/includes/Parser.php(2923): Parser->variableSubstitution(Array)
#4 [internal function]: Parser->braceSubstitution(Array)
#5 /var/www/w/includes/Parser.php(2714): call_user_func(Array, Array)
#6 /var/www/w/includes/Parser.php(2815): Parser->replace_callback('{{PAGENAME}} (D...', Array)
#7 /var/www/w/includes/Parser.php(3862): Parser->replaceVariables('{{PAGENAME}} (D...')
#8 /var/www/w/extensions/DynamicPageList/DynamicPageList2.php(807): Parser->transformMsg('{{PAGENAME}} (D...', Object(ParserOptions))
#9 /var/www/w/extensions/DynamicPageList/DynamicPageList2.php(544): DynamicPageList('?debug=0?catego...', Array, Object(Parser))
#10 [internal function]: DynamicPageList2('?debug=0?catego...', Array, Object(Parser))
#11 /var/www/w/includes/Parser.php(601): call_user_func_array('DynamicPageList...', Array)
#12 /var/www/w/includes/Parser.php(299): Parser->strip('{{En constructi...', Object(StripState))
#13 /var/www/w/includes/JobQueue.php(256): Parser->parse('{{En constructi...', Object(Title), Object(ParserOptions), true, true, 26044)
#14 /var/www/w/maintenance/runJobs.php(24): RefreshLinksJob->run()
#15 {main}

--86.213.75.164 12:12, 10 May 2007 (CEST)

Does this happen everytime you run the script? Did you start runJobs.php manually? If not please do so and check what happens. I guess it may have been a unique situation, maybe after you changed some central templates... --Gero 16:57, 11 May 2007 (CEST)

Hi, yes I run the script manually and it brakes only on some pages. When there's an error, there's a backtrace like the above one. I don't know what the problem with this :/ -86.213.75.164 21:40, 16 May 2007 (CEST)

TOC Issue and Workaround

I was having some problems with TOC generation with the DPL extension. The problems I was having are mentioned above in other sections. Basically, my problem was that I had a page which had many sections of its own, plus DPL was generating sections, and the end result was that the page received two tables of contents with the second one located where the DPL call was.

I found a workaround for this, though! This problem only occurs if you use DPL as a parser extension. If you use the parser function syntax, the TOC gets generated properly. However, you'll still have to use __NOEDITSECTION__ to suppress section editting throughout the page (unless you don't care about it). Just thought I'd share that, looking over this page I don't see this workaround noted anywhere. -- 216.146.163.228 21:49, 11 May 2007 (CEST)

Thanks! See also #Category display mode. Gero 07:28, 12 May 2007 (CEST)

‎notcategory not working :(

I am version 1.2.0 with MW version 1.10.0, see http://biodatabase.org/index.php/Sandbox#Broken_DPL

Is this my error or a bug in 1.10.0 ?


I get the following output using

category = xyz
notcategory=some such cat

%DPL-1.2.0-WARNING: Unknown parameter '‎notcategory' is ignored. Help: available parameters: addca... namespace, notcategory, notnam ...

and using

notcategory=some such cat

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


Can you help? And is posting at the bottom a no no? --Dmb 11:32, 6 June 2007 (CEST)

Answer

Please look at the following examples:
1) List of African Union member states

2) List of African Union member states without Arab League

As far as I can see everything works fine.
Sorry but I do not have to time to check your sandbox... If you are able to reproduce the error here I will help. Maybe it has something to do with the namespace; a short look at your example showed that all of your matching articles are templates.. Feel free to experiment here in this dpldemo wiki ...
Posting at the bottom is o.k.
Good Luck! Gero 08:52, 7 June 2007 (CEST)

Answer Back

Above is fine without doubt. I tried a DPL using;

category = category for non template pages
notcategory = some other category

But I get the same error; "Unknown parameter '‎notcategory'". So I don't think it is a namespace thing. Did you try DPL 1.2.0 in MW 1.10.0? If not I suggest that you have a go :-D --Dmb 13:08, 8 June 2007 (CEST)

However, its not unpossible that I installed DPL bad. --Dmb 13:11, 8 June 2007 (CEST)

DPL 1.2.0 on MW 1.10

I made a test installation of Mediawiki 1.10 and I could not reproduce the problem wioth "notcategory=". Gero 18:34, 13 June 2007 (CEST)

Thanks for your help. I'll try getting the site admins to do a re-install. --Dmb 16:04, 24 June 2007 (CEST)

Unescaped SQL being passed through PHP

Hey all, I upgraded MediaWiki to 1.10.0 this morning, and as part of the effort, I also upgraded DPL to 1.2.0. A little while later, someone pointed me to a page on the site that was broken, it had a MySQL error on it.

After poking around, we found that the problem was in the DPL extension. The problem is that parameters aren't being SQL-escaped to the back end. So if you have a parameter such as:

<dpl>
  title=Jacob's Ladder
</dpl>

DPL is throwing up when it gets to the apostrophe. The query on the back end looks like this:

SELECT DISTINCT page_namespace, page_title FROM `wiki_page` WHERE 1=1 AND page_namespace IN ('0') AND page_title = 'Jacob's_Ladder' AND page_is_redirect=0 LIMIT 500

Notice that the apostrophe in Jacob's isn't escaped as \'.

You can verify by pasting the above code in any of the pages here. (I can't save it myself because I get a database error when I try, even here. But if you have a site where some articles with apostrophes have already been entered, well, you see my dilemma...)

I haven't had time to explore all of the security implications of this yet, but that looks to me like it could be ripe pickin's for an SQL injection attack. O.O I've disabled DPL on my wiki site. I've got a lot on my plate and can't debug right now, but I'll check back now and then to see if it's fixed.

Will be solved with 1.2.1

Thanks for the bug report! The vast majority of the DPL php code escapes strings properly. Unfortunately there is a handful of points (titlematch being one of them) in the code where this was forgotten. An update will be posted soon. Gero 11:45, 12 June 2007 (CEST)

utf-8 / latin1

Database error A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "". MySQL returned error "1267: Illegal mix of collations (utf8_general_ci,COERCIBLE) and (latin1_bin,IMPLICIT) for operation 'concat' (localhost)".

I read below about someone having a similar issue that was corrected in 0.9.6 -- however, we are using utf-8 in our database. Changing the array ordermethod from a default of 'title' to 'titlewithoutnamespace' eliminated the issue (DynamicPageList2.php Line 418) -- forcing ordermethod=title brings it back, of course.

This can be seen in action here. The exact and complete contents of the page is:

<dpl> namespace=Logs ordermethod=title </dpl>

--Ratio 16:42, 11 June 2007 (CEST)

Disregard my last. Apparently there was an error in one of our tables. Still had a Latin1 in one key spot.

--Ratio 17:07, 11 June 2007 (CEST)

unexpected infinite transclusion loop error

I am experiencing an unexpected infinite transclusion loop error "%DPL-1.2.1-WARNING: An infinite transclusion loop is created by page 'IT Policies'.". I have a template named "Template:IT Policies" which is used for a menu system included on all policy pages. This template {{IT Policies}} only produces this error when called from another article with an identical name "IT Policies" which includes the template. Aside from the normal articles, which are members of four sub categories, the template itself, the main "IT Policies" article, the main "IT Policies" Category, and the sub categories all call the template with no error, only the article with a similar name? It makes no difference whether I have commented out the "block recursion" lines per DPL:Bug Reports Archive#Returning page itself or not, I like to see the current article in the menu.

I'm thinking that the infinite transclusion loop detection is producing a false positive. For now I have moved the article named "IT Policies" to "Policies" which has solved the problem, links to the old name redirect to the new and the error no longer appears

The "Template:IT Policies" articles calls DPL as followes:

 Fancy menu styling, collapsable tables and whatnot...
<DPL>
 category     = General Policies
 addpagesize  = true
</DPL>
<DPL>
 category     = Service Policies
 addpagesize  = true
</DPL>

Problem with "reset" link in SP form

It links to /$1/Special:DynamicPageListSP, I suspect it's something to do with friendly URL's, see http://www.organicdesign.co.nz/Special:DynamicPageListSP --Nad 04:54, 7 July 2007 (CEST)

Could you explain?

Sorry, but I do not understand your problem. Gero 15:24, 8 July 2007 (CEST)

List Counter doesn't work correctly

Problem

It seem that when I filter the number of item to be showed using "includematch" the following variables doesn't have a right values.

  •  %NR% in listseparators
  •  %PAGES% in resultsheader

Look like it still content value before the list is filtered.

Follow Up

I just look into the code.

  •  %PAGE% use what it get from DB (all of the item num),
  • filter (includematch) use for-next loop for what it get from DB, and selected the item based on "includematch" regex.
  • unfortunately %NR% use the for-next index counter.

I think I can fix this problem myself.

Fixing the problem

The problem is that DPL applies some special additional filtering which cannot be done in the database. Therefore 'offset' and 'count' deviate from what the user gets to see. Please post your changes to the code here. I will integrate them into the next release. Gero 23:13, 11 July 2007 (CEST)

Fixing the problem (answer)

Hi Gero, I just done some patching. No extensive test, but it works for me. This is the code: List Counter Fix

Correcting the bug fix

Hi Sarif, you used an uninitialized variable called $iRowCounter at three places. I replaced this by a reference to $this->filteredCount. Could you upload a Test file (see category Test) which demonstrates the error? I will provide the corrected version shortly afterwards, so we can both see that it works. -- 217.238.216.19 07:16, 14 July 2007 (CEST)

Test Page

Hi Gero, great. I just put some pages to demonstrate the error. Here it is: Test includematch