Per https://gitlab.wikimedia.org/repos/ci-tools/patchdemo/-/issues/590#note_89788

AFAIK the comment at https://gitlab.wikimedia.org/repos/ci-tools/patchdemo/-/issues/552#note_48220 is still accurate, in that this would be the minimal configuration to load Wikibase repo and client:

wfLoadExtension( 'WikibaseRepository', "$IP/extensions/Wikibase/extension-repo.json" );
require_once "$IP/extensions/Wikibase/repo/ExampleSettings.php";
wfLoadExtension( 'WikibaseClient', "$IP/extensions/Wikibase/extension-client.json" );

T291617, which is close to done, will make the middle line unnecessary; the rest of this will still have to be hard-coded in Patch Demo, I expect (the “knowledge” about those custom extension JSON paths has to live somewhere).

I also wonder if it makes sense to present Wikibase as one extension or two. Most single Wikibase wikis use both WikibaseRepo and WikibaseClient. A repo-only wiki is possible, I think, but hardly useful (there’s not really a reason to exclude client IMHO). A client-only wiki is only possible with custom configuration, so it doesn’t really make sense in Patch Demo. So perhaps it’s easiest to just offer users one checkbox for Wikibase and make that load both repo and client together (with the above snippet).

T291617, which is close to done, will make the middle line unnecessary; the rest of this will still have to be hard-coded in Patch Demo, I expect (the “knowledge” about those custom extension JSON paths has to live somewhere).

Slight complication here. Apparently the wfLoadExtension() calls for normal extensions aren’t actually written by Patch Demo; Patch Demo calls MediaWiki’s install.php with --with-extensions, and that generates a LocalSettings.php that loads all the extensions. So if we want to call wfLoadExtension() with custom JSON paths, that information might have to live in MediaWiki core.

Fortunately, MediaWiki still supports “legacy” extensions that have a PHP file instead; if you run install.php --with-extensions now, it’ll generate a LocalSettings.php with require_once "$IP/extensions/Wikibase/Wikibase.php";. Wikibase.php, in turn, contains the two wfLoadExtension() calls that we need. (I believe this is also how Wikibase is loaded in CI.)

Due to T291617, the resulting wiki doesn’t quite work yet (the entitySources setting is missing because Wikibase.php doesn’t load the example settings), but once that’s done, I think adding Wikibase support to Patch Demo should be as simple as adding it to the relevant lists (repository-lists/all.txt, some other files in that directory, and helm/patchdemo/files/repos.cfg, I think?). This would be the “one-extension” presentation mentioned in the previous comment – the interface would present one Wikibase extension which would load both extensions internally.

Speculative merge request (insert “I have no idea what I’m doing” dog here): https://gitlab.wikimedia.org/repos/qte/catalyst/patchdemo/-/merge_requests/79

jhuneidi merged https://gitlab.wikimedia.org/repos/test-platform/catalyst/shared-repo-config/-/merge_requests/1

Add Wikibase and WikibaseLexeme

jhuneidi merged https://gitlab.wikimedia.org/repos/test-platform/catalyst/wiki-repos-pool/-/merge_requests/5

Submodule update commit

jhuneidi merged https://gitlab.wikimedia.org/repos/test-platform/catalyst/ci-charts/-/merge_requests/40

Add wikibase and wikibaselexeme

jhuneidi merged https://gitlab.wikimedia.org/repos/test-platform/catalyst/patchdemo/-/merge_requests/79

Add Wikibase and WikibaseLexeme

It’s working \o/ https://cd96b28ff7.catalyst.wmcloud.org/wiki/Special:Version

Well, mostly. I was able to create an Item and a Property, but trying to add a Statement to the Item using the UI fails. This turns out to be because mw.config.get( 'wgServer' ) is http://cd96b28ff7.catalyst.wmcloud.org/ (HTTP, not HTTPS), and Firefox blocks loading the “mixed active content”, sc. the request to http://cd96b28ff7.catalyst.wmcloud.org/w/api.php?action=wbsearchentities. (Presumably it would be possible to create a Statement using e.g. the API Sandbox; I haven’t tried it yet.)

