Difference between revisions of "Wgraph:Bug Reports Archive"

From FollowTheScore
Jump to: navigation, search
(New page: .{{subst:DPL:Bug Reports Archive}})
 
(Replacing page with '.This is an archive of old bug reports on Wgraph. If you want to report a new bug, please go to the article for '''new Wgraph:Bug Reports'''! __TOC__ __NEWSECTIONLINK__ <...')
 
Line 1: Line 1:
.This is an archive of old bug reports on DPL.
+
.This is an archive of old bug reports on Wgraph.
  If you want to report a new bug, please go to the article for '''new [[DPL:Bug Reports]]'''!
+
  If you want to report a new bug, please go to the article for '''new [[Wgraph:Bug Reports]]'''!
  
 
__TOC__
 
__TOC__
 
__NEWSECTIONLINK__ <!-- Makes it look like a talk page with + next to 'edit' -->
 
__NEWSECTIONLINK__ <!-- Makes it look like a talk page with + next to 'edit' -->
  
==URL in special page should use Localsettings parameters==
+
...
You create some URLs in the special page, for instance to reset the DPL, you do <pre><nowiki><a href=../index.php/Special:DynamicPageListSP>reset</a></nowiki></pre>
 
But I think this path depends on each installation, and using "$wgArticlePath" could be wiser.
 
::Certainly, yes. Will be changed in 1.2.2 [[User:Gero|Gero]] 00:20, 22 June 2007 (CEST)
 
 
 
==Returning page itself==
 
DPL appears to never return the page that includes the DPL code. For example, <nowiki>{{#dpl:titlematch=%Bug%}}</nowiki> gives {{#dpl:titlematch=%Bug%}}
 
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. [[User:217.111.20.10|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 <nowiki>nottitlematch={{PAGENAME}}</nowiki> 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. [[User:Gero|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:
 
 
 
[[User:200.136.161.153|200.136.161.153]]
 
 
 
<pre>
 
<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>
 
</pre>
 
 
 
===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:
 
 
 
<pre>
 
if ($article->myDate != '') $sTag = str_replace('?TE%',$article->myDate,$sTag);
 
else $sTag = str_replace('?TE%',$wgLang->timeanddate($article->mDate, true),$sTag);
 
</pre>
 
 
 
I changed the ?TE% to %DATE% and it worked:
 
<pre>
 
if ($article->myDate != '') $sTag = str_replace('%DATE%',$article->myDate,$sTag);
 
else $sTag = str_replace('%DATE%',$wgLang->timeanddate($article->mDate, true),$sTag);
 
</pre>
 
 
 
[[User:200.136.161.153|200.136.161.153]].
 
 
 
=== Comment ===
 
Thank you very much for bringing up this error.
 
 
 
<big>
 
Indeed the php source file is corrupted.
 
</big>
 
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.''' --[[User:Gero|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. [[User:84.59.31.28|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 &lt;DPL&gt; tag). As the [[DPL:Manual - General Usage and Invocation Syntax|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 <nowiki>{{#dpl:..|..|..}}</nowiki>.
 
 
 
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.
 
:[[User:84.59.31.28|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. --[[User:Ycombarnous|Ycombarnous]] 11:28, 25 March 2007 (CEST)
 
 
 
===Answer===
 
# Thanks for the note on %REVISION%. I added the missing piece of information.
 
# 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.
 
# Your calendar example looks quite nice. Is there something DPL could learn to make the task of creating an event list easier?
 
 
 
--[[User:Gero|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 ...
 
 
 
--[[User:Gero|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) ?
 
 
 
<pre><nowiki>
 
==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==
 
</nowiki></pre>
 
 
 
===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. --[[User:Gero|Gero]] 11:05, 1 March 2007 (CET)
 
 
 
===Answer (2)===
 
Please see my answer to [[#Category display mode]]. Maybe this solves your problem. --[[User:Gero|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.
 
 
 
<pre><nowiki>
 
{{#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{{!}}
 
}}
 
</nowiki></pre>
 
 
 
=== 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
 
<pre><nowiki>
 
{{#dpl:category=Fictitious country
 
  |includepage=president,revolution
 
  |mode=userformat
 
  |listseparators=¶{¦ class="sortable wikitable"
 
    ¶!Country
 
    ¶!President
 
    ¶!Revolution,¶¦-¶¦[[%PAGE%]],,¶¦}
 
  |secseparators=¶¦
 
}}
 
</nowiki></pre>
 
 
 
*But this one does work
 
<pre><nowiki>
 
<DPL>
 
  category=Fictitious country
 
  includepage=president,revolution
 
  mode=userformat
 
  listseparators=¶{¦ class="sortable wikitable" ¶!Country ¶!President ¶!Revolution,¶¦-¶¦[[%PAGE%]],,¶¦}
 
  secseparators=¶¦
 
</DPL>
 
</nowiki></pre>
 
 
 
--[[User:Ycombarnous|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 [[DPL:Websites using DPL|Sites using DPL]] article.
 
--[[User:Gero|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]]. -- [[User:Gero|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? --[[User:Gero|Gero]] 17:50, 20 February 2007 (CET)
 
 
 
=== Question (2)===
 
*I entered all necessary information (version date, error line number) at http://bugzilla.wikimedia.org/show_bug.cgi?id=8957. LEt me know if you need something else. --[[User:Ycombarnous|Ycombarnous]] 16:51, 21 February 2007 (CET)
 
*And here is the line in php.ini:
 
<pre>
 
; 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
 
</pre>
 
 
 
=== 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?)
 
* [[DPL:Version History|Version 0.9.6]] of DPL contains some new features. Please try.
 
-- [[User:Gero|Gero]] 15:56, 26 February 2007 (CET)
 
 
 
=== Question (3)===
 
(Newbie Question) I'm using 0.9.6 and observing the following warning regularly:
 
<pre>
 
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
 
</pre>
 
Is this 'normal' behaviour?  Any recommendations on how to correct this?
 
--[[User:Mattueckerman|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.
 
--[[User:Gero|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.
 
 
 
<pre>
 
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)".
 
</pre>
 
 
 
;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.[[User:Kohyin|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. [[User:Gero|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. --[[User:Gero|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.
 
[[User:Weakmassive|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.
 
--[[User:Gero|Gero]] 16:22, 16 February 2007 (CET)
 
:Thanks. This works now with the latest version.--[[User:Weakmassive|Weakmassive]] 15:47, 16 February 2007 (CET)
 
 
 
== Sort problem ==
 
I'm also having the same [http://meta.wikimedia.org/wiki/Talk:DynamicPageList2#Problems_with_sortkey problem with sortkey] as I did in previous versions. Any ideas? --[[User:Weakmassive|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]]? --[[User:Gero|Gero]] 16:07, 15 February 2007 (CET)
 
:The page I'm having problems with is [http://www.mographwiki.net/Industry_Directory:_Geographical here]. I want the Cities sorted alphabetically, so I want to use this code:
 
 
 
<pre><nowiki>
 
<dpl>
 
category=Cities
 
ordermethod=category,sortkey
 
headingmode=H2
 
mode=ordered
 
shownamespace=false
 
</dpl>
 
</nowiki></pre>
 
 
 
...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.--[[User:Weakmassive|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]]. --[[User:Gero|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?
 
<pre>
 
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)".
 
</pre>
 
 
 
Thanks. --[[User:Weakmassive|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.
 
:::::--[[User:Gero|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. --[[User:Weakmassive|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 ?
 
 
 
 
 
<pre><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></pre>
 
 
 
=== 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...
 
--[[User:Gero|Gero]] 09:11, 15 February 2007 (CET)
 
 
 
== [http://meta.wikimedia.org/wiki/Talk:DynamicPageList2 Talk on DPL2 (metawiki)] ==
 
=== Proposal ===
 
we should put a copy of '''Talk:DynamicPageList2''' here.
 
--[[User:Ycombarnous|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
 
[http://meta.wikimedia.org/wiki/Talk:DynamicPageList2 link to Talk:DynamicPageList2] should be enough.
 
--[[User:Gero|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]]<br>
 
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. -- [[User:Gero|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:
 
 
 
<DPL>
 
category=Peace and Security Council|Cities
 
mode=category
 
</DPL>
 
 
 
=== 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..
 
 
 
<DPL>
 
resultsheader=__NOTOC____NOEDITSECTION__
 
category=Peace and Security Council|Cities
 
mode=category
 
</DPL>
 
 
 
----
 
Additional remarks:
 
# I plan to set these two pragmas automatically if a DPL query is using mode=category.
 
# These pragmas are also useful in combination with other DPL queries.
 
# the trick explained above has been used in [[Example 1]]
 
# The principal reason why mediawiki feels tempted to generate a separate TOC for the output of DPL is not clear to me.
 
# 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.
 
# 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).
 
--[[User:Gero|Gero]] 11:50, 2 March 2007 (CET)
 
:Ok many thanks :) --[[User:83.203.42.222|83.203.42.222]] 14:49, 2 March 2007 (CET)
 
 
 
== wrong text included ==
 
=== Question ===
 
Hello, I made a [http://beadsoft.net/wtest/index.php?title=DynamicPageList_of_Extensions&oldid=471 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. --[[User:GunterS|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). -- [[User:Gero|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 [http://beadsoft.net/wtest/index.php?title=DynamicPageList_of_Extensions&oldid=473 here]. --[[User:GunterS|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 [http://beadsoft.net/wtest/index.php?title=DynamicPageList_of_Extensions_2 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?
 
 
 
--[[User:Gero|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. --[[User:GunterS|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). --[[User:Gero|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 ...
 
--[[User:Gero|Gero]] 10:32, 5 March 2007 (CET)
 
 
 
Would like to, but the extension itself is missing :(  --[[User:GunterS|GunterS]] 19:00, 6 March 2007 (CET)
 
 
 
Maybe, you want to join in at the discussion [http://www.mediawiki.org/wiki/Talk:Extension_Matrix 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:
 
 
 
<nowiki> <DPL>
 
  category=Philosophie_générale_licence,_semestre2,_2006-2007
 
  includepage=*
 
</DPL></nowiki>
 
 
 
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" ...
 
 
 
--[[User:Gero|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?
 
 
 
[[User:Kik|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 )
 
 
 
--[[User:Gero|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.
 
 
 
[[User:Kik|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.
 
 
 
[[User:Kik|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 [http://www.willemvanstrijen.nl/wikidelfia/index.php?title=Agnetapark 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?).
 
 
 
--[[User:Gero|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! <br>
 
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! --[[User:BB70|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? --[[User:Gero|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. --[[User:BB70|BB70]] 11:43, 20 March 2007 (CET)
 
 
 
=="replaceintitle" seems not to work==
 
I tried:
 
<pre>
 
<dpl>
 
  mode=none
 
  category=Test
 
  replaceintitle=\Test\,
 
</dpl>
 
</pre>
 
 
 
and it seems not to work.
 
 
 
--[[User:Dario|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:
 
 
 
<pre>
 
<dpl>
 
  mode=none
 
  category=Test
 
  replaceintitle=/Test/,
 
</dpl>
 
</pre>
 
 
 
Now it works:
 
 
 
<dpl>
 
  mode=none
 
  category=Test
 
  replaceintitle=/Test/,
 
</dpl>
 
:[[User:Gero|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 ??
 
 
 
[[Image: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
 
*Mysql 5.0.37
 
*php 5.2.1
 
*mediawiki 1.9.2
 
*downloaded DPL from [[DPL:Manual_-_Source_and_Installation]]
 
 
 
==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 <nowiki>{</nowiki>{#dpl: createdby=user}}
 
<pre>
 
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)".
 
</pre>
 
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. --[[User:80.175.250.218|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:
 
<pre>#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}</pre>
 
--[[User:86.213.75.164|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...
 
--[[User:Gero|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 :/ -[[User:86.213.75.164|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 <nowiki>__NOEDITSECTION__</nowiki> 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. -- [[User:216.146.163.228|216.146.163.228]] 21:49, 11 May 2007 (CEST)
 
 
 
:Thanks! See also [[#Category display mode]]. [[User:Gero|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
 
 
 
<pre>
 
category = xyz
 
notcategory=some such cat
 
</pre>
 
 
 
%DPL-1.2.0-WARNING: Unknown parameter '‎notcategory' is ignored. Help: available parameters: addca... namespace, notcategory, notnam ...
 
 
 
and using
 
 
 
<pre>
 
notcategory=some such cat
 
</pre>
 
 
 
%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? --[[User:Dmb|Dmb]] 11:32, 6 June 2007 (CEST)
 
 
 
=== Answer ===
 
Please look at the following examples:<br>
 
1) <u>List of African Union member states</u>
 
<dpl>
 
category=African Union member states
 
addcategories=true
 
</dpl>
 
2) <u>List of African Union member states without Arab League</u>
 
<dpl>
 
category=African Union member states
 
addcategories=true
 
notcategory=Arab League
 
</dpl>
 
: 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! [[User:Gero|Gero]] 08:52, 7 June 2007 (CEST)
 
 
 
=== Answer Back ===
 
 
 
Above is fine without doubt. I tried a DPL using;
 
 
 
<pre>
 
category = category for non template pages
 
notcategory = some other category
 
</pre>
 
 
 
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 --[[User:Dmb|Dmb]] 13:08, 8 June 2007 (CEST)
 
 
 
: However, its not unpossible that I installed DPL bad. --[[User:Dmb|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=". [[User:Gero|Gero]] 18:34, 13 June 2007 (CEST)
 
: Thanks for your help. I'll try getting the site admins to do a re-install.  --[[User:Dmb|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:
 
 
 
<nowiki><dpl></nowiki>
 
  title=Jacob's Ladder
 
<nowiki></dpl></nowiki>
 
 
 
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. [[User:Gero|Gero]] 11:45, 12 June 2007 (CEST)
 
 
 
== utf-8 / latin1 ==
 
 
 
<tt>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)".</tt>
 
 
 
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 [http://www.haunted-memories.net/wiki/index.php/DPL_Bug here]. The exact and complete contents of the page is:
 
 
 
<tt><nowiki><dpl>
 
namespace=Logs
 
ordermethod=title
 
</dpl></nowiki></tt>
 
 
 
--[[User:Ratio|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.
 
 
 
--[[User:Ratio|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 <nowiki>{{IT Policies}}</nowiki> 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:
 
<nowiki></nowiki> Fancy menu styling, collapsable tables and whatnot...
 
<nowiki><DPL></nowiki>
 
  category    = General Policies
 
  addpagesize  = true
 
<nowiki></DPL></nowiki>
 
<nowiki><DPL></nowiki>
 
  category    = Service Policies
 
  addpagesize  = true
 
<nowiki></DPL></nowiki>
 
<nowiki></nowiki>
 
 
 
== Problem with "reset" link in SP form ==
 
It links to <tt>/$1/Special:DynamicPageListSP</tt>, I suspect it's something to do with friendly URL's, see http://www.organicdesign.co.nz/Special:DynamicPageListSP --[[User:Nad|Nad]] 04:54, 7 July 2007 (CEST)
 
 
 
=== Could you explain? ===
 
Sorry, but I do not understand your problem. [[User:Gero|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. [[User:Gero|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:
 
[[:Image:20070713_DynamicPageList2.zip|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. -- [[User:217.238.216.19|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]]
 

Latest revision as of 15:08, 21 July 2007

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

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



...