Note that this probably involves a lot more than just installing the Wikibase extension; we want to be able to be a client of wikidata.org, but currently Wikibase Client does not support repositories which it does not have direct database access to. T209880: [Investigation - 8h] technical overview of current db based Wikibase federation & blockers to get to an API based federation has some information on the topic.

Other somewhat relevant tasks/links:

• T216112: Support data sharing in complex networks of MediaWiki wikis
• T192911: Build an FAQ for Wikibase federation
• T196997: Wikidata/Wikibase federation and distribution (for Wikidocumentaries)
• Wikibase registry

@Sannita has some ideas relevant to this, detailed at: https://meta.wikimedia.org/wiki/User:Sannita/Sandbox

To be clear, this request would allow us to still have standard running text MediaWiki pages on Wikispore and not convert it into a Wikidata-style database, correct?

In T231897#5935369, @Koavf wrote:

To be clear, this request would allow us to still have standard running text MediaWiki pages on Wikispore and not convert it into a Wikidata-style database, correct?

Yes, it would be a complement to the text MediaWiki pages, and probably a way of helping to sort them, in a somewhat similar way to categories.

Well, Wikidata itself also allows having standard text pages. They have chosen to reserve the main namespace for items, but it could be any other namespace.

To be a little more clear, there are two separate Wikibase extensions: Wikibase Client which allows connecting to a Wikibase instance somewhere else (although currently it has to be on the same DB cluster) and Wikibase Repo which is the Wikidata-style semantic database thing (currently installed on two Wikimedia wikis with very different configuration, Wikidata and Commons).

The LinkedWiki and Semantic Wikibase extensions would be possible options to explore.

Another options (mentioned on #mwstake-general:matrix.org recently): WikidataShow, WikibaseFetcher (very WIP), External Data (looks painful)

I've been working a bit on UnlinkedWikibase (which is what I renamed WikibaseFetcher to… although I don't know if it's actually a better name). The idea is basically that it provides the following:

• way to get a single entity: mw.ext.UnlinkedWikibase.getEntity( 'Q42' )
• page property that links a wiki page to a (single) Wikibase ID: {{#unlinkedwikibase: id=Q42 }}
• lookup to find the local wiki page for a given Wikibase ID: mw.ext.UnlinkedWikidata.getLocalTitle( 'Q42' )
• Sparql query method: mw.ext.UnlinkedWikibase.query( 'SELECT … ' )

The main issues with it are around caching, because some things (especially Sparql queries) can take a while and so slow down parsing. It's actually working really well in my experimenting though, and makes it easy to make Wikidata-powered infoboxes on any non-Wikimedia wiki. Here's an example: https://freo.wiki/Leake_Street

Of course, it might still be good to install Wikibase on Wikispore, because there's metadata that doesn't belong on Wikidata but which should still be kept somewhere. Is this task about that, or about linking with Wikidata?

If you'll see above c. 2020-03-03, this is mostly a matter of doing things like storing interwiki links and making Wikidata-powered infoboxes, not having locally stored databases at Wikispore.

@Koavf Sure, I just wanted to check I was understanding. :-) So I think something like UnlinkedWikibase would be a reasonable solution to this — unless Wikispore is able to become an actual Wikimedia project, or Wikibase changes to support federation better (which I think is planned, but is possibly a while away… not that I know anything about it).

In T231897#8172759, @Samwilson wrote:

Of course, it might still be good to install Wikibase on Wikispore, because there's metadata that doesn't belong on Wikidata but which should still be kept somewhere. Is this task about that, or about linking with Wikidata?

Let's split. Filed T315954: Install Wikibase on Wikispore as a local knowledge base for the other one.

I think MediaWiki-extensions-UnlinkedWikibase is ready to be installed on Wikispore, if it's thought that it's worth giving it a go.

It can be installed with Composer: add "samwilson/unlinked-wikibase": "^1.0" to composer.local.json.

Change 833135 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/vagrant@master] Add role for UnlinkedWikibase extension

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

Change 833135 merged by jenkins-bot:

[mediawiki/vagrant@master] Add role for UnlinkedWikibase extension

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

Created a vagrant role for UnlinkedWikibase, and am trying to install it on wikispore-test.

The vagrant git-update command is failing with:

PHP Fatal error: Class 'PluggableAuth' not found in /vagrant/mediawiki/extensions/WSOAuth/src/AuthProviderFramework.php on line 21

I guess WSOAuth needs update for rEPLGa28e6bed06e9: Added namespace to classes.

It looks like the namespaces work was done in 771941: Add support for PluggableAuth 6.0 (in which the AuthProviderFramework.php file was also renamed), so I guess that means the latest version isn't being pulled by the git update.

Oh!! It's because WSOAuth is no longer hosted at https://github.com/WikibaseSolutions/WSOAuth, but the Vagrant config hasn't been updated. I'll fix that up.

Change 834622 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/vagrant@master] Remove WSOAuth extension's Git URL, as it's now on Gerrit

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

Change 834622 merged by jenkins-bot:

[mediawiki/vagrant@master] Remove WSOAuth extension's Git URL, as it's now on Gerrit

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

The test site is back up. 🎉

Next issues:

<b>Deprecated</b>:  Hook PersonalUrls was deprecated in MediaWiki 1.39 but is registered in /vagrant/mediawiki/extensions/PluggableAuth/extension.json in <b>/vagrant/mediawiki/includes/debug/MWDebug.php</b> on line <b>381</b><br />

