Last modified: 2014-11-17 09:21:12 UTC
Per bug 13051 comment 2, please install the RandomRootPage extension for Wikibooks wikis (http://www.mediawiki.org/wiki/Extension:RandomRootPage). I imagine this will require code review prior to actually doing it, so leaving out the 'shell' keyword.
Install it on Wikisources as well because of the same reason.
Nothing to do on shell until after code review.
Any update on this? Helder
I'm wondering the code review process couldn't take more than a few minutes (if not seconds). The code is totally a rework of part of the MediaWiki core code. It should be as effective and work similarly.
If it supports namespace selection, it should be actually installed on all WMF wikis (eg. Wikipedias have Portals, so do Wikinewses) or even moved to MediaWiki itself.
(In reply to comment #5) > If it supports namespace selection, it should be actually installed on all WMF > wikis (eg. Wikipedias have Portals, so do Wikinewses) or even moved to > MediaWiki itself. The extension does not support namespace selection like the core code does. which means that [[special:random/portal]] often takes the reader to pages like: http://en.wikipedia.org/wiki/Portal:British_Armed_Forces/Header http://en.wikipedia.org/wiki/Portal:Silesia/Intro Also, the extension logic excludes page names with a slash: > AND page_title NOT LIKE '%/%' which excludes pages like this: http://en.wikisource.org/wiki/9/11_Commission_Report Fixing these problems in core would be nice however special:random is really broken on Wikisource and Wikibooks, and this extension is a much needed band-aid.
I've looked at the extension and noticed it duplicates a crapload of code from SpecialRandom. It's currently 97 lines but could be reduced to like 10 by subclassing SpecialRandom and adding the LIKE clause to $this->extra.
(In reply to comment #7) > I've looked at the extension and noticed it duplicates a crapload of code from > SpecialRandom. It's currently 97 lines but could be reduced to like 10 by > subclassing SpecialRandom and adding the LIKE clause to $this->extra. It appears Reedy did this in r87598
Any progress on code review and deployment, please? This is very much needed feature for many WMF wikis.
I'm very sorry for the delay in review. Huji, could you please move the extension into Git? I also posted at https://www.mediawiki.org/wiki/Extension_talk:Randomrootpage#Review_for_deployment . Thanks.
Tim Starling reviewed this last night and said that it is ready to deploy. Tim mentioned that he wanted to deploy it, so I'm assigning to Tim.
Just a note: although this may (or may not) be rare, it is possible that a page contains "/" and is still a "root page". For example, on Wikibooks there could be a book called "Programming in C/C++" and the page "Programming in C" doesn't exist, so the root page is "Programming in C/C++" itself, and woud have probability zero of being selected by the extension.
(In reply to comment #12) > Just a note: although this may (or may not) be rare, it is possible that a page > contains "/" and is still a "root page". > For example, on Wikibooks there could be a book called "Programming in C/C++" > and the page "Programming in C" doesn't exist, so the root page is "Programming > in C/C++" itself, and woud have probability zero of being selected by the > extension. I suppose the query should depend on whether subpages are enabled in a NS... If they are enabled, and you have a title that has a /, there isn't any way to distinguish that it's not actually a subpage of the root title..
Going ahead and declining this: no way we can allow "page_title NOT LIKE '%/%'" on production servers. Please reopen this bug once the extension is rewritten to work reasonably fast (which would require a schema change).
(In reply to comment #14) > Going ahead and declining this: no way we can allow "page_title NOT LIKE '%/%'" > on production servers. Please reopen this bug once the extension is rewritten > to work reasonably fast (which would require a schema change). Provided that the majority of pages do not have a / in them, that doesn't sound exactly horrible (In my uninformed opinion). Especially when compared to the filesort that dynamicpagelist does which is installed on wikibooks... In my non-rigorous tests on the toolserver, 95% of the time for enwikibooks a suitable page would be within the first 15 pages looked at.
Like Bawolff says, the query is fast enough as long as the proportion of root pages is high enough. As long as there are more than say 1% root pages, the number of scanned rows should be tolerable.
Adding shell keyword since Tim is approving for deployment. Sam or Huji, could you please move the extension into Git, by listing it at https://www.mediawiki.org/wiki/Git/Conversion/Extensions_queue , so it can be deployed? Thanks.
I will move it to Git in the next few days.
The extension has been moved to git and the Review queue has been changed accordingly. The next step is that reedy should move the extension to the Development queue. I have notified him on his mediawiki talk page.
This is dark deployed. I'll enable it when 1.20wmf3 is live everywhere
Enabled on wikibooks and wikisource
This worked yesterday. Today the below page doesn't exist: http://en.wikibooks.org/wiki/Special:Randomrootpage
Not sure what happened. Fixed again
Reopening, as the request was to enable on all wikis. Consider portals i.e. on Wikipedias/Wikinewses etc...
(In reply to comment #24) > Reopening, as the request was to enable on all wikis. Consider portals i.e. on > Wikipedias/Wikinewses etc... (In reply to comment #16) > Like Bawolff says, the query is fast enough as long as the proportion of root > pages is high enough. As long as there are more than say 1% root pages, the > number of scanned rows should be tolerable.
Let's enable it on all wikis and disable on those which behave critical then. Like we do with other settings...
Is there anything that is blocking this request? A check for the percentage of root pages?
This currently seems to be enabled everywhere except Wikipedia and the special wikis. Is there any reason why it cannot be enabled everywhere?