Page MenuHomePhabricator

Enable arbitrary access on Beta Wikiversity
Open, MediumPublic

Description

As suggested by @StevenJ81 at T54971#4735320, let's try to enabe property support before sitelinks here.

(I'm not sure if there are "attempt to index field 'wikibase' (a nil value)" issues or not...), anyway posted locally

Event Timeline

Does this still need community consensus as it is tagged?

Reedy added a subscriber: Reedy.

No, I don't think so, it's a beta wiki. It's for testing stuff

@Reedy , while I agree with the first clause of your statement, I must correct the latter one: Beta Wikiversity is not a beta wiki for testing stuff like testwikipedia or testwikidata are. It is a full fledged content Wikimedia project being that to separate Wikiversities what Wikimedia Incubator is to separate Wikipedias, Wikivoyages, Wiktionaries, and Wikinewses.

@Reedy , while I agree with the first clause of your statement, I must correct the latter one: Beta Wikiversity is not a beta wiki for testing stuff like testwikipedia or testwikidata are. It is a full fledged content Wikimedia project being that to separate Wikiversities what Wikimedia Incubator is to separate Wikipedias, Wikivoyages, Wiktionaries, and Wikinewses.

Ugh. Yeah. This is why we shouldn't reuse names like we do. See also naming things is h ard

Maybe the only way to address what @Reedy concerns above, is to rename the root url of this wiki to https://mul.wikiversity.org/ (like T64717), but that's a separated question.

Dear Beta Wikiversity admins: what's the status of local discussion? Looks like no further comments after my posting?!

I a

Dear Beta Wikiversity admins: what's the status of local discussion? Looks like no further comments after my posting?!

I am an admin, but I do not think this requires community consensus. At least I cannot remember that there has been community consensus on every single wiki where arbitrary access has been rolled out.

Lea_Lacroix_WMDE moved this task from Incoming to Needs Work on the Wikidata-Campsite board.
Lea_Lacroix_WMDE added a subscriber: Lea_Lacroix_WMDE.

We're going to move forward with this. Next steps:

  • update and improve task description
  • get details about how we can enable arbitrary access without coupling it with enabling sitelinks
Addshore added subscribers: Ladsgroup, Addshore.

We're going to move forward with this. Next steps:

  • update and improve task description
  • get details about how we can enable arbitrary access without coupling it with enabling sitelinks

Regarding the second point:

I spent one hour digging the code and apparently sitelinks stuff and client are different things. The way that sitelinks in repo works is (according to SiteLinkTargetProvider) and then get valid groups + special wikis and then discards everything else. Meaning as long as we are not adding 'sources' to $wgWBClientSettings['specialSiteLinkGroups'] and $wgWBRepoSettings['specialSiteLinkGroups'], we are fine. It's interesting to see 'oldwikisource' is not a 'wikisource' but a 'sources' wiki but if anyone fixes it, it will accidentally enable sitelinks for oldwikisource.

If we want to enable client on sourceswiki, we need to add it to the client dblist and pull it on mwmaint1002, make the tables and then just sync the dblist everywhere. I can do it later.

wikiversity is not configured to work with sitelinks, so you won't be able to add them unless we explicitly add it.