Page MenuHomePhabricator

Not possible to configure Minerva main menu to use Special:RandomRoot instead of Special:Random
Closed, ResolvedPublic3 Estimated Story Points


Step of Reproduce

  1. Go to
  2. Click On Menu and then Random.


should be shown only Root Random pages


There is some page comes, which is not Root Page.


The problem is that Wikiversity and like sister project have their main content in Root Pages. Subpage may be in bad condition. So Project like Wikiversity needs only show root pages.

QA steps

On beta cluster verify that

  • on mobile web, link to random page points to a random article
  • Edit the randompage-url and put different location - the Random menu entry should point to that new location

Developer notes

Per @phuedx 's excellent suggestion instead of hardcoding this make use of the MediaWiki message Mediawiki:Random-url

We have a very similar handling when it comes to inserting community portal link (

In order to make this work please

  • refactor insertCommunityPortal() into sth like buildMenuEntryFromMediaWikiMessage( $message ), and instead of hardcoded Portal-url use the $message variable
  • the insertCommunityPortal() method should call buildMenuEntryFromMediaWikiMessage( 'Portal-url' )
  • the insertRandomLink() method should call buildMenuEntryFromMediaWikiMessage( 'Random-url' )

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Jdlrobson added a subscriber: Jdlrobson.

It looks like wgContentNamespaces is not configured for that wiki.
T125948 should provide some insight into how to fix that.
This is not an issue with MobileFrontend but how the site is configured.

Framawiki renamed this task from Mobile Web Version of English Wikiversity shows Random pages instead of RootRandom Page. to Set wgContentNamespaces for English Wikiversity.Mar 4 2018, 9:31 PM
Framawiki added a subscriber: Framawiki.

Hello @Jayprakash12345 ! Can you start a community discussion to decide which namespace to consider as "content namespaces" ? Thanks !

@Framawiki :

The mobile configuration should match the desktop configuration. The Random desktop link is already configured as:

This uses the default namespace.


Hello @Jayprakash12345 ! Can you start a community discussion to decide which namespace to consider as "content namespaces" ? Thanks !

@Framawiki Dave Braunschweig Can. I am not community member of en.wikiversity. Thanks

Only namespace 0 (NS_MAIN?) is a content namespace.

We're not requesting additional functionality in this task, just consistency between mobile and desktop experiences.


TheDJ added a subscriber: TheDJ.

@Jdlrobson en.wikiversity uses a different Random link than the default in its sidemenu. Namely Special:RandomRootPage instead of Special:Random. As Minerva doesn't support MediaWiki:Sidebar, this isn't taken into account. See also:

TheDJ renamed this task from Set wgContentNamespaces for English Wikiversity to English Wikiversity uses a different Random link, which Minerva doesn't know about.Mar 5 2018, 6:54 AM

The wgContentNamespaces variable is used by a variety of content pages notably Nearby and Random. When I investigated this before for another wiki however I learned that it is a little overloaded with what it supports. I think the link updates in MediaWiki:sidebar were to route around problems with the code a long time ago but I'm not convinced they are still needed.

What are the downsides of setting wgContentNamespace to use the real content namespace? I see French wikiversity has. Won't that make the entire site better?$wgContentNamespaces

I'm also confused by the comments above which says NS_MAIN #is# a content namespace thus it should show up in random if that's the case.

Consistency aside why is this setup this way?


The best way to understand why might be the explanation at en.wikipedia: .

"Special:RandomRootpage: redirects to a random root page, that is, excluding sub-pages. Some wikis, such as Wikibooks, use a sub-page hierarchy. This extension can be used there as a substitute for Special:Random, so it can be used to show "random books" in Wikibooks, instead of random pages"

Wikiversity has the same approach. We don't want to display lesson subpages. Subpages by themselves don't always make much sense. Just as you would start at the title page of a book, you should start at the root of a lesson.

So, rather than random pages, we only show randomrootpages.

The only namespace that has content is namespace 0, the NS_MAIN namespace.


Right. Got it. So this is about subpages not namespace.

Unfortunately that's not going to work in the mobile site right now or anytime soon as we don't have a good solution for T65459.

While, making the Minerva menu customisable would solve this problem on the short term, it doesn't help making the link behave correctly on new skins and other generic mediawiki-based clients e.g. Android and iOS apps who will assume Special:Random is the canonical link.

I'm a little confused why SpecialRandomRoot was defined as a separate page rather than a default.
Does it ever make sense to visit Special:Random on a wiki that has Special:RandomRoot ?
Would it make sense if wikis such as wikiversity could change the behaviour of Special:Random to behave like Special:RandomRoot ?

Jdlrobson renamed this task from English Wikiversity uses a different Random link, which Minerva doesn't know about to Not possible to configure Minerva main menu to use Special:RandomRoot instead of Special:Random.Mar 12 2018, 6:07 PM


I think that's a valid assumption. I'm trying to think of a use case where a wiki would want RandomRoot for their main namespace but Random for one of the other namespaces. I'm not coming up with anything.

If I personally were rewriting Special:Random right now, I think it would be handy to have it support random page, random root page, and random subpage. For example, if I give it a prefix rather than just a namespace, it would find a random page in that namespace with that prefix. It's not something that would be used for the sidebar, but could be used for a variety of creative activities on projects that support subpages, such as a random chapter in a book or a random lesson in a learning project, etc. That, combined with redirect pages would make all kinds of interesting lessons possible.

In the interest of fixing the discrepancy (at the expense of punting the more general problem, captured in T65459: Allow configuration of the Minerva menu), can we update [[ | MediaWiki\Minerva\Menu\Definitions::insertRandomItem ]] to use

wfMessage( 'Mediawiki:Random-url' )->inContentLanguage()->plain()

instead of

SpecialPage::getTitleFor( 'Randompage' )->getLocalURL() . '#/random',


Jdlrobson triaged this task as Medium priority.Apr 25 2019, 4:15 AM
Jdlrobson moved this task from Incoming to Triaged but Future on the Readers-Web-Backlog board.
Jdlrobson updated the task description. (Show Details)
ovasileva set the point value for this task to 3.May 22 2019, 4:56 PM

Change 520313 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Random link in main menu can be customised

Change 520313 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Random link in main menu can be customised

Jdlrobson claimed this task.

@Jayprakash12345 please get an admin to edit entering the text Special:RandomRootpage to address this page. I've also added a note to the page. Change will go live by Thursday for all wikis.

pmiazga updated the task description. (Show Details)
pmiazga added a subscriber: pmiazga.

Pulling it into current sprint so we can properly test it, and other members are aware of this change.

Change 521471 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/skins/MinervaNeue@master] Hygiene: Do not insert Random menu entry if message do not exists

Change 521471 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Hygiene: Do not insert Random menu entry if message do not exists

Moving to blocked on others, it needs 1.34.0-wmf.13 to get live everywhere so we can verify this code on production.

This is working as intended on
Provided there are no entries in logstash this can be resolved :)

pmiazga updated the task description. (Show Details)