Issue:Listing certain subcategories of articles

Description:	listing articles with subcategories - but how?
Extension / Version:	DPL   /   1.8
Type / Status:	Change Request   /   open

Problem

There are lots of projects with universities in my wiki-db, connected with categories like "dep03", "Wien TU", "Regensburg U" and "project-id" and containing project-descriptions. When I use "*universities" and "dep03" as page-selectors (namespace=category) I don´t get a list of universities which are only connected with department 03. Why?--Hannds 0920 15:40, 20 September 2009 (UTC)

Reply

I think there will be some logical reason for this - either a bug in DPL or a problem on your side. I recommend to reproduce your problem here in this wiki with some sample data. I am quite confident that we will find out the cause.

BTW: The "*" - operator only searches one level deep in the cat tree, "**" goes two levels deep (more is not possible atm.)

You can use pseudo-recursion to traverse deeper trees as is shown in some examples on this web site.

Gero 09:30, 21 September 2009 (UTC)

Reply

With these lines I solved my basic problem .. <noinclude><dpl></noinclude>

 category=+*universities
 category=-dep03
 category=-projects current
 ordermethod=category,sortkey
 headingmode=ordered
 include=#..some sections..

<noinclude></dpl></noinclude> .. but without being completely content. For example because there appeared out of the resulting list a new question - after about 400 lines (presenting 130 institutions) there was a break, a cut without any error message. Please, tell me how to debug effficiently dpl-errors. --Hannds 0920 22:16, 3 October 2009 (UTC)

Reply 2

DPL has a configurable safety limit for the maximum number of recors in the result set. By default this is set to 500. You can increase the limit in your LocalSettings.php after the require_once for DPL, as described in the manual, see DPL:Manual_-_Source_and_Installation and look for MaxResultCount or AllowUnlimitedResults.

However, if your result is so big, you should consider to use results scrolling. I suggest to use an approach as in DPL_Example_027. Gero 04:56, 4 October 2009 (UTC)

vielleicht interessiert dich auch das:

Forschungseinrichtung_in_Deutschland

---

Many thanks!, vielen Dank für die Hilfen! Der Link auf die Forschungseichtichtungen war mir schon bekannt! - scroll=yes werde ich ausprobieren.

In the meanwhile I believe that your dpl-extension is a really mighty tool! but I am still fighting with the rules for achieving nice layouts (esp. tables!). --Hannds 0920 13:48, 4 October 2009 (UTC)

Next problem

Sorry, but the "DPL Extension Continue" (scroll=yes) does´nt work. I can´t detect any effect. Later on I dicovered that there exist a similiar experience in the talk, written by Subfader, see Talk:DPL Example 020#Links at the bottom.--Hannds 0920 18:21, 5 October 2009 (UTC)

Depending on your default settings DPL may use the Mediawiki Pareser Cache. In this case you would always see the same result. Do you recognize a difference when you call the page as an anonymous user or as a logged-in user? Does it work if you are logged in into your wiki? Also a proxy server or your browser cache may play a role. Does it work if you add "&action=purge" to the URL? Does it work if you add "allowcachedresults=no" to the DPL statement? If nothing helps: Can you demonstrate the problem here in this wiki?

Note that DPL Example 020 uses a different flavor of scroll template (of course both scroll helper templates should work correctly).

Gero 11:07, 6 October 2009 (UTC)

I´ve tried it yet. The answer for "&action=purge" was <this page does´nt exist>. And no effect with <allowcachedresults=no>. Perhaps "?action=purge" will work. May be that the listing of subcategories (single universities as subcategory of "universities") produce data which stay in the cache for a long time, a day or so. A simulation of my case here would need actually too much time, later?

--Hannds 0920 19:08, 6 October 2009 (UTC)