Install it on Wikisources as well because of the same reason.

mike.lifeguard+bugs wrote:

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.

sumanah wrote:

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.

sumanah wrote:

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.

sumanah wrote:

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

aaron.adrignola wrote:

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?

https://gerrit.wikimedia.org/r/#/c/194086/ would enable it on special wikis but not wikipedias.

So all that remains is Wikipedia... @tstarling?

It's 10 lines of code (literally) so I wonder why it isn't in core yet...

In T18655#1231731, @Ricordisamoa wrote:

It's 10 lines of code (literally) so I wonder why it isn't in core yet...

I believe it is because there was this long-lasting discussion that WMF's database indices may need to be modified to support this extension fully. I feel like this is one of those MediaWiki features that is not core only because the biggest MW user (Wikimedia) may not be able to fully support it. The keyword being the word "may".

That said, this extension is already installed on select Wikimedia wikis. If you think that is enough of an indication that its should work across all WMF wikis without problem, as the person who wrote this extension in the first place I'll happily create a bug and a patch to make it core.

In my experience, different people have different views on how "inclusionist" core should be for specialized features (and furthermore, those views seem to vary with time). Personally I could see arguments both ways, and I don't think it really matters either way.

Probably having it as an extension made concerns about the filesort less controversial. But quite frankly such concerns are overblown anyways.

Change 206480 had a related patch set uploaded (by Nemo bis):
Enable RandomRootPage everywhere

https://gerrit.wikimedia.org/r/206480

Change 206480 merged by jenkins-bot:
Enable RandomRootPage on remaining sites

https://gerrit.wikimedia.org/r/206480