DPL:Bug Reports Archive

From FollowTheScore
Revision as of 21:53, 15 September 2007 by 87.160.247.24 (talk) (→‎Reply: Feh!)
(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


Columns Bug

When I use the columns setting, it breaks the background-colour I have set. If I remove it, the background-colour comes back.
Contact me here, if you have any further questions.
--Jamie

Can you demonstrate the effect here or in your wiki? Gero 05:18, 25 July 2007 (CEST)
Sorry about that.
Here ya go. :)
--Jamie
Have you seen DPL:Requests_for_new_features_Archive#Global background-color? Maybe you have the same problem?
Gero 15:30, 27 July 2007 (CEST)

When using simple tables in the included page

When using simple tables in the included page, the first to be included looks strange Table bug and not as the original Table Bug 2. All the others Table Bug 3 and Table Bug 4 look different but still not right in the DPLed list.

Is this a bug? And if so is there a workaround or anything I can do to avoid that (except of not using simple tables...)? Please inform me about your reply: NaSe1977 13:11, 25 July 2007 (CEST)

You may consider it a bug or a feature: DPL does not automatically insert newlines between the articles. That´s the reason why the output looks so strange. I modified your Table bug article to show how two additional lines solve the problem.
Gero 16:52, 26 July 2007 (CEST)
Thanks a lot, this helped. Strange enough my DPL2 1.2.9 does not seem to know format, do I have to enable it anyhow? (I used mode=userformat' and 'listseparators=...' instead)
NaSe1977 09:15, 27 July 2007 (CEST)
You may have downloaded the ZIP file just before I had updated it. Please try again and look for the String "'format'" in the source. Gero 09:51, 27 July 2007 (CEST)

Parser functions and templates in <dlp> versus #dpl

I try to call a parser function from within <dpl> and #dpl and find that the latter does not work. For example, I have the following 

listseparators=,\n* [[%PAGE%|%TITLE%]]   (%CATLIST%)({{HEKtest3|%PAGE%}}) {{#sub:%TITLE%|0|7}},

using <dpl> both the #sub function and the HEKtest3 template works as they shall. For #dpl, the result of the #sub is just the text TITLE. For the macro HEKtest3 it's even more strange, because if I output the parameter like {{{1}}}} it works fine, but if I use #sub on the parameter within the same template it does not output anything. So it seems the template has the correct value, but can not use it for anything other than simple output.

Again - this works fine with <dpl>.

Could it be the pipe-character that is the problem?

Thanks H

Possibly; try using template:! or ¦ per DPL:Manual - General Usage and Invocation Syntax#Using DPL2 as a parser function. -Eep² 12:34, 9 August 2007 (CEST)
Thanks - it helped a little. But:
  • {{HEKtest3¦%CATNAMES%}} now works fine. The template is able to use the content of %CATNAMES%
  • {{HEKtest3¦%PAGE%}} does not work! It creates an output that contains a link to the HEKtest3 template with the content of %PAGE% as the dislpay text. Weird!
  • {{HEKtest3¦%TITLE%}} caused the same problem as above
  • The #sub function does not work with ¦ either (see description of problem above)
Well, if all you want are the page name and title, try using the MediaWiki magic words {{FULLPAGENAME}} (includes namespace) and {{PAGENAME}} (page title only). -Eep² 17:50, 10 August 2007 (CEST)
Thanks, but that only gives me the name of the page I'm on, and not the name of the page retrieved by the #dpl function
This problem can be easily solved in the latest revision with ²{...}², see the manual. The idea is that this special markup will be translated to twin curly braces during the iteration over the DPL result set. Gero 20:49, 15 August 2007 (CEST)

addpagesize does not correctly report the size of the page

This is a bit pedantic, but its an important 'bug' in my wiki; See the following; 

<dpl>
category = page size test
mode = ordered
ordermethod = size
order = ascending
addpagesize = true
</dpl>
  1. Page size test page 1 [89 B]
  2. Page size test page 2 [771 B]

As you can see by clicking above both pages are apparently about the same size, and page 1 is aparently a bit bigger. By looking at the source of the two pages we can see that this is only the case once the included template text has been taken into account. That is why I call "ordermethod = size" and "addpagesize = true" buggy... They should use the apparent size of the 'rendered page', not the size of the source code for that page.

I think this could be fixed... It would be a big help for me if it was... http://biodatabase.org/index.php/Sandbox

Thanks for the great extension! --Dmb 09:32, 10 August 2007 (CEST)

--Dmb 09:32, 10 August 2007 (CEST)

Reply

Summing up the size of included templates would be quite time consuming. I suggest that you create a DPL query which goes over the "original master date" (The copyrighted articles, I assume) and that you convert the link which DPL presents to the user into a link which points to your own article. Of course this is only possible if your article has a 1:1 correspondence with the master articles and if there is a consistent naming convention so that the name of your article can be algorithmically deduced from the master article´s name. O.k.??
Gero 20:54, 15 August 2007 (CEST)

Yup... but how do I do it??? Cheers, --87.160.217.187 20:09, 24 August 2007 (CEST)
Quite simple: use the namespace, categories etc. which apply to your raw data articles, set addpagesize=yes and use 'replaceintitle' to make the transformation of the title. Have a careful look into ther manual ;-). If you really can´t figure out how to do it, create demo pages which reflect the principle structure of your current pages here in this wiki and I´ll show you how to do it. ::::
Seems to be working now (http://biodatabase.org/index.php/Contribute_to_MetaBase) Cheers dude! --Dmb 14:19, 14 September 2007 (CEST)
But :-( I still have a problem... Let me explain properly... The template holds the page data, so carries the size parameter. I make a DPL for the category 'Data Template', and alter the name using replaceintitle so it matches the pagename. However,... the page itself (the page the data template is included in) may be categorized, specifically if it is edited it joins category 'edited' ... I want to exclude include that category from my DPL! So I think it is impossible. Actually I think this is a bug at the MW level, which could store the size of the fully rendered page (page + templates) upon save. --87.160.247.24 21:53, 15 September 2007 (CEST)

Wrong number of items per column

Hi, I'm dealing with a DPL report that finds 116 articles and place them in 8 columns as specified by the following DPL parser function: 

{{#dpl:
   |titleregexp=^TRB....$
   |mode=userformat
   |listseparators={{!}} valign="top" style="padding-right:20px;" {{!}},\n* [[%TITLE%]],,
   |columns=8
   |rowcolformat=style="color:black; background-color:white; text-align:left; vertical-align:top;"
   |replaceintitle=/ /,_
}}

The problem is: I get four columns with 15 items and four columns with 14 items, when the ideal would be 7 columns with 15 items and the last column with whatever is left (11 in this specific case). Is this some kind of off-by-one error in the code? I will try to reproduce it here, with a smaller number of articles: stay tuned!- Manu3d 13:29, 16 August 2007 (CEST)

By the way, this is a screenshot of what I see:

DplColumnProblem.jpg

(A few minutes later) I managed to reproduce the problem but it seems to point to a conceptual issue. Check out my user page. The problem is that the code tries to spread evenly the results over the maximum number of columns, adapting the number of items per column to put something into each column. Ideally, using "rows=" together with "columns=" estabilishes the number of items each column contains, potentially reducing the number of visible columns from the number estabilished by the user.

Is there a way around this?

Thanks for your help. - Manu3d 13:52, 16 August 2007 (CEST)

Reply

Indeed DPL tries to spread the results evenly over the columns. So far nobody complained about that... Why is it important to have a less well balanced output scheme? Gero 23:00, 16 August 2007 (CEST)

That isn't balanced, Gero. It should be equal column lengths until the very last column. At least make your idea of "balanced" columns optional... Your way seems balanced for horizontal/row lists (as in Special:Allpages):
 1  2  3  4
 5  6  7  8
 9 10 11 12
13 14 15 16

and not vertical/column lists: 

1 5  9 13
2 6 10 14
3 7 11 15
4 8 12 16

-Eep² 11:10, 17 August 2007 (CEST)

I agree with Eep², the current way of handling it seems to originate from row-oriented thiking and it's fine for that purpose. But you wouldn't want a row-oriented result looking like this, would you: 

 1  2  3  4
 5  6  7  8
 9 10 11 12
13 14 15
16 17 18
19 20 21

-Manu3d 11:38, 17 August 2007 (CEST)

Decision

O.k., your arguments convinced me. Will be changed in the next version. Gero 14:38, 17 August 2007 (CEST)

Well, you don't have to choose one way over the other, but if you allow both list directions (as an option), the associated balancing should take effect with it. -Eep² 15:12, 17 August 2007 (CEST)

Question Re: Templates

This isn't really a bug, but I wanted ask about this. If I have a template called 'Awards' and the template took too fields 'Award' and 'Date' where Award is a name of an award from a specific list and date is the date its awarded, can I use DPL to get a list of all pages using the 'Awards' template with 'Five Year Award' in the Award field? -Thanks. 18:21, 18 August 2007 (CEST)

Answer

You should be able to do this with uses=Template:Award, include={Awards}.dpl and includematch=/Five Year Award/ ; see the manual for details. There are examples for similar applications of DPL on this website. Your template Awards.dpl should contain code that produces a table row in your result. Gero 20:41, 18 August 2007 (CEST)


The bug of Template:Catlist?

When I import the Template:Catlist, it became what is shown below;
Catlist error msg 001.png

Could anyone give me a hand? please! —The preceding unsigned comment was added by Roc michael (talk • contribs) 06:36, August 21, 2007. Please sign your posts!

Do you have Simple Forms and Call installed per DPL:Catlist? -Eep² 09:08, 25 August 2007 (CEST)
Thank you, Eep²! Please see The bug(s) is/are nothing about DPL.

environment setting

  • MediaWiki: 1.10.0
  • PHP: 5.1.6 (apache2handler)
  • MySQL: 5.0.24a-community-nt-log
  • Parser hooks
    1. CategoryTree
    2. CharInsert
    3. Cite
    4. CreateBox (version 1.5)
    5. CSS (version 1.0.0, 2007-06-15)
    6. CurrentUsers (version 1.0.2, 2007-07-26)
    7. DPLforum (version 3.2)
    8. DynamicPageList2 (version 1.3.1)
    9. Inputbox
    10. LabeledSectionTransclusion
    11. NiceCategoryList
    12. ParserFunctions
    13. RegexParserFunctions (version 0.1)
    14. Semantic Forms (version 0.5)
    15. Semantic MediaWiki (version 0.7)
    16. Simple Forms (version 0.3.4, 2007-08-03)
    17. SimpleTable
    18. StackFunctions (version 0.6)
    19. StringFunctions (version 1.9.3)
    20. SyntaxHighlight
    21. Variables
    22. Winter (Wiki INTERpreter) (version 2.0.2)

Reply

Open the Catlist article and remove one leading '{' from the #dpl statement. Thus you will see the input which is sent to DPL. Then check the argument of the namespace parameter. You seem to have user defined namespaces. Make sure that they start with numbers of 100 and greater (as recommended). Gero 16:24, 21 August 2007 (CEST)

Different results

Thank you, Gero!

After your instructions, I'v found that some different results, but I still don't know what're the reasons. The statements like bellows: 

 {{#dpl: namespace=Category | format = ,\n*%TITLE%,, }}

and 

 {{#dpl: namespace=Template | format=,\n*%TITLE%,, }}

Could cause the results 

%DPL-1.3.1-??: ??? 'namespace' ??: 'Category'! ??: namespace= ???? (?) | Attribute | Attribute_talk | RD | RD_talk | Relation | Relation_talk....?

and 

%DPL-1.3.1-??: ??? 'namespace' ??: 'Template'! ??: namespace= ???? (?) | Attribute | Attribute_talk | RD | RD_talk | Relation | Relation_talk....?

But in this site thay don't make this results? I notice that the version of between this site and mime are different. Is it the reason. Please help me! --Roc michael 00:51, 22 August 2007 (CEST)

The bug(s) is/are nothing about DPL

After several my testing I found the bug(s) I met is/are nothing about DPL. The reason of the bug(s) is/are that I've ruined my testwiki by changing charset of Localsetting.php to utf8 and ansi again and again.

Whan I changed the charset of Localsetting.php, my wiki-system will become unstable and some arguments of DPL can't work.

Thank Gero and others. You are very kind.--Roc michael 14:42, 22 August 2007 (CEST)

SQL error with uses= and linksfrom=

1.3.2 had this bugfix:

Bugfix with SQL error
ambiguous 'page_name' in SQL statement fixed (appeared when namespace= and linksfrom= were used together)

I believe there is a similar bug with 'page_id' in the SQL statement which appears when uses= and linksfrom= are used together. I put an example on Test linksfrom, which now errors: MySQL returned error "1052: Column 'page_id' in where clause is ambiguous (localhost)". It appears that uses= adds a reference to page_id which should be something like `page`.page_id instead.

Answer

Thank you for reporting that error. If you find a problem with a DPL statement, please add 'debug=4' as first parameter. This will echo the SQL statement even if it is buggy. Otherwise calling an article with such a DPL statement will reuslt in an empty page so that the user has no idea what went wrong.

Indeed there are some other parameter combinations (only with linksfrom) which cause the same error, for example revision+linksfrom. Will be repaired. Gero 09:06, 24 August 2007 (CEST)

Direct subcategory feature broken by spaces?

I added this example to Test category hierarchy‎. "category=*African Country" appears to not descend any subcategories, but "category=*African_Country" works correctly. —The preceding unsigned comment was added by 64.186.172.226 (talk • contribs) 18:43, August 23, 2007. Please sign your posts!

Yes. The bug will be corrected soon. Gero 14:40, 26 August 2007 (CEST)

Deleted pages show up on Special:Wantedpages

I have a query that pulls back a list of pages in a category called "Spec Work Required". I've had two matching articles that proved to be unnecessary and were deleted. They no longer show on the page with the query, but when I look at the special page, "Wanted Pages", they appear.

I restored one of them, removed the categories, saved the change, and deleted the article again, and it still appears on the Wanted Pages list.

The wiki where this is going on is a private one where my software development team is spec'ing a fairly large software application, so I can't share the pages with anyone at this time. In order to try to demonstrate the problem further, I created The Deleted Republic on this site. I don't seem to have rights to delete that page, though, so I can't complete the bug test.

To complete it, someone with adequate rights would have to delete The Deleted Republic, check to see that it has in fact been removed from the country list, then check Wanted Pages to see if the article appears. If it does, then I'd say the bug is verified.

At this point, this is not a critical bug as my team is pretty careful about checking our Wanted Pages list to make sure we're not referring to lots of specs that don't exist, but I'm thinking about incorporating this extension into another wiki site where it could be much more problematic.

--Aaron Overton 20:26, 25 August 2007 (CEST)

Answer

Hello Aaron, I tried to follow the procedure outlined above. After deleting "The Deleted Republic" it still shows on the WantedPages -- but because this very article refers to it ;-)). I suggest that you try in your wiki the following:

  • delete an article which is part of a DPL result
  • execute runJobs.php (in the maintenance directory) OR wait for an hour OR open the article containing the query and saving it without changes.
  • Each of these steps should have the effect that the reference from the query page becomes deleted from the database. At least the last method works in my local wiki.

You could also add a final DPL statement with reset=all (see the manual for details!) to the article containing your query. Then the database will never contain backward links from the query page to the article page. In that case it should be enough to just delete the article.

Could you please check all of the above and report here briefly if it works as described? It would be nice if you could add an entry to the FAQ article afterwards ... Gero 14:26, 26 August 2007 (CEST)

Reply

Well, heck. I went back and followed my own directions on my own wiki and wasn't getting the same results. I found myself wondering if it was the hour delay - I didn't wait an hour after adding the test page.

However, I did navigate to the deleted page and check its "What links here" link and the DPL query page did in fact show up on that list. So I don't appear to be crazy, at least in this one small regard.

I tried your suggestion of opening the DPL query page in edit mode and saving it again. That did clear whatever was cached connecting the deleted article to its categories, thus making the article still appear in some way linked to the DPL query page. I trust that your other methods would work similarly. So it appears not so much to be a DPL bug, but something I guess I could call a "quirk" based on the interaction between MediaWiki and DPL. That makes it pretty darn minor, but I will go ahead and add something to your FAQ page. --Aaron Overton 20:54, 2 September 2007 (CEST)

Creating an annual calendar

When I try to creat an anual calendar with the commands of 

{{CalendarSingle|year=2007|month=01|show_year=no|basepage=Events:}}
...
{{CalendarSingle|year=2007|month=12|show_year=no|basepage=Events:}}

I get an error - See DPL:Bug Reports/Annual calendar

Strange, it does work on this wiki. Doesnt work on mine, I can't even post the wikitext. [1]

-- 14:50, 26 August 2007 (CEST)

Maybe you should download the latest DPL version and check if your templates are the same as in this wiki, Gero 15:30, 26 August 2007 (CEST)

wfDynamicPageListSPloadMessages

DPL works fine on my wiki, but if I try to go to Special:Specialpages, I get the following: 

Internal error

Invalid NULL return from broken hook wfDynamicPageListSPloadMessages

Backtrace:

#0 F:\edit\includes\MessageCache.php(677): wfRunHooks('LoadAllMessages')
#1 F:\edit\includes\SpecialSpecialpages.php(13): MessageCache::loadAllMessages()
#2 F:\edit\includes\SpecialPage.php(653): wfSpecialSpecialpages(NULL, Object(UnlistedSpecialPage))
#3 F:\edit\includes\SpecialPage.php(459): SpecialPage->execute(NULL)
#4 F:\edit\includes\Wiki.php(203): SpecialPage::executePath(Object(Title))
#5 F:\edit\includes\Wiki.php(45): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#6 F:\edit\index.php(89): MediaWiki->initialize(Object(Title), Object(OutputPage), Object(User), Object(WebRequest))
#7 {main}

I know it's DPL throwing the error because it only happens when DPL is enabled, and it happens when DPL is enabled and the rest of my extensions are disabled.

I just downloaded the latest source for DPL today, and it didn't fix it. Any ideas? Jonathan Kovaciny 20:22, 27 August 2007 (CEST)

Reply

Please check the function which is hooked to 'LoadAllMessages' (wfDynamicPageListSPloadMessages()) and add "return true;" at the end. This may help. You could also comment out the line where wfDynamicPageListSPloadMessages is registered (in file DynamicPageListSP). You could also comment out the line in DynamicPageList2.php with the "require_once" statement for the special page. Anyway, the next version of DPL will no longer have a Special Page as the DPL GUI is a better alternative. So don´t bother with the special page. Gero 07:48, 28 August 2007 (CEST)

That template can't handle multiple namespaces, categories, or even articles (as I mentioned to you almost a month ago); it's not ready to replace the special page. -Eep² 09:23, 28 August 2007 (CEST)
I commented out line 19 ($wgHooks['LoadAllMessages'][] = 'wfDynamicPageListSPloadMessages';) and it seems to work now. But what does this line do? -- Jonathan Kovaciny 16:15, 28 August 2007 (CEST)

%PAGES% not working

{{#dpl:namespace=Template
|mode=category
|ordermethod=titlewithoutnamespace
|shownamespace=no
|rowcolformat=width=100%
|resultsheader=<h2>Templates (%PAGES%)</h2>
}}

Just shows "Templates (0)" instead of actual # of articles/pages (templates) found... Also, the column heights are not all equal except for the rightmost one, as stated in a recent update release notes. -Eep² 23:17, 29 August 2007 (CEST)

Indeed there is a bug in %PAGES% when used together with mode=category. Will be fixed in the next release. Gero 09:17, 30 August 2007 (CEST)

Transcluded parameter truncated

Transcluding a single template parameter sometimes does not get the full parameter. Example: See the Nigunda Test entry at Test section inclusion#include a single template parameter. The retrieved value is terminated prematurely (right before the pipe). I believe the scope of the bug is just when a pipe is used within square brackets in a parameter. --Rezyk 12:03, 31 August 2007 (CEST)

Answer

Thank you for reporting. There is a bug in the parser (it simply ignores hyperlinks and gets fooled by pipe characters inside hyperlinks). Has been corrected. Gero 13:37, 31 August 2007 (CEST)

ordermethod ignored form2 demo (repost)

{{# dpl:
|category=Untranslated
|namespace=FollowTheScore
|shownamespace=false
|ordermethod=titlewithoutnamespace,firstedit
|addeditdate=true
|adduser=true
|addpagesize=true
|mode=userformat
|listseparators=¶{¦class="sortable" ¶!Script ¶!Last ¶!By ¶!Size,¶¦-¶¦style="background:#ccffcc;"¦%TITLE%¶¦%DATE%¶¦%USER%¶¦%SIZE%,¶,¶¦}
|secseparators=\n¦
}}

ordermethod is not processed. Bug to be reported in bugtracker. 82.255.229.238 14:30, 9 August 2007 (CEST)

The bug fix was included into the latest revision (1.3.3) Gero 11:13, 17 August 2007 (CEST)

Resultsheader with columns

The %PAGES% gives back <number of pages>/columns instead of <number of pages>. Is this intentional or a bug?

Page:Resultsheaderwithcolumns

It is a bug and will be resolved. Gero 21:08, 24 July 2007 (CEST)

Database error

{{#dpl:namespace=
|linksto={{PAGENAME}}
}}

gives

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

But this (which I won't actually do): 

{{#dpl:namespace=
|linksfrom={{PAGENAME}}
}}

gives a 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 "1052: Column 'page_namespace' in where clause is ambiguous (localhost)".

-Eep² 13:42, 7 August 2007 (CEST)

This is resolved. Gero 08:15, 15 August 2007 (CEST)


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

ordermethod ignored form2 demo

{{# dpl:
|category=Untranslated
|namespace=FollowTheScore
|shownamespace=false
|ordermethod=titlewithoutnamespace,firstedit
|addeditdate=true
|adduser=true
|addpagesize=true
|mode=userformat
|listseparators=¶{¦class="sortable" ¶!Script ¶!Last ¶!By ¶!Size,¶¦-¶¦style="background:#ccffcc;"¦%TITLE%¶¦%DATE%¶¦%USER%¶¦%SIZE%,¶,¶¦}
|secseparators=\n¦
}}

ordermethod is not processed. Bug to be reported in bugtracker. 82.255.229.238 14:30, 9 August 2007 (CEST)

Retrieved from "http://followthescore.org/dpldemo/index.php?title=DPL:Bug_Reports_Archive&oldid=6437"