Difference between revisions of "Issue:Hook into Special:Whatlinkshere"

From FollowTheScore
Jump to: navigation, search
(Yes, we can ;-))
 
(12 intermediate revisions by 3 users not shown)
Line 29: Line 29:
 
The article [[Article connected by DPL category keyword]] is in the category "Whatlinksheretest". However, when you visit [[Special:WhatLinksHere/Article connected by DPL category keyword]], the results do not contain [[Test what links here with categories]]. [[User:Maiden taiwan|Maiden taiwan]] 21:30, 7 July 2009 (UTC)
 
The article [[Article connected by DPL category keyword]] is in the category "Whatlinksheretest". However, when you visit [[Special:WhatLinksHere/Article connected by DPL category keyword]], the results do not contain [[Test what links here with categories]]. [[User:Maiden taiwan|Maiden taiwan]] 21:30, 7 July 2009 (UTC)
  
:Haha, exactly the opposite of what I want. I see DPL as dynamic, means actually really no page LINKS to your article. DPL just lists it on your test page. If it was a longer list and there was a navigation with your article on navigation page 2 the DPL page wouldn't be counted as LINKING TO as well. What's the sense then??? Think about it. I'm in favour of disabling all references for "what links here" and "file links" on image pages, then add a parameter to ENABLE the reference like enablerefs=true (still if the DPL list had a navi it wouldn't make sense, at least it's not DPL's fault then). --[[User:Subfader|Subfader]] 01:02, 8 July 2009 (UTC)
+
:Haha, exactly the opposite of what I want. I see DPL as dynamic, i.e. it outputs lists for queries like a search result. It checks which pages match your DPL criteria and outputs links in most case. And in fact, actually no page LINKS to your article. DPL just lists it on your test page because you searched for articles in a certain category the article belongs to. If your page was deleted it wouldn't be resulted by the DPL query. A handmade link on a page would be defunct. Big difference. Furthermore, if your DPL output was a long list with navigation and your article on navigation page 2, the DPL page wouldn't be counted as LINKING TO as well (I suppose). What's the sense then??? Think about it. I'm in favour of disabling all references for "what links here" and "file links" on image pages, then add a parameter to ENABLE the reference like enablerefs=true (still if the DPL list had a navi it wouldn't make sense, at least it's not DPL's fault when a user enables refs on navigations list oputput). --[[User:Subfader|Subfader]] 01:02, 8 July 2009 (UTC)
 +
 
 +
::Here is a case where you want the behavior I described. Suppose you need to rename a category on your wiki. (Say, a user created a category with a bad name.)  On a stock MediaWiki system, it's easy to see a list of the affected articles: just view the category page. When DPL is installed, however, this gets harder. You don't want to break any DPL queries that use this category (like mine, above).  How can you find out, "Is this category part of any DPL query on our wiki?" There's no good way to do it. So category renames are now risky.  I deal with this problem all the time. [[User:Maiden taiwan|Maiden taiwan]] 01:23, 8 July 2009 (UTC)
 +
 
 +
:::You could use my suggested enablerefs=true. See it from my point of view. [[:Image:Placeholder.png]] is not embedded on any page, just listed on DPL pages because it is in [[:Category:Test Images]] (DPL on User:Subfader/Examples) and was recntly uploaded by me (DPL on User:Subfader). Because of that it is not listed on [[Special:UnusedImages]] while actually no page uses (embeds) it or links to it. --[[User:Subfader|Subfader]] 02:04, 8 July 2009 (UTC)
 +
 
 +
::::enableRefs is an interesting idea. However, if the responsibility is on the page creator, it won't get used. Any random user could produce a DPL tag without enableRefs, which is problematic for the category renaming scenario I described. I'd rather see $wgDplEnableRefs=true at the global level, or the opposite disableRefs=false (so refs are enabled by default). [[User:Maiden taiwan|Maiden taiwan]] 03:01, 8 July 2009 (UTC)
 +
 
 +
== Yes, we can ;-) ==
 +
 
 +
The current version of DPL already allows some sort of influence on the creation of back links.
 +
 
 +
Look at [[Test what links here]] and [[Test what links here 2]] and check the "Special:What links here" for the page in the result set!
 +
 
 +
DPL uses an internal function to list result pages if you DO NOT USE THE FORMAT statement. This link is not caught by the wiki engine - so no backlink will appear.
 +
 
 +
If you create the output yourself by using the format statement, DPL will produce wiki text for output which is then parsed by the MW engine. So you will get backlinks.
 +
 
 +
So, those who want backlinks should use the format statement. It can of course be used in a way to generate the same kind of bullet list that is default for 'standard' output.
 +
 
 +
Those who want to use 'format' and nevertheless want to get rid of the links have to use [[reset]] or [[eliminate]]. The latter is more precise in that it only removes links generated by DPL but it needs more performance.
 +
 
 +
[[User:Gero|Gero]] 18:45, 8 July 2009 (UTC)
 +
 
 +
:Thanks Gero, that brings some light to it. The format option hrr. Makes sense. --[[User:Subfader|Subfader]] 19:33, 8 July 2009 (UTC)

Latest revision as of 20:33, 8 July 2009

Description:
Extension / Version: DPL   /   1.6.8
Type / Status: Change Request   /   open

Problem

Special:Whatlinkshere does not detect DPL-generated lists, of course. It would be great if it could detect them. Right now, if you visit Special:Whatlinkshere for a given article, and it returns no results, you can be fooled that nobody links to your article, and perhaps it's safe to delete... but DPL-generated lists might link to it, and you'll never know about it.

Reply

You are not right. Look at the example Test what links here. This article lists a certain page. And that is the only reference to that page. Go to that page and check the "what links here". It will show the article containing the DPL query.

There is, however, a way to explicitly PREVENT MediaWik from showing links which come from DPL queries: See the reset and eliminate Command.

Gero 09:14, 9 April 2008 (CEST)

Test case

OK, here is a test case that shows Special:Whatlinkshere does not detect some DPL-generated lists. The article Test what links here with categories contains a DPL tag that selects on a category:

<dpl>
category = Whatlinksheretest
</dpl>

The article Article connected by DPL category keyword is in the category "Whatlinksheretest". However, when you visit Special:WhatLinksHere/Article connected by DPL category keyword, the results do not contain Test what links here with categories. Maiden taiwan 21:30, 7 July 2009 (UTC)

Haha, exactly the opposite of what I want. I see DPL as dynamic, i.e. it outputs lists for queries like a search result. It checks which pages match your DPL criteria and outputs links in most case. And in fact, actually no page LINKS to your article. DPL just lists it on your test page because you searched for articles in a certain category the article belongs to. If your page was deleted it wouldn't be resulted by the DPL query. A handmade link on a page would be defunct. Big difference. Furthermore, if your DPL output was a long list with navigation and your article on navigation page 2, the DPL page wouldn't be counted as LINKING TO as well (I suppose). What's the sense then??? Think about it. I'm in favour of disabling all references for "what links here" and "file links" on image pages, then add a parameter to ENABLE the reference like enablerefs=true (still if the DPL list had a navi it wouldn't make sense, at least it's not DPL's fault when a user enables refs on navigations list oputput). --Subfader 01:02, 8 July 2009 (UTC)
Here is a case where you want the behavior I described. Suppose you need to rename a category on your wiki. (Say, a user created a category with a bad name.) On a stock MediaWiki system, it's easy to see a list of the affected articles: just view the category page. When DPL is installed, however, this gets harder. You don't want to break any DPL queries that use this category (like mine, above). How can you find out, "Is this category part of any DPL query on our wiki?" There's no good way to do it. So category renames are now risky. I deal with this problem all the time. Maiden taiwan 01:23, 8 July 2009 (UTC)
You could use my suggested enablerefs=true. See it from my point of view. Image:Placeholder.png is not embedded on any page, just listed on DPL pages because it is in Category:Test Images (DPL on User:Subfader/Examples) and was recntly uploaded by me (DPL on User:Subfader). Because of that it is not listed on Special:UnusedImages while actually no page uses (embeds) it or links to it. --Subfader 02:04, 8 July 2009 (UTC)
enableRefs is an interesting idea. However, if the responsibility is on the page creator, it won't get used. Any random user could produce a DPL tag without enableRefs, which is problematic for the category renaming scenario I described. I'd rather see $wgDplEnableRefs=true at the global level, or the opposite disableRefs=false (so refs are enabled by default). Maiden taiwan 03:01, 8 July 2009 (UTC)

Yes, we can ;-)

The current version of DPL already allows some sort of influence on the creation of back links.

Look at Test what links here and Test what links here 2 and check the "Special:What links here" for the page in the result set!

DPL uses an internal function to list result pages if you DO NOT USE THE FORMAT statement. This link is not caught by the wiki engine - so no backlink will appear.

If you create the output yourself by using the format statement, DPL will produce wiki text for output which is then parsed by the MW engine. So you will get backlinks.

So, those who want backlinks should use the format statement. It can of course be used in a way to generate the same kind of bullet list that is default for 'standard' output.

Those who want to use 'format' and nevertheless want to get rid of the links have to use reset or eliminate. The latter is more precise in that it only removes links generated by DPL but it needs more performance.

Gero 18:45, 8 July 2009 (UTC)

Thanks Gero, that brings some light to it. The format option hrr. Makes sense. --Subfader 19:33, 8 July 2009 (UTC)