Last modified: 2013-02-06 09:38:48 UTC
[[{{#ifexist:Category:Ifexist baz bar|Category:Ifexist baz bar}}]] That is the test case. Currently, it puts an entry in pagelinks and in categorylinks. However, having an entry in pagelinks for a link that isn't clickable is unintuitive and confusing (in API results, etc.). A new column to flag non-clickable links that have a pagelinks entry is a possible solution.
The same thing happens with an escaped category link, for example [[:Category:Foo]]. http://en.wikipedia.org/w/api.php?action=parse&text=%5B%5B%3ACategory%3AFoo%5D%5D+%7B%7B%23ifexist%3ACategory%3ABar%7D%7D [[:Category:Foo]] {{#ifexist:Category:Bar}} <links> <pl ns="14">Category:Bar</pl> <pl ns="14">Category:Foo</pl> </links>
Re-opening. Not sure why this is closed as INVALID.
I've just run up against this problem myself. To clarify the current behaviour: An #ifexist test on a nonexistent category ("{{#ifexist:Category:NoSuchThing|[[Category:NoSuchThing]]}}") results in an entry in pagelinks, but none in categorylinks. A test on a category that does exist ("{{#ifexist:Category:People|[[Category:People]]}}") generates entries in both tables. From this we can attribute the entry in pagelinks to the #ifexist test itself, and the entry in categorylinks to its parsed result ("" and "[[Category:People]]" for the examples above). I'd imagine the pagelinks entry has to exist to ensure the page containing the #ifexist test is properly re-evaluated should someone come along and create (or un-create) its subject. This is definitely a PITA for those working from the database alone though; ideally such entries should be stored elsewhere ('pageexistslinks') to keep the semantics of the pagelinks table clear. I'd imagine there are performance gains to be had by doing so also - only a subset of the usual tests make against pagelinks would need to test pageexistslinks also.
> I'd imagine the pagelinks entry has to exist to ensure the page containing the > #ifexist test is properly re-evaluated should someone come along and create (or > un-create) its subject. Exactly. that is bug 10857. Probably.(In reply to comment #2) > Re-opening. Not sure why this is closed as INVALID. Well, how about a dupe then. Bug 12019 looks good. But really, this is an expected behavior. *** This bug has been marked as a duplicate of bug 12019 ***