I think this is a general Patch Demo issue (possibly limited to the Catalyst backend? no idea) which probably also affects other extensions in some way (e.g. mw.config.get( 'wgMathEntitySelectorUrl' ) is also HTTP, http://cd96b28ff7.catalyst.wmcloud.org/w/api.php), but it might be slightly worse for Wikibase than other extensions.

I’m also starting to second-guess my decision to include Wikibase in the “Wikimedia” set of extensions. Looking at it more closely, it clearly doesn’t mean “anything deployed anywhere in Wikimedia production” – e.g. FlaggedRevs and ProofreadPage aren’t included. And given that Wikibase (at least in repo mode) is only included in very few Wikimedia wikis (Wikidata and Commons plus their test versions), perhaps it should be left out of the default Patch Demo setup too.

On the other hand, including it should be mostly harmless, given that the default configuration uses a separate Item namespace (rather than usurping the main namespace, which would be more disruptive).

I noticed that both the item and the property page have an Add languages button, even though entities don’t have interlanguage links (well, items’ sitelinks are interlanguage links, but they’re somewhere else). This doesn’t happen on Wikidata, I guess it’s disabled via site configuration somehow. Shouldn’t it be the job of Wikibase to disable these buttons?

In T372960#10494320, @Lucas_Werkmeister_WMDE wrote:

It’s working \o/ https://cd96b28ff7.catalyst.wmcloud.org/wiki/Special:Version

Well, mostly. I was able to create an Item and a Property, but trying to add a Statement to the Item using the UI fails. This turns out to be because mw.config.get( 'wgServer' ) is http://cd96b28ff7.catalyst.wmcloud.org/ (HTTP, not HTTPS), and Firefox blocks loading the “mixed active content”, sc. the request to http://cd96b28ff7.catalyst.wmcloud.org/w/api.php?action=wbsearchentities. (Presumably it would be possible to create a Statement using e.g. the API Sandbox; I haven’t tried it yet.)

I think this is a general Patch Demo issue (possibly limited to the Catalyst backend? no idea) which probably also affects other extensions in some way (e.g. mw.config.get( 'wgMathEntitySelectorUrl' ) is also HTTP, http://cd96b28ff7.catalyst.wmcloud.org/w/api.php), but it might be slightly worse for Wikibase than other extensions.

I made a little change to the catalyst helm chart to solve the https problem: https://gitlab.wikimedia.org/repos/test-platform/catalyst/ci-charts/-/merge_requests/41
It is not in production yet but I have created an example wiki here if you wish to do any further testing: https://ed0c44379f.catalyst.wmcloud.org

In T372960#10494573, @Tacsipacsi wrote:

I noticed that both the item and the property page have an Add languages button, even though entities don’t have interlanguage links (well, items’ sitelinks are interlanguage links, but they’re somewhere else). This doesn’t happen on Wikidata, I guess it’s disabled via site configuration somehow. Shouldn’t it be the job of Wikibase to disable these buttons?

I think in production this is mainly disabled via $wgWBClientSettings['excludeNamespaces'] – though that doesn’t include namespace 120 (Property:) so I’m not sure why e.g. Property:P31 doesn’t show the link… but in any case, it’s definitely not related to Patch Demo (I also see those links on my local dev wiki).

In T372960#10495631, @jeena wrote:

I made a little change to the catalyst helm chart to solve the https problem: https://gitlab.wikimedia.org/repos/test-platform/catalyst/ci-charts/-/merge_requests/41
It is not in production yet but I have created an example wiki here if you wish to do any further testing: https://ed0c44379f.catalyst.wmcloud.org

Thanks, that wiki looks pretty good to me. (I added a second statement to Q1, so I think eventually its talk page should show that, once the job queue runs and reaches the dispatchChanges job. What’s the job queue setup for Patch Demo wikis? ^^)

The HTTP/HTTPS issue seems to be resolved now \o/

Adding to our Product Verification column as a potential alternative to T380031: [UX Review] [wmcloud.org] Allow cloud VPS solution to have two versions simulataneously. (As far as I’m concerned, this task is otherwise done.)

In T372960#10494323, @Lucas_Werkmeister_WMDE wrote:

I’m also starting to second-guess my decision to include Wikibase in the “Wikimedia” set of extensions. Looking at it more closely, it clearly doesn’t mean “anything deployed anywhere in Wikimedia production” – e.g. FlaggedRevs and ProofreadPage aren’t included. And given that Wikibase (at least in repo mode) is only included in very few Wikimedia wikis (Wikidata and Commons plus their test versions), perhaps it should be left out of the default Patch Demo setup too.

On the other hand, including it should be mostly harmless, given that the default configuration uses a separate Item namespace (rather than usurping the main namespace, which would be more disruptive).

I’ll leave it in the “Wikimedia” set for now, but if someone else wants to remove it (e.g. because the “add languages” button on the main page is a bit disruptive) I’m fine with that too.

In T372960#10496500, @Lucas_Werkmeister_WMDE wrote:

In T372960#10494573, @Tacsipacsi wrote:

I noticed that both the item and the property page have an Add languages button, even though entities don’t have interlanguage links (well, items’ sitelinks are interlanguage links, but they’re somewhere else). This doesn’t happen on Wikidata, I guess it’s disabled via site configuration somehow. Shouldn’t it be the job of Wikibase to disable these buttons?

I think in production this is mainly disabled via $wgWBClientSettings['excludeNamespaces'] – though that doesn’t include namespace 120 (Property:) so I’m not sure why e.g. Property:P31 doesn’t show the link…

It doesn’t show up on https://www.wikidata.org/wiki/Wikidata:List_of_policies_and_guidelines?useskin=vector-2022 either, even though it’s a Wikibase client namespace (and the page is indeed connected to an item), so it’s probably because Wikidata is configured such that simply interlanguage links don’t appear at all on Vector 2022…

but in any case, it’s definitely not related to Patch Demo (I also see those links on my local dev wiki).

I was pretty sure this is the case, which is why I wrote that hiding them should be the job of Wikibase (and not the job of the Patch Demo configuration).

In T372960#10494323, @Lucas_Werkmeister_WMDE wrote:

I’m also starting to second-guess my decision to include Wikibase in the “Wikimedia” set of extensions. Looking at it more closely, it clearly doesn’t mean “anything deployed anywhere in Wikimedia production” – e.g. FlaggedRevs and ProofreadPage aren’t included. And given that Wikibase (at least in repo mode) is only included in very few Wikimedia wikis (Wikidata and Commons plus their test versions), perhaps it should be left out of the default Patch Demo setup too.

On the other hand, including it should be mostly harmless, given that the default configuration uses a separate Item namespace (rather than usurping the main namespace, which would be more disruptive).

I’ll leave it in the “Wikimedia” set for now, but if someone else wants to remove it (e.g. because the “add languages” button on the main page is a bit disruptive) I’m fine with that too.

FTR, it has been removed now, see T393806. (Not because of the “add languages” button, but because the entity search UI was disrupting testing of the regular search.)