Issue:Listing certain subcategories of articles

Description:	listing articles with subcategories - but how?
Extension / Version:	DPL   /   1.84
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 first answer for "&action=purge" was <this page does´nt contain any text>. 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?

Important seems to be the last error message: "the unknown command 'scroll' will be ignored" which I received when I set debug=2 (during a separate try). --Hannds 0920 19:08, 6 October 2009 (UTC)

The scroll command came in only recentkly (1.8.9). Please Download it and try again. If that does not help, send me a link to your wiki and I will try to find the reason for your problems. The scroll feature is still very new and I may be able to find the cause if I can reproduce the error. As you have seen I put some effort into DPL because I think it should be made available on huge wikis like wikipedia (although it may not be easy to convince the admins that it can be run without "danger"). Therefore I am especially interested in showcases with a large number of pages. And your wiki seems to be such a showcase ... -- 07:00, 7 October 2009 (UTC)

Gero, many thanks for your answers. We have both - an internal and an external part of our wiki. Actually there will be no chance for my colleague to install something new. My main interest is to solve the security lack in connection with dpl coding - in order to apply dpl in future. --Hannds 0920 20:45, 7 October 2009 (UTC)

I still don´t understand how you differentiate between internal and public pages within the same wiki? --Gero 08:19, 8 October 2009 (UTC)

There are two authorities. It indicates that we have two separate wikis installed.--Hannds 0920 17:12, 14 October 2009 (UTC)