Last modified: 2013-05-24 01:51:06 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2170 - Random page in this category feature
Random page in this category feature
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Normal enhancement with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 5399 15824 17068 23181 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-14 12:01 UTC by Hemanshu Desai
Modified: 2013-05-24 01:51 UTC (History)
15 users (show)

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


Attachments

Description Hemanshu Desai 2005-05-14 12:01:03 UTC
Mediawiki should have a random page in this category feature
Comment 1 Bawolff (Brian Wolff) 2006-01-26 00:12:48 UTC
wouldn't [[special:Random/Category]] do that?
Comment 2 Rob Church 2006-01-26 14:06:48 UTC
No. That retrieves a random category. The request is for a way of generating a
random page from a specified category.
Comment 3 Melancholie 2006-03-31 13:21:09 UTC
*** Bug 5399 has been marked as a duplicate of this bug. ***
Comment 4 Anthony Bentley 2006-10-05 10:12:12 UTC
My thoughts are that this could be either by adding arguments to 
SpecialRandompage or by creating a new special page for this purpose.  
SpecialRandompage currently has the argument of the namespace in which it 
searches.  
If carrying out a search within a category then shouldn't be required as 
the search would always be over the main namespace.  Not aware that users 
etc. can assign themselves to categories?
Would this only be required over the main namespace or is there a good 
reason for allowing choice of namespace?
Is category (cl_from) the only index that it's worth filtering on or is it 
worth having additional functionality to choose the index?
Comment 5 badock 2007-04-14 12:20:14 UTC
I had the same idea, but with Portals instead of Categories.
Comment 6 Dan Bolser 2007-05-31 12:06:52 UTC
The DPL extension can do this (random n pages in category X).

DPL should be a part of MediaWiki :D 
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-11-11 00:04:30 UTC
This probably needs a cl_random column.  Marking schema-change.
Comment 8 Victor Vasiliev 2007-11-11 12:34:57 UTC
Fixed in r27380.
Comment 9 Dan Bolser 2007-11-11 14:26:51 UTC
How about some docs as to how the feature works? Should I add a 'documentation' bug?
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-11-11 17:01:51 UTC
Note, the patch might not be acceptable for efficiency concerns.  It should stay in the software but might not be enabled on Wikimedia sites.
Comment 11 Melancholie 2009-01-19 14:22:21 UTC
*** Bug 17068 has been marked as a duplicate of this bug. ***
Comment 12 Melancholie 2009-01-27 00:32:39 UTC
As this is not fixed for Wikimedia wiki, a nice toolserver link:
* http://toolserver.org/~erwin85/randomarticle.php
Comment 13 Greg Ubben 2009-09-11 05:59:24 UTC
This new user script also works well for this:
* http://en.wikipedia.org/wiki/User_talk:GregU/randomlink.js
Comment 14 Happy-melon 2010-04-13 11:57:22 UTC
*** Bug 23181 has been marked as a duplicate of this bug. ***
Comment 15 Platonides 2010-04-15 11:09:13 UTC
Vasiliev implementation was reverted on r27436.

However, I don't think we can make it faster without adding a category_random, it seems quite good:

EXPLAIN SELECT page_namespace, page_title FROM page USE INDEX(page_random) JOIN categorylinks ON page_id = cl_from WHERE page_is_redirect = 0 AND page_random >= 0.15564 AND cl_to = 'GFDL' ORDER BY page_random LIMIT 1;

Both select_types SIMPLE:
+-------------+------+-----------------+-------------+------------------------+
|table        |type  |key    | key_len |ref          | Extra                  |
+-------------+------+-----------+-----+-------------+------------------------+
|page         |range |page_random|   8 |NULL         |Using where             |
|categorylinks|eq_ref|cl_from    | 261 |page_id,const|Using where; Using index|
+-------------+------+-----------+-----+-------------+------------------------+

It would change to Using temporary; Using filesort if we weren't using a LIMIT, but that's not the case.
Accessing the pages on the category is O(1), the problem is that for all the results it needs to go to page to see the page_random. And for large categories that would be a worse case of checking thousands of entries.
My testing shows that in practise it is run in a fraction of second, probably due to the index + random numbers uniformly distributed.
Comment 16 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-04-15 15:08:36 UTC
AFAICT, that will have to scan the entire page_random index in the worst case, e.g., if there are no actual pages in the category.  You left out part of the EXPLAIN -- this is full thing for me on enwiki (on toolserver).

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: page
         type: range
