Issue:Returns 0 results even when resultsheader is used
| Description: | Returns 0 results even when noresultsheader is used |
| Extension / Version: | DPL / 1.4.7 |
| Type / Status: | Bug / closed |
Problem
The following is in Template:Person
{{#dpl: linksto={{FULLPAGENAME}} | uses=Template:Person | includepage={Person}.dpl | includematch=/.mother={{FULLPAGENAME}}¦.father={{FULLPAGENAME}}/ | mode=inline | inlinetext= • | resultsheader=''{{FULLPAGENAME}}'' has %PAGES% children listed here: |oneresultheader=''{{FULLPAGENAME}}'' has %PAGES% child listed here: | noresultsheader=''{{FULLPAGENAME}}'' has no offspring listed here.| resultsfooter=}}
and it works as expected unless (I'm guessing) another page refers to the page that this template instance is used in. Then instead of
has no offspring listed here.
it returns
has 0 children listed here:
The other page might be one that (say) lists all the pages that Template:Person is used in. When you first create a page using this template, it works exactly as expected however often you preview it. However, once you have saved the page, within a short period of time it goes to the other behavior. If no other page refers to this one, it works as it should. I'm not sure I can come up with a simple example of how to reproduce this, but it is rather consistent.
This page shows the problem, this page does not. The only difference of which I am aware is that no other page links to the latter. They both use Template:Person so it isn't directly related to self-inclusion. If you look at the site you'll see that it would have been impossible without DPL and the cool xxx.dpl templates! BTW there are other self referential templates that also search using similar keys and have the same problem, as you can see from the examples.
Thanks --Frank 15:16, 27 October 2007 (EDT)
Reply
The decision whether to use the noresultsheader or not is taken based on the number of rows found in the SQL result. The actual number of results, however, comes from those pages that match the includematch. If you have a page which conatins a list of all PERSONs that page will contain a link to every person, i.e. also to those which have no children. This makes the linksto condition true and the SQL result contains your summary page. Therefore DPL suspects that there will be some results. If, afterwards, it turns out that none of the referring pages matches the includematch condition you will getthe message you described.
I see three remedies:
- you can add reset=all to the summary page. This will prevent the links contained within the DPL output to be recorded in the database. So there will be no linksto-matches.
- you can add an #if statement to the resultsheader which checks %PAGES% against 0. (Correctly you would also have to check against 1). The #if could then output the desired text for 0 matches. You would have to use ²{#if:.....}² to prevent the statement from being processed before DPL will be invoked.
- I could change the code to become aware of the situations describes above. I'll put it on my list ...
I would advise to take way #1 and wait for #3.
Gero 22:55, 27 October 2007 (CEST)
Reply
If I understand correctly, Categories that list all pages would also cause the problem, and as far as I know there's no equivalent to reset=all for them. I added reset=all to the relevant dpl queries and the problem didn't go away. Unfortunately I have been completely unable to get ExtensionFunctions to work, even with a fresh install of Mediawiki 1.11 on a different website, and no one on the Mediawiki mailing list seems to be able to help. So I guess I'll wait for option 3. It is a cosmetic problem so we can obviously live with it. Thanks for responding so rapidly (and for a great extension!).
Frank 18:49, 27 October 2007 (EDT)
It was very easy to fix so I did it right now. Use 1.5.1 and everything should be fine.
Btw: the reset=all could well be applied to a DPL query which lists all of your PERSON articles. This might make a lot of sense as DPL will not see the inverse links of such a page when looking for a PERSON´s children.
- Gero 12:51, 28 October 2007 (CET)
