Last modified: 2014-01-08 19:57:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T9546, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 7546 - A page redirected to, but with no links to the redirecting page, is not considered orphaned
A page redirected to, but with no links to the redirecting page, is not consi...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
All All
: Low normal with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 26568 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2006-10-11 12:47 UTC by Vasya Pupkin
Modified: 2014-01-08 19:57 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Vasya Pupkin 2006-10-11 12:47:05 UTC
If there is a redirect page which redirects to orphaned page, neither will be shown by 
Special:Lonelypages. For example, create page "Test Page", move it to "Moved Test Page" and check 
Special:Lonelypages after that.
Comment 1 Rob Church 2006-12-23 14:20:01 UTC
This is happening because redirects cause a page link relationship to be
created, which the report interprets as the redirect target no longer being
orphaned. In addition, redirects themselves are suppressed from the result set.
Comment 2 Vasya Pupkin 2006-12-23 20:51:05 UTC
I know, but the idea is to change this behaviour somehow. Orphaned pages should not 
be lost in any way, I think.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-23 22:53:59 UTC
It would probably be easiest to just not exclude redirects.  However, we don't
want tons of redirects from typos and weird alternative spellings to show up on
the list.  The most coherent thing to do would be to list a page if it's lonely
excluding links from redirects, *and* all its redirects are lonely excluding
links to redirects (what to do about links to double+ redirects is probably not
very important).
Comment 4 Vasya Pupkin 2006-12-23 23:00:44 UTC
Well, I think the easiest way is not to count redirects as links to a page when 
checking if it is orphaned. If this is possible, of course.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-23 23:03:57 UTC
Then you can have pages linking to a redirect but none linking to the target,
and the target will effectively have incoming links but will still be listed as
Comment 6 Vasya Pupkin 2006-12-23 23:10:40 UTC
True. Then, the only way I see is to check each redirect page in chain for at least 
one reference from normal page.. But this is definetely not an easiest way.. :)
Comment 7 Mashiah Davidson 2007-01-08 01:24:31 UTC
Each article is one of three:
* An article (set 0)
* A redirect (set 1)
* A disambiguation page (set 1).

Let's the initial state for parented articles set to a set of articles linked from other articles, i.e. we 
are to check for each link if it is stated from list 0 to list 0.

Now the lonelypages list may contain articles linked from redirects (a category) or disambiguation pages 
(a category). 

For such a state of a list it is true that some pages will have more care than needed. This is much better 
than the state we have at the moment, because we do not know what do we need to attend.

After this change I see two possible ways:
1/ Each wiki works out it's own bot-/manually- created list of articles for exclusion from the lonelypages 
list. The best of the bots will serve all the wikis if it will found.
2/ The algorithm is obvious without any bot-elections and will be implemented soon =)

I think this issue is connencted to #8516 forming it's part not related to namespaces.
Comment 8 Brion Vibber 2011-02-14 02:37:55 UTC
*** Bug 26568 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.