possible_keys: page_random
          key: page_random
      key_len: 8
          ref: NULL
         rows: 10001064
        Extra: Using where
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: categorylinks
         type: eq_ref
possible_keys: cl_from,cl_timestamp,cl_sortkey
          key: cl_from
      key_len: 261
          ref: enwiki.page.page_id,const
         rows: 1
        Extra: Using where; Using index

Note rows: 10001064.  Try running that on a large database with 'GFDL' replaced by 'Nonexistent category' and you'll see it takes forever.  It's O(N) in number of pages in the worst case, only acceptable for very small sites.
Comment 17 Platonides 2010-04-15 21:38:15 UTC
Yes, I tried to fit it into bugzilla width.
Hmm. You are right. Is it checking page table before categorylinks? Checking categorylinks first, it should be immediate if there are no pages in the category, but O(N) pages in the category otherwise.
mysql should have implemented a 2choose a random row matching this" :(
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-04-16 00:01:53 UTC
If it checks category first, it can't use the page_random index, so it's O(N log N) in the size of the category to sort its contents.  You may as well skip the page table join and ORDER BY RAND() in that case.

I don't think it would have been trivial for MySQL to implement efficient "pick a random row" without some kind of special index.  In any event, they don't, so we need cl_random if we really want this enough.
Comment 19 Alexandre Emsenhuber [IAlex] 2010-11-07 13:56:56 UTC

*** This bug has been marked as a duplicate of bug 15824 ***
Comment 20 Platonides 2010-11-07 15:13:49 UTC
Reason to close bug 15824 was the existance of http://www.mediawiki.org/wiki/Extension:RandomInCategory
Comment 21 Platonides 2010-11-07 15:14:45 UTC
*** Bug 15824 has been marked as a duplicate of this bug. ***
Comment 22 Technical 13 2013-05-23 11:29:38 UTC
Either there is no documentation for this fix or the fix was never reinstated after it was reverted.  http://www.mediawiki.org/wiki/Help_talk:Random_page/Archive_1  It is being asked for by others, and now I've found need of something like this myself on en.wikipedia.  There is a banner for Today's Article For Improvement that is currently populated using a bot and a lot of "template" style pages with less than optimal code that could greatly be simplified if I could use a [[:Special:Random/Category:This_weeks_TAFIs]] to pick a random article from a category for the week. The only "extra" that I would ask is that the page would be picked on page load instead of clicking on the link so that the link when using the "piping trick" would show the name of the article it was going to take you to.  Can this be done?
Comment 23 Technical 13 2013-05-24 00:13:08 UTC
(In reply to comment #22)
> Either there is no documentation for this fix or the fix was never reinstated
> after it was reverted.
> http://www.mediawiki.org/wiki/Help_talk:Random_page/Archive_1  It is being
> asked for by others, and now I've found need of something like this myself on
> en.wikipedia.  There is a banner for Today's Article For Improvement that is
> currently populated using a bot and a lot of "template" style pages with less
> than optimal code that could greatly be simplified if I could use a
> [[:Special:Random/Category:This_weeks_TAFIs]] to pick a random article from a
> category for the week. The only "extra" that I would ask is that the page
> would be picked on page load instead of clicking on the link so that the link
> when using the "piping trick" would show the name of the article it was going
> to take you to.  Can this be done?

http://en.wikipedia.org/wiki/Wikipedia_talk:Today%27s_articles_for_improvement#Teahouse_TAFI_banner is the link to the full discussion for using this feature.
Comment 24 Kunal Mehta (Legoktm) 2013-05-24 01:19:05 UTC
(In reply to comment #22)
> Either there is no documentation for this fix or the fix was never reinstated
> after it was reverted. 

No, the extension in comment 20 was simply never deployed to WMF sites.
Comment 25 Technical 13 2013-05-24 01:48:16 UTC
(In reply to comment #24)
> (In reply to comment #22)
> > Either there is no documentation for this fix or the fix was never reinstated
> > after it was reverted. 
> 
> No, the extension in comment 20 was simply never deployed to WMF sites.

Can this bug be re-opened since there was no actual implemented fix?
Comment 26 Kunal Mehta (Legoktm) 2013-05-24 01:51:06 UTC
(In reply to comment #25)

> Can this bug be re-opened since there was no actual implemented fix?

No, this bug (implementing such a feature in MediaWiki) is fixed. If you want it deployed on enwiki or another WMF site, file a new bug under the Wikimedia category.

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


Navigation
Links