Tracked in T318213 (and I've made a patch).

…and:

==> Updating /vagrant/mediawiki/extensions/SpecialNamespaces ...
***** GIT PULL failed in /vagrant/mediawiki/extensions/SpecialNamespaces for branch 'master'

This I fixed by deleting the extensions/SpecialNamespaces directory and re-running vagrant provision.

In T231897#8257276, @Samwilson wrote:

==> Updating /vagrant/mediawiki/extensions/SpecialNamespaces ...
***** GIT PULL failed in /vagrant/mediawiki/extensions/SpecialNamespaces for branch 'master'

That means there was some change in that repository, either something uncommitted, or committed but merge conflicting with latest master. Probably a bugfix or bugfix attempt (although if it was functional and even remotely important, you can find it on production Wikispore).

Ah, sorry I should've thought to check! There's no changes made to prod for that extension, so I assume whatever hotfix was there isn't important. I've been working on SpecialNamespaces (T191635: Convert SpecialNamespaces to use extension registration) so am happy to work on whatever shortcomings there are there, and the latest code (that's now on the test site) is running fine I think.

I think the prod site is nearly ready to update. I just want to get OAuth working on the test site (or has that never worked?). And do you think it's worth fixing T318213 first?

In T231897#8258011, @Samwilson wrote:

I assume whatever hotfix was there isn't important.

IIRC SpecialNamespaces stopped working correctly with MW master something like a year ago, and I was trying to fix that. I'm sure I would have upstreamed it if the fix actually worked, but we are likely to run into the problem again.

Looking at the error logs, there's a bunch of

2020-08-02 15:10:04 mediawiki-vagrant wiki: [39247da1240b6bef8da8c007] /wiki/Main_Page   Error from line 122 of /vagrant/mediawiki/extensions/SpecialNamespaces/SpecialNamespaces.php: Call to a member function get() on null
#0 /vagrant/mediawiki/includes/HookContainer/HookContainer.php(320): fnNamespaceHook(array)
#1 /vagrant/mediawiki/includes/HookContainer/HookContainer.php(131): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)
#2 /vagrant/mediawiki/includes/HookContainer/HookRunner.php(1098): MediaWiki\HookContainer\HookContainer->run(string, array)
#3 /vagrant/mediawiki/includes/title/NamespaceInfo.php(394): MediaWiki\HookContainer\HookRunner->onCanonicalNamespaces(array)
#4 /vagrant/mediawiki/languages/Language.php(589): NamespaceInfo->getCanonicalNamespaces()
#5 /vagrant/mediawiki/languages/Language.php(665): Language->getNamespaces()
#6 /vagrant/mediawiki/includes/title/MediaWikiTitleCodec.php(109): Language->getNsText(integer)
#7 /vagrant/mediawiki/includes/title/MediaWikiTitleCodec.php(139): MediaWikiTitleCodec->getNamespaceName(integer, string)
#8 /vagrant/mediawiki/includes/title/MediaWikiTitleCodec.php(261): MediaWikiTitleCodec->formatTitle(integer, string, string, string)
#9 /vagrant/mediawiki/includes/cache/LinkCache.php(169): MediaWikiTitleCodec->getPrefixedDBkey(TitleValue)
#10 /vagrant/mediawiki/includes/cache/LinkBatch.php(215): LinkCache->addGoodLinkObjFromRow(TitleValue, stdClass)
#11 /vagrant/mediawiki/includes/OutputPage.php(1438): LinkBatch->addResultToCache(LinkCache, Wikimedia\Rdbms\ResultWrapper)
#12 /vagrant/mediawiki/includes/OutputPage.php(1371): OutputPage->addCategoryLinksToLBAndGetResult(array)
#13 /vagrant/mediawiki/includes/OutputPage.php(1882): OutputPage->addCategoryLinks(array)
#14 /vagrant/mediawiki/includes/OutputPage.php(2016): OutputPage->addParserOutputMetadata(ParserOutput)
#15 /vagrant/mediawiki/includes/page/Article.php(742): OutputPage->addParserOutput(ParserOutput, array)
#16 /vagrant/mediawiki/includes/actions/ViewAction.php(74): Article->view()
#17 /vagrant/mediawiki/includes/MediaWiki.php(527): ViewAction->show()
#18 /vagrant/mediawiki/includes/MediaWiki.php(313): MediaWiki->performAction(Article, Title)
#19 /vagrant/mediawiki/includes/MediaWiki.php(940): MediaWiki->performRequest()
#20 /vagrant/mediawiki/includes/MediaWiki.php(543): MediaWiki->main()
#21 /vagrant/mediawiki/index.php(53): MediaWiki->run()
#22 /vagrant/mediawiki/index.php(46): wfIndexMain()
#23 /var/www/w/index.php(5): require(string)
#24 {main}

from last August, so maybe that was it.

Then again, that was on one-year.old core code, so if it magically fixed itself, all the better.

I just want to get OAuth working on the test site

You mean WSOAuth, right? It did work.

And do you think it's worth fixing T318213 first?

If it's just a deprecation at this point, no reason to block an update on it.

Call to a member function get() on null

I guess this is about the cache not being configured or something? It's using the LocalServerObjectCache but I'd have thought the WANObjectCache would be better for this. Anyway, it doesn't seem to be happening now.

You mean WSOAuth, right? It did work.

Yep, sorry that's right! I'll get it working again (unless you know what I've broken?). :-)

Filed T318527: Improve logging in WSOAuth for the WSOAuth issue.

Is this done?