Hi Adam,

Many thanks for this!

Not sure if correct, but what I understood is that $wgServer should be defined with HTTPS (fixing the mixed content API issue), and then we should explicitly override the baseUri for the RDF exports to ensure it uses HTTP, not HTTPs. Along these lines, in LocalSettings.php (of the wikibase container), I changed the following:

$wgServer = "https://qawiki.org"; // now HTTPS $wgCanonicalServer = $wgServer;

// an old setting that doesn't doesn't seem to do anything ... $wgWBRepoSettings['repoApiBaseUri'] = 'https://qawiki.org/w/api.php';

// added ... $wgWBRepoSettings['entitySources']['local']['baseUri'] = "http://qawiki.org/entity/"; $wgWBClientSettings['entitySources']['local']['baseUri'] = "http://qawiki.org/entity/";

$wgResourceLoaderUseHTTPS = true; $wgSecureLogin = true; $wgCookieSecure = true; $wgUsePathInfo = true;

Upon restarting the container, visiting the site via the browser gives me the error:

[c500a0c6a4c1bbba6a18104a] 2025-05-22 21:07:59: Fatal exception of type "InvalidArgumentException"

I assume this is because the array in which I am trying to set the values doesn't exist yet, and perhaps I need to assign $wgWBClientSettings elsewhere, not in LocalSettings.php? Or I need to load something via LocalSettings.php before setting these values?

Best/thanks, Aidan

On 2025-05-22 02:57, Addshore wrote:

Hi hi!

Looking through the docs, this certainly isn't the easiest thing to figure out at all.

This is something you can fix, if you did want to convert to https URIs. But converting is your choice and everything should be able to work either way around. It looks like I wrote up changing the concept URI of a wikibase and query service in docker images some time ago at https:// addshore.com/2019/11/changing-the-concept-uri-of-an-existing-wikibase- with-data/ <https://addshore.com/2019/11/changing-the-concept-uri-of-an- existing-wikibase-with-data/>

I think (but someone that looks at the codebase more these days would have to confirm) that you can set the concept URIs in this entity sources config https://doc.wikimedia.org/Wikibase/master/php/ docs_topics_entitysources.html#autotoc_md228 <https://doc.wikimedia.org/ Wikibase/master/php/docs_topics_entitysources.html#autotoc_md228> This would mean that you can make mediawiki be https everywhere, and just set the concept uris to be http

By default this config comes from this place i think https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/ repo/config/Wikibase.default.php#L345-L378 <https://github.com/ wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/config/ Wikibase.default.php#L345-L378> And you can see the baseuri setting there too https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/ repo/config/Wikibase.default.php#L369C6-L369C42 <https://github.com/ wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/config/ Wikibase.default.php#L369C6-L369C42> By default, *$wgServer . '/entity/'*

So perhaps something like this might work....

$wgWBRepoSettings['entitySources']['local']['baseUri'] = "<new base uri>"; $wgWBClientSettings['entitySources']['local']['baseUri'] = "<new base uri>";

Adam

On Thu, 22 May 2025 at 04:04, Aidan Hogan <aidhog@gmail.com mailto:aidhog@gmail.com> wrote:

Hi all,

I am running a Wikibase instance at https://qawiki.org/ <https://
qawiki.org/> via Docker. The
version I am running is wikibase-bundle:1.36.3-wmde.4. (I considered
updating to the latest version, but it seems daunting.) I've recently
switched to HTTPS hosting, but have not managed to get the Wikibase
config working fully.

I wish to keep HTTP IRIs for the RDF/SPARQL service (otherwise the WDQS
updater skips all entities and/or if I force HTTPS, the query service
still uses HTTP prefixes), so I set in LocalSettings.php:

$wgServer = "http://qawiki.org <http://qawiki.org>";
$wgCanonicalServer = $wgServer;

To enable HTTPS elsewhere, I've tried setting:

$wgWBRepoSettings['repoApiBaseUri'] = 'https://qawiki.org/w/api.php
<https://qawiki.org/w/api.php>';
$wgSecureLogin = true;
$wgCookieSecure = true;
$wgUsePathInfo = true;
$wgResourceLoaderStorageVersion = 2;

Everything is mostly working okay, except some API calls are
directed to
HTTP, and fail due to mixed content. For example, visiting:

https://qawiki.org/ <https://qawiki.org/>

and tying "w" in the search bar should provide autocomplete
suggestions,
but the call is heading to:

http://qawiki.org/w/api.php?
action=wbsearchentities&search=What%20is%20the&format=json&errorformat=plaintext&language=en&uselang=en&type=item <http://qawiki.org/w/api.php?action=wbsearchentities&search=What%20is%20the&format=json&errorformat=plaintext&language=en&uselang=en&type=item>

and is being blocked for mixed content. I don't know why it generates a
HTTP URL, but I guess it relates to $wgServer.

If I set $wgServer to HTTPS, these issues disappear, but then the WDQS
updater no longer works, and if I manually update with

         --conceptUri https://qawiki.org/ <https://qawiki.org/>

the WDQS prefixes still use HTTP, and it breaks some application
queries.

Any help on how to "force" the front-end to call the API via HTTPS
(ideally without changing $wgServer, which seems to break WDQS)
would be
appreciated!

Best,
Aidan
_______________________________________________
Wikibase Community User Group mailing list --
wikibaseug@lists.wikimedia.org <mailto:wikibaseug@lists.wikimedia.org>
To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org
<mailto:wikibaseug-leave@lists.wikimedia.org>

---

Wikibase Community User Group mailing list -- wikibaseug@lists.wikimedia.org To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org

Hi Deepesha, Adam, all,

[Replying to an old thread from May last year ...]

I've been very busy the past few months, so didn't have time to solve this, but I appreciate again the help! I'm also happy to say that I finally got around to updating the Wikibase version to the latest, and with some wrangling, I seem to have a clean/functional/secure/up-to-date instance of Wikibase up and running for QAWiki:

https://qawiki.org/

In case it might be of interest to others, the one complication I had was to stop "too many redirects" problems, relating to some interaction between our institution's upper-level nginx setup (which I do not have access to) and traefik, bouncing HTTP -> HTTPS redirects around. I did not manage to fully debug this as I do not have access to the upper nginx configuration, but the solution was to disable all of traefik's HTTPS configurations in docker-compose.yml (with the idea, I assume, that the upper-level nginx is taking care of that). Will copy below the configuration for posterity. After this, I managed to import the old dump fine and update it. I updated ElasticSearch manually, and was in the process of doing the same (and failing) for WDQS when I realised it had already been done automatically from the relational database (just took some time). Then some minor configurations were left, and all good.

Overall the newer version seems much easier and cleaner to manage.

Best/thanks, Aidan

-----------------------------------------------------------------------

# This is the reverse proxy and SSL service traefik: image: traefik:3 command: # traefik static configuration via command line # enable accesslog - "--accesslog.format=common" # http endpoint - "--entrypoints.web.address=:80" # https endpoint # - "--entrypoints.websecure.address=:443" # - "--entrypoints.websecure.asdefault" # - "--entrypoints.websecure.http.tls.certresolver=letsencrypt" # http to https redirect # - "--entrypoints.web.http.redirections.entryPoint.to=websecure" # - "--entrypoints.web.http.redirections.entryPoint.scheme=https" # - "--entrypoints.web.http.redirections.entrypoint.permanent=true" # ACME SSL certificate generation # - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true" # - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" # - "--certificatesresolvers.letsencrypt.acme.email=${MW_ADMIN_EMAIL}" # - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" # additionial traefik dynamic configuration via config file - "--providers.file.filename=/etc/traefik/dynamic.yml" # Uncomment this line to only test ssl generation first, makes sure you don't run into letsencrypt rate limits # - "--certificatesresolvers.letsencrypt.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory" # Uncomment the following line for debugging, also expose port 8080 below # - "--api.dashboard=true" # - "--api.insecure=true" # - "--log.level=DEBUG" restart: unless-stopped ports: - 80:80 # - 443:443 # traefik dashboard # - 8080:8080 volumes: - ./config/traefik-dynamic.yml:/etc/traefik/dynamic.yml:ro - traefik-letsencrypt-data:/letsencrypt environment: WIKIBASE_PUBLIC_HOST: ${WIKIBASE_PUBLIC_HOST} WDQS_PUBLIC_HOST: ${WDQS_PUBLIC_HOST}

On 2025-05-28 05:44, Deepesha Burse wrote:

Hi Aidan,

Thanks a lot for raising this issue. Since you're on a version that has not been supported for over 3 years <https://www.mediawiki.org/wiki/ Version_lifecycle>, I would suggest you to try to update to the latest deploy version. Deploy supports https out of the box and also receives updates. But I see that you're finding it hard to update to the latest version, do you mind sharing where you are getting stuck? Maybe we can find a solution for that and that fixes this issue too?

Thank you :)

Best,

On Thu, May 22, 2025 at 11:26 PM Aidan Hogan <aidhog@gmail.com mailto:aidhog@gmail.com> wrote:

Hi Adam,

Many thanks for this!

Not sure if correct, but what I understood is that $wgServer should be
defined with HTTPS (fixing the mixed content API issue), and then we
should explicitly override the baseUri for the RDF exports to ensure it
uses HTTP, not HTTPs. Along these lines, in LocalSettings.php (of the
wikibase container), I changed the following:

$wgServer = "https://qawiki.org <https://qawiki.org>";  // now HTTPS
$wgCanonicalServer = $wgServer;

// an old setting that doesn't doesn't seem to do anything ...
$wgWBRepoSettings['repoApiBaseUri'] = 'https://qawiki.org/w/api.php
<https://qawiki.org/w/api.php>';

// added ...
$wgWBRepoSettings['entitySources']['local']['baseUri'] =
"http://qawiki.org/entity/ <http://qawiki.org/entity/>";
$wgWBClientSettings['entitySources']['local']['baseUri'] =
"http://qawiki.org/entity/ <http://qawiki.org/entity/>";

$wgResourceLoaderUseHTTPS = true;
$wgSecureLogin = true;
$wgCookieSecure = true;
$wgUsePathInfo = true;

Upon restarting the container, visiting the site via the browser gives
me the error:

[c500a0c6a4c1bbba6a18104a] 2025-05-22 21:07:59: Fatal exception of type
"InvalidArgumentException"

I assume this is because the array in which I am trying to set the
values doesn't exist yet, and perhaps I need to assign
$wgWBClientSettings elsewhere, not in LocalSettings.php? Or I need to
load something via LocalSettings.php before setting these values?

Best/thanks,
Aidan

On 2025-05-22 02:57, Addshore wrote:
 > Hi hi!
 >
 > Looking through the docs, this certainly isn't the easiest thing to
 > figure out at all.
 >
 > This is something you can fix, if you did want to convert to
https URIs.
 > But converting is your choice and everything should be able to work
 > either way around.
 > It looks like I wrote up changing the concept URI of a wikibase and
 > query service in docker images some time ago at https://
 > addshore.com/2019/11/changing-the-concept-uri-of-an-existing-
wikibase- <http://addshore.com/2019/11/changing-the-concept-uri-of-
an-existing-wikibase->
 > with-data/ <https://addshore.com/2019/11/changing-the-concept-
uri-of-an- <https://addshore.com/2019/11/changing-the-concept-uri-
of-an->
 > existing-wikibase-with-data/>
 >
 > I think (but someone that looks at the codebase more these days
would
 > have to confirm)
 > that you can set the concept URIs in this entity sources config
 > https://doc.wikimedia.org/Wikibase/master/php/ <https://
doc.wikimedia.org/Wikibase/master/php/>
 > docs_topics_entitysources.html#autotoc_md228 <https://
doc.wikimedia.org/ <https://doc.wikimedia.org/>
 > Wikibase/master/php/docs_topics_entitysources.html#autotoc_md228>
 > This would mean that you can make mediawiki be https everywhere, and
 > just set the concept uris to be http
 >
 > By default this config comes from this place i think
 > https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/
master/ <https://github.com/wikimedia/mediawiki-extensions-Wikibase/
blob/master/>
 > repo/config/Wikibase.default.php#L345-L378 <https://github.com/
<https://github.com/>
 > wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/config/
 > Wikibase.default.php#L345-L378>
 > And you can see the baseuri setting there too
 > https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/
master/ <https://github.com/wikimedia/mediawiki-extensions-Wikibase/
blob/master/>
 > repo/config/Wikibase.default.php#L369C6-L369C42 <https://
github.com/ <https://github.com/>
 > wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/config/
 > Wikibase.default.php#L369C6-L369C42>
 > By default, *$wgServer . '/entity/'*
 >
 > So perhaps something like this might work....
 >
 > $wgWBRepoSettings['entitySources']['local']['baseUri'] = "<new
base uri>";
 > $wgWBClientSettings['entitySources']['local']['baseUri'] = "<new
base uri>";
 >
 > Adam
 >
 > On Thu, 22 May 2025 at 04:04, Aidan Hogan <aidhog@gmail.com
<mailto:aidhog@gmail.com>
 > <mailto:aidhog@gmail.com <mailto:aidhog@gmail.com>>> wrote:
 >
 >     Hi all,
 >
 >     I am running a Wikibase instance at https://qawiki.org/
<https://qawiki.org/> <https://
 > qawiki.org/ <http://qawiki.org/>> via Docker. The
 >     version I am running is wikibase-bundle:1.36.3-wmde.4. (I
considered
 >     updating to the latest version, but it seems daunting.) I've
recently
 >     switched to HTTPS hosting, but have not managed to get the
Wikibase
 >     config working fully.
 >
 >     I wish to keep HTTP IRIs for the RDF/SPARQL service
(otherwise the WDQS
 >     updater skips all entities and/or if I force HTTPS, the query
service
 >     still uses HTTP prefixes), so I set in LocalSettings.php:
 >
 >     $wgServer = "http://qawiki.org <http://qawiki.org> <http://
qawiki.org <http://qawiki.org>>";
 >     $wgCanonicalServer = $wgServer;
 >
 >     To enable HTTPS elsewhere, I've tried setting:
 >
 >     $wgWBRepoSettings['repoApiBaseUri'] = 'https://qawiki.org/w/
api.php <https://qawiki.org/w/api.php>
 >     <https://qawiki.org/w/api.php <https://qawiki.org/w/api.php>>';
 >     $wgSecureLogin = true;
 >     $wgCookieSecure = true;
 >     $wgUsePathInfo = true;
 >     $wgResourceLoaderStorageVersion = 2;
 >
 >     Everything is mostly working okay, except some API calls are
 >     directed to
 >     HTTP, and fail due to mixed content. For example, visiting:
 >
 > https://qawiki.org/ <https://qawiki.org/> <https://qawiki.org/
<https://qawiki.org/>>
 >
 >     and tying "w" in the search bar should provide autocomplete
 >     suggestions,
 >     but the call is heading to:
 >
 > http://qawiki.org/w/api.php <http://qawiki.org/w/api.php>?
 >   
  action=wbsearchentities&search=What%20is%20the&format=json&errorformat=plaintext&language=en&uselang=en&type=item <http://qawiki.org/w/api.php?action=wbsearchentities&search=What%20is%20the&format=json&errorformat=plaintext&language=en&uselang=en&type=item <http://qawiki.org/w/api.php?action=wbsearchentities&search=What%20is%20the&format=json&errorformat=plaintext&language=en&uselang=en&type=item>>
 >
 >     and is being blocked for mixed content. I don't know why it
generates a
 >     HTTP URL, but I guess it relates to $wgServer.
 >
 >     If I set $wgServer to HTTPS, these issues disappear, but then
the WDQS
 >     updater no longer works, and if I manually update with
 >
 >              --conceptUri https://qawiki.org/ <https://
qawiki.org/> <https://qawiki.org/ <https://qawiki.org/>>
 >
 >     the WDQS prefixes still use HTTP, and it breaks some application
 >     queries.
 >
 >     Any help on how to "force" the front-end to call the API via
HTTPS
 >     (ideally without changing $wgServer, which seems to break WDQS)
 >     would be
 >     appreciated!
 >
 >     Best,
 >     Aidan
 >     _______________________________________________
 >     Wikibase Community User Group mailing list --
 > wikibaseug@lists.wikimedia.org
<mailto:wikibaseug@lists.wikimedia.org>
<mailto:wikibaseug@lists.wikimedia.org
<mailto:wikibaseug@lists.wikimedia.org>>
 >     To unsubscribe send an email to wikibaseug-
leave@lists.wikimedia.org <mailto:wikibaseug-leave@lists.wikimedia.org>
 >     <mailto:wikibaseug-leave@lists.wikimedia.org
<mailto:wikibaseug-leave@lists.wikimedia.org>>
 >
 >
 > _______________________________________________
 > Wikibase Community User Group mailing list --
wikibaseug@lists.wikimedia.org <mailto:wikibaseug@lists.wikimedia.org>
 > To unsubscribe send an email to wikibaseug-
leave@lists.wikimedia.org <mailto:wikibaseug-leave@lists.wikimedia.org>

_______________________________________________
Wikibase Community User Group mailing list --
wikibaseug@lists.wikimedia.org <mailto:wikibaseug@lists.wikimedia.org>
To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org
<mailto:wikibaseug-leave@lists.wikimedia.org>

-- Deepesha Burse Developer Advocate

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30-577 11 62-0 https://wikimedia.de https://wikimedia.de

Keep up to date! Current news and exciting stories about Wikimedia, Wikipedia and Free Knowledge in our newsletter (in German): Subscribe now.

Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de https://spenden.wikimedia.de Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. Geschäftsführende Vorstände: Franziska Heine.

---

Wikibase Community User Group mailing list -- wikibaseug@lists.wikimedia.org To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org

At Rhizome, we do it this way:

1. Get the full TTL dump from Wikibase:

docker compose exec php ./extensions/Wikibase/repo/maintenance/dumpRdf.php --server https://artbase.rhizome.org --output /tmp/db-dumps/dump.ttl

Set the output path to a directory that is mounted into the wikibase and the wdqs container, so it can be accessed by both. In this case it is /tmp/db-dumps

2. "Munge" data for import... this is doing some unknown-to-me things to the data so the import works as intended, turned out to be important:

docker compose  exec wdqs ./munge.sh -f /tmp/db-dumps/$DATESTR.ttl -d /tmp/db-dumps/mungedOut -- --conceptUri https://artbase.rhizome.org

Set the concept URL to match your Wikibase's settings.

3. Clear Blazegraph:

docker compose exec wdqs curl "http://localhost:9999/bigdata/namespace/wdq/sparql" --data-urlencode "update=DROP ALL;"

This sends the a command to Blazegraph to drop all data.

4. Load dump into Blazegraph:

docker compose exec wdqs ./loadData.sh -n wdq -d /tmp/db-dumps/mungedOut

Hope this helps!

Yours, Dragan

On 11.02.26 21:07, Aidan Hogan via Wikibase Community User Group wrote:

Hi all,

Indeed I spoke a *tad* too soon in that I think the re-indexing of RDF for WDQS in query.qawiki.org was not complete / correct, and new items are not being indexed. I cannot seem to find some up-to-date documentation on how to do this part of repopulating WDQS. Ideally, I would like the RDF to be indexed with http:// IRIs after loading in the SQL dump from a legacy instance of Wikibase. Below I'll indicate where I am in the process thus far.

What is the recommended way to rebuild and index the RDF dump in WDQS assuming the SQL database has already been populated?

Best/thanks! Aidan

---

Process thus far:

• Installed WBS Deploy 5.0.1 in Docker.

• Dumped the SQL database from the old instance, brought it down,

brought up the new deploy.

• Loaded the SQL database into the new deploy and run

maintenance/update.php (I know this is deprecated, but I could not get the new run.php script to work, and the old script seems to have done the job)

• Built the indexes/aliases for elasticsearch/cirrus and indexed the

new content (seems to be fine).

• Run various jobs to try to dump and reload the RDF for WDQS, but all

of these failed, or worked only partially; tried two methods:

- Tried to dump the RDF from the new wikibase container via maintenance/dumpRdf.php, which worked, but could not get it to load into Blazegraph. The load script seems to assume the munged output, but the /wdqs/munge.sh script throws a null-related error during the process when called on the RDF dump.

• Tried to import the RDF directly via the wikibase APIs using

org.wikidata.query.rdf.tool.Update in the wikidata-query-tools JAR, which seems to have partially worked, but gave lots of warnings about unrecognised statements, and requires an --idrange that is a bit awkward to use (I set it to 700, even though I had 621 items, and it seems to have created blank items up to 700 with a modification date).

On 2026-02-10 22:47, Aidan Hogan wrote:

...

Hi Deepesha, Adam, all,

[Replying to an old thread from May last year ...]

I've been very busy the past few months, so didn't have time to solve this, but I appreciate again the help! I'm also happy to say that I finally got around to updating the Wikibase version to the latest, and with some wrangling, I seem to have a clean/functional/secure/up-to-date instance of Wikibase up and running for QAWiki:

https://qawiki.org/

In case it might be of interest to others, the one complication I had was to stop "too many redirects" problems, relating to some interaction between our institution's upper-level nginx setup (which I do not have access to) and traefik, bouncing HTTP -> HTTPS redirects around. I did not manage to fully debug this as I do not have access to the upper nginx configuration, but the solution was to disable all of traefik's HTTPS configurations in docker-compose.yml (with the idea, I assume, that the upper-level nginx is taking care of that). Will copy below the configuration for posterity. After this, I managed to import the old dump fine and update it. I updated ElasticSearch manually, and was in the process of doing the same (and failing) for WDQS when I realised it had already been done automatically from the relational database (just took some time). Then some minor configurations were left, and all good.

Overall the newer version seems much easier and cleaner to manage.

Best/thanks, Aidan

---

# This is the reverse proxy and SSL service    traefik:      image: traefik:3      command:        # traefik static configuration via command line        # enable accesslog        - "--accesslog.format=common"        # http endpoint        - "--entrypoints.web.address=:80"        # https endpoint        # - "--entrypoints.websecure.address=:443"        # - "--entrypoints.websecure.asdefault"        # - "--entrypoints.websecure.http.tls.certresolver=letsencrypt"        # http to https redirect        # - "--entrypoints.web.http.redirections.entryPoint.to=websecure"        # - "--entrypoints.web.http.redirections.entryPoint.scheme=https"        # - "--entrypoints.web.http.redirections.entrypoint.permanent=true"        # ACME SSL certificate generation        # - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"        # - "-- certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"        # - "-- certificatesresolvers.letsencrypt.acme.email=${MW_ADMIN_EMAIL}"        # - "--certificatesresolvers.letsencrypt.acme.storage=/ letsencrypt/acme.json"        # additionial traefik dynamic configuration via config file        - "--providers.file.filename=/etc/traefik/dynamic.yml"        # Uncomment this line to only test ssl generation first, makes sure you don't run into letsencrypt rate limits        # - "--certificatesresolvers.letsencrypt.acme.caserver=https:// acme-staging-v02.api.letsencrypt.org/directory"        # Uncomment the following line for debugging, also expose port 8080 below        # - "--api.dashboard=true"        # - "--api.insecure=true"        # - "--log.level=DEBUG"      restart: unless-stopped      ports:        - 80:80        # - 443:443        # traefik dashboard        # - 8080:8080      volumes:        - ./config/traefik-dynamic.yml:/etc/traefik/dynamic.yml:ro        - traefik-letsencrypt-data:/letsencrypt      environment:        WIKIBASE_PUBLIC_HOST: ${WIKIBASE_PUBLIC_HOST}        WDQS_PUBLIC_HOST: ${WDQS_PUBLIC_HOST}

On 2025-05-28 05:44, Deepesha Burse wrote:

...

Hi Aidan,

Thanks a lot for raising this issue. Since you're on a version that has not been supported for over 3 years <https://www.mediawiki.org/ wiki/ Version_lifecycle>, I would suggest you to try to update to the latest deploy version. Deploy supports https out of the box and also receives updates. But I see that you're finding it hard to update to the latest version, do you mind sharing where you are getting stuck? Maybe we can find a solution for that and that fixes this issue too?

Thank you :)

Best,

On Thu, May 22, 2025 at 11:26 PM Aidan Hogan <aidhog@gmail.com mailto:aidhog@gmail.com> wrote:

Hi Adam,

Many thanks for this!

Not sure if correct, but what I understood is that $wgServer should be     defined with HTTPS (fixing the mixed content API issue), and then we     should explicitly override the baseUri for the RDF exports to ensure it     uses HTTP, not HTTPs. Along these lines, in LocalSettings.php (of the     wikibase container), I changed the following:

$wgServer = "https://qawiki.org https://qawiki.org";  // now HTTPS     $wgCanonicalServer = $wgServer;

// an old setting that doesn't doesn't seem to do anything ...     $wgWBRepoSettings['repoApiBaseUri'] = 'https://qawiki.org/w/api.php     https://qawiki.org/w/api.php';

// added ...     $wgWBRepoSettings['entitySources']['local']['baseUri'] =     "http://qawiki.org/entity/ http://qawiki.org/entity/";     $wgWBClientSettings['entitySources']['local']['baseUri'] =     "http://qawiki.org/entity/ http://qawiki.org/entity/";

$wgResourceLoaderUseHTTPS = true;     $wgSecureLogin = true;     $wgCookieSecure = true;     $wgUsePathInfo = true;

Upon restarting the container, visiting the site via the browser gives     me the error:

[c500a0c6a4c1bbba6a18104a] 2025-05-22 21:07:59: Fatal exception of type     "InvalidArgumentException"

I assume this is because the array in which I am trying to set the     values doesn't exist yet, and perhaps I need to assign     $wgWBClientSettings elsewhere, not in LocalSettings.php? Or I need to     load something via LocalSettings.php before setting these values?

Best/thanks,     Aidan

On 2025-05-22 02:57, Addshore wrote:      > Hi hi!      >      > Looking through the docs, this certainly isn't the easiest thing to      > figure out at all.      >      > This is something you can fix, if you did want to convert to     https URIs.      > But converting is your choice and everything should be able to work      > either way around.      > It looks like I wrote up changing the concept URI of a wikibase and      > query service in docker images some time ago at https://      > addshore.com/2019/11/changing-the-concept-uri-of-an-existing-     wikibase- <http://addshore.com/2019/11/changing-the-concept-uri-of-     an-existing-wikibase->      > with-data/ <https://addshore.com/2019/11/changing-the-concept-     uri-of-an- <https://addshore.com/2019/11/changing-the-concept-uri-     of-an->      > existing-wikibase-with-data/>      >      > I think (but someone that looks at the codebase more these days     would      > have to confirm)      > that you can set the concept URIs in this entity sources config      > https://doc.wikimedia.org/Wikibase/master/php/ <https://     doc.wikimedia.org/Wikibase/master/php/>      > docs_topics_entitysources.html#autotoc_md228 <https://     doc.wikimedia.org/ https://doc.wikimedia.org/      > Wikibase/master/php/docs_topics_entitysources.html#autotoc_md228>      > This would mean that you can make mediawiki be https everywhere, and      > just set the concept uris to be http      >      > By default this config comes from this place i think      > https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/     master/ <https://github.com/wikimedia/mediawiki-extensions-Wikibase/     blob/master/>      > repo/config/Wikibase.default.php#L345-L378 <https://github.com/     https://github.com/      > wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/config/      > Wikibase.default.php#L345-L378>      > And you can see the baseuri setting there too      > https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/     master/ <https://github.com/wikimedia/mediawiki-extensions-Wikibase/     blob/master/>      > repo/config/Wikibase.default.php#L369C6-L369C42 <https://     github.com/ https://github.com/      > wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/config/      > Wikibase.default.php#L369C6-L369C42>      > By default, *$wgServer . '/entity/'*      >      > So perhaps something like this might work....      >      > $wgWBRepoSettings['entitySources']['local']['baseUri'] = "<new     base uri>";      > $wgWBClientSettings['entitySources']['local']['baseUri'] = "<new     base uri>";      >      > Adam      >      > On Thu, 22 May 2025 at 04:04, Aidan Hogan <aidhog@gmail.com     mailto:aidhog@gmail.com      > <mailto:aidhog@gmail.com mailto:aidhog@gmail.com>> wrote:      >      >     Hi all,      >      >     I am running a Wikibase instance at https://qawiki.org/     https://qawiki.org/ <https://      > qawiki.org/ http://qawiki.org/> via Docker. The      >     version I am running is wikibase-bundle:1.36.3-wmde.4. (I     considered      >     updating to the latest version, but it seems daunting.) I've     recently      >     switched to HTTPS hosting, but have not managed to get the     Wikibase      >     config working fully.      >      >     I wish to keep HTTP IRIs for the RDF/SPARQL service     (otherwise the WDQS      >     updater skips all entities and/or if I force HTTPS, the query     service      >     still uses HTTP prefixes), so I set in LocalSettings.php:      >      >     $wgServer = "http://qawiki.org http://qawiki.org <http://     qawiki.org http://qawiki.org>";      >     $wgCanonicalServer = $wgServer;      >      >     To enable HTTPS elsewhere, I've tried setting:      >      >     $wgWBRepoSettings['repoApiBaseUri'] = 'https://qawiki.org/w/     api.php https://qawiki.org/w/api.php      >     <https://qawiki.org/w/api.php <https://qawiki.org/w/ api.php>>';      >     $wgSecureLogin = true;      >     $wgCookieSecure = true;      >     $wgUsePathInfo = true;      >     $wgResourceLoaderStorageVersion = 2;      >      >     Everything is mostly working okay, except some API calls are      >     directed to      >     HTTP, and fail due to mixed content. For example, visiting:      >      > https://qawiki.org/ https://qawiki.org/ <https://qawiki.org/     https://qawiki.org/>      >      >     and tying "w" in the search bar should provide autocomplete      >     suggestions,      >     but the call is heading to:      >      > http://qawiki.org/w/api.php http://qawiki.org/w/api.php?      >  action=wbsearchentities&search=What%20is%20the&format=json&errorformat=plaintext&language=en&uselang=en&type=item <http://qawiki.org/w/api.php?action=wbsearchentities&search=What%20is%20t... http://qawiki.org/w/api.php?action=wbsearchentities&search=What%20is%20the&format=json&errorformat=plaintext&language=en&uselang=en&type=item>

>      >     and is being blocked for mixed content. I don't know why it     generates a      >     HTTP URL, but I guess it relates to $wgServer.      >      >     If I set $wgServer to HTTPS, these issues disappear, but then     the WDQS      >     updater no longer works, and if I manually update with      >      >              --conceptUri https://qawiki.org/ <https://     qawiki.org/> <https://qawiki.org/ https://qawiki.org/>      >      >     the WDQS prefixes still use HTTP, and it breaks some application      >     queries.      >      >     Any help on how to "force" the front-end to call the API via     HTTPS      >     (ideally without changing $wgServer, which seems to break WDQS)      >     would be      >     appreciated!      >      >     Best,      >     Aidan      >     _______________________________________________      >     Wikibase Community User Group mailing list --      > wikibaseug@lists.wikimedia.org     mailto:wikibaseug@lists.wikimedia.org     <mailto:wikibaseug@lists.wikimedia.org     mailto:wikibaseug@lists.wikimedia.org>      >     To unsubscribe send an email to wikibaseug-     leave@lists.wikimedia.org <mailto:wikibaseug- leave@lists.wikimedia.org>      >     <mailto:wikibaseug-leave@lists.wikimedia.org     mailto:wikibaseug-leave@lists.wikimedia.org>      >      >      > _______________________________________________      > Wikibase Community User Group mailing list --     wikibaseug@lists.wikimedia.org mailto:wikibaseug@lists.wikimedia.org      > To unsubscribe send an email to wikibaseug-     leave@lists.wikimedia.org <mailto:wikibaseug- leave@lists.wikimedia.org>

_______________________________________________     Wikibase Community User Group mailing list --     wikibaseug@lists.wikimedia.org mailto:wikibaseug@lists.wikimedia.org     To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org     mailto:wikibaseug-leave@lists.wikimedia.org

-- Deepesha Burse Developer Advocate

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30-577 11 62-0 https://wikimedia.de https://wikimedia.de

Keep up to date! Current news and exciting stories about Wikimedia, Wikipedia and Free Knowledge in our newsletter (in German): Subscribe now.

Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de https://spenden.wikimedia.de Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. Geschäftsführende Vorstände: Franziska Heine.

---

Wikibase Community User Group mailing list -- wikibaseug@lists.wikimedia.org To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org

---

Wikibase Community User Group mailing list -- wikibaseug@lists.wikimedia.org To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org

Thank you Dragan! This indeed helped and worked. Unfortunately I seem to have networking issues so the query endpoint is not working at the moment, and I do not have access to the higher-level nginx to debug this at the moment. But I believe I have loaded the data correctly.

Calling SPARQL queries directly in the back-end, I have one issue. I called these methods with the argument conceptUri http://qawiki.org/ (HTTP not HTTPS). I prefer in general to keep the IRIs in RDF as HTTP as this seems to work better with the query service (e.g., the prefixes are loaded with HTTPS). Now I'm noticing that the imported data use HTTP IRIs, but the new/updated data use HTTPS IRIs.

Is there a configuration for the WDQS updater to always use HTTP IRIs?

Otherwise, I am okay with using conceptUri https://qawiki.org/, but is there a way to configure the front-end of WDQS to use HTTPS IRIs (e.g., for preloaded prefixes)?

And +1 to what Ismael mentions. It would be great to (officially) document these steps! (There are many blog posts out there with folks describing similar processes, but unfortunately they become out-of-date as new versions are released)

Best, Aidan

On 2026-02-11 23:04, Dragan Espenschied via Wikibase Community User Group wrote:

At Rhizome, we do it this way:

1. Get the full TTL dump from Wikibase:

docker compose exec php ./extensions/Wikibase/repo/maintenance/ dumpRdf.php --server https://artbase.rhizome.org --output /tmp/db-dumps/ dump.ttl

Set the output path to a directory that is mounted into the wikibase and the wdqs container, so it can be accessed by both. In this case it is / tmp/db-dumps

2. "Munge" data for import... this is doing some unknown-to-me things to

the data so the import works as intended, turned out to be important:

docker compose  exec wdqs ./munge.sh -f /tmp/db-dumps/$DATESTR.ttl -d / tmp/db-dumps/mungedOut -- --conceptUri https://artbase.rhizome.org

Set the concept URL to match your Wikibase's settings.

3. Clear Blazegraph:

docker compose exec wdqs curl "http://localhost:9999/bigdata/ namespace/wdq/sparql" --data-urlencode "update=DROP ALL;"

This sends the a command to Blazegraph to drop all data.

4. Load dump into Blazegraph:

docker compose exec wdqs ./loadData.sh -n wdq -d /tmp/db-dumps/mungedOut

Hope this helps!

Yours, Dragan

On 11.02.26 21:07, Aidan Hogan via Wikibase Community User Group wrote:

...

Hi all,

Indeed I spoke a *tad* too soon in that I think the re-indexing of RDF for WDQS in query.qawiki.org was not complete / correct, and new items are not being indexed. I cannot seem to find some up-to-date documentation on how to do this part of repopulating WDQS. Ideally, I would like the RDF to be indexed with http:// IRIs after loading in the SQL dump from a legacy instance of Wikibase. Below I'll indicate where I am in the process thus far.

What is the recommended way to rebuild and index the RDF dump in WDQS assuming the SQL database has already been populated?

Best/thanks! Aidan

---

Process thus far:

• Installed WBS Deploy 5.0.1 in Docker.

• Dumped the SQL database from the old instance, brought it down,

brought up the new deploy.

• Loaded the SQL database into the new deploy and run maintenance/

update.php (I know this is deprecated, but I could not get the new run.php script to work, and the old script seems to have done the job)

• Built the indexes/aliases for elasticsearch/cirrus and indexed the

new content (seems to be fine).

• Run various jobs to try to dump and reload the RDF for WDQS, but all

of these failed, or worked only partially; tried two methods:

- Tried to dump the RDF from the new wikibase container via maintenance/dumpRdf.php, which worked, but could not get it to load into Blazegraph. The load script seems to assume the munged output, but the /wdqs/munge.sh script throws a null-related error during the process when called on the RDF dump.

• Tried to import the RDF directly via the wikibase APIs using

org.wikidata.query.rdf.tool.Update in the wikidata-query-tools JAR, which seems to have partially worked, but gave lots of warnings about unrecognised statements, and requires an --idrange that is a bit awkward to use (I set it to 700, even though I had 621 items, and it seems to have created blank items up to 700 with a modification date).

On 2026-02-10 22:47, Aidan Hogan wrote:

...

Hi Deepesha, Adam, all,

[Replying to an old thread from May last year ...]

I've been very busy the past few months, so didn't have time to solve this, but I appreciate again the help! I'm also happy to say that I finally got around to updating the Wikibase version to the latest, and with some wrangling, I seem to have a clean/functional/secure/up- to-date instance of Wikibase up and running for QAWiki:

https://qawiki.org/

In case it might be of interest to others, the one complication I had was to stop "too many redirects" problems, relating to some interaction between our institution's upper-level nginx setup (which I do not have access to) and traefik, bouncing HTTP -> HTTPS redirects around. I did not manage to fully debug this as I do not have access to the upper nginx configuration, but the solution was to disable all of traefik's HTTPS configurations in docker-compose.yml (with the idea, I assume, that the upper-level nginx is taking care of that). Will copy below the configuration for posterity. After this, I managed to import the old dump fine and update it. I updated ElasticSearch manually, and was in the process of doing the same (and failing) for WDQS when I realised it had already been done automatically from the relational database (just took some time). Then some minor configurations were left, and all good.

Overall the newer version seems much easier and cleaner to manage.

Best/thanks, Aidan

---

# This is the reverse proxy and SSL service    traefik:      image: traefik:3      command:        # traefik static configuration via command line        # enable accesslog        - "--accesslog.format=common"        # http endpoint        - "--entrypoints.web.address=:80"        # https endpoint        # - "--entrypoints.websecure.address=:443"        # - "--entrypoints.websecure.asdefault"        # - "--entrypoints.websecure.http.tls.certresolver=letsencrypt"        # http to https redirect        # - "--entrypoints.web.http.redirections.entryPoint.to=websecure"        # - "--entrypoints.web.http.redirections.entryPoint.scheme=https"        # - "-- entrypoints.web.http.redirections.entrypoint.permanent=true"        # ACME SSL certificate generation        # - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"        # - "-- certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"        # - "-- certificatesresolvers.letsencrypt.acme.email=${MW_ADMIN_EMAIL}"        # - "--certificatesresolvers.letsencrypt.acme.storage=/ letsencrypt/acme.json"        # additionial traefik dynamic configuration via config file        - "--providers.file.filename=/etc/traefik/dynamic.yml"        # Uncomment this line to only test ssl generation first, makes sure you don't run into letsencrypt rate limits        # - "-- certificatesresolvers.letsencrypt.acme.caserver=https:// acme- staging-v02.api.letsencrypt.org/directory"        # Uncomment the following line for debugging, also expose port 8080 below        # - "--api.dashboard=true"        # - "--api.insecure=true"        # - "--log.level=DEBUG"      restart: unless-stopped      ports:        - 80:80        # - 443:443        # traefik dashboard        # - 8080:8080      volumes:        - ./config/traefik-dynamic.yml:/etc/traefik/dynamic.yml:ro        - traefik-letsencrypt-data:/letsencrypt      environment:        WIKIBASE_PUBLIC_HOST: ${WIKIBASE_PUBLIC_HOST}        WDQS_PUBLIC_HOST: ${WDQS_PUBLIC_HOST}

On 2025-05-28 05:44, Deepesha Burse wrote:

...

Hi Aidan,

Thanks a lot for raising this issue. Since you're on a version that has not been supported for over 3 years <https://www.mediawiki.org/ wiki/ Version_lifecycle>, I would suggest you to try to update to the latest deploy version. Deploy supports https out of the box and also receives updates. But I see that you're finding it hard to update to the latest version, do you mind sharing where you are getting stuck? Maybe we can find a solution for that and that fixes this issue too?

Thank you :)

Best,

On Thu, May 22, 2025 at 11:26 PM Aidan Hogan <aidhog@gmail.com mailto:aidhog@gmail.com> wrote:

Hi Adam,

Many thanks for this!

Not sure if correct, but what I understood is that $wgServer should be     defined with HTTPS (fixing the mixed content API issue), and then we     should explicitly override the baseUri for the RDF exports to ensure it     uses HTTP, not HTTPs. Along these lines, in LocalSettings.php (of the     wikibase container), I changed the following:

$wgServer = "https://qawiki.org https://qawiki.org";  // now HTTPS     $wgCanonicalServer = $wgServer;

// an old setting that doesn't doesn't seem to do anything ...     $wgWBRepoSettings['repoApiBaseUri'] = 'https://qawiki.org/w/api.php     https://qawiki.org/w/api.php';

// added ...     $wgWBRepoSettings['entitySources']['local']['baseUri'] =     "http://qawiki.org/entity/ http://qawiki.org/entity/";     $wgWBClientSettings['entitySources']['local']['baseUri'] =     "http://qawiki.org/entity/ http://qawiki.org/entity/";

$wgResourceLoaderUseHTTPS = true;     $wgSecureLogin = true;     $wgCookieSecure = true;     $wgUsePathInfo = true;

Upon restarting the container, visiting the site via the browser gives     me the error:

[c500a0c6a4c1bbba6a18104a] 2025-05-22 21:07:59: Fatal exception of type     "InvalidArgumentException"

I assume this is because the array in which I am trying to set the     values doesn't exist yet, and perhaps I need to assign     $wgWBClientSettings elsewhere, not in LocalSettings.php? Or I need to     load something via LocalSettings.php before setting these values?

Best/thanks,     Aidan

On 2025-05-22 02:57, Addshore wrote:      > Hi hi!      >      > Looking through the docs, this certainly isn't the easiest thing to      > figure out at all.      >      > This is something you can fix, if you did want to convert to     https URIs.      > But converting is your choice and everything should be able to work      > either way around.      > It looks like I wrote up changing the concept URI of a wikibase and      > query service in docker images some time ago at https://      > addshore.com/2019/11/changing-the-concept-uri-of-an-existing-     wikibase- <http://addshore.com/2019/11/changing-the-concept-uri-of-     an-existing-wikibase->      > with-data/ <https://addshore.com/2019/11/changing-the-concept-     uri-of-an- <https://addshore.com/2019/11/changing-the-concept-uri-     of-an->      > existing-wikibase-with-data/>      >      > I think (but someone that looks at the codebase more these days     would      > have to confirm)      > that you can set the concept URIs in this entity sources config      > https://doc.wikimedia.org/Wikibase/master/php/ <https://     doc.wikimedia.org/Wikibase/master/php/>      > docs_topics_entitysources.html#autotoc_md228 <https://     doc.wikimedia.org/ https://doc.wikimedia.org/      > Wikibase/master/php/ docs_topics_entitysources.html#autotoc_md228>      > This would mean that you can make mediawiki be https everywhere, and      > just set the concept uris to be http      >      > By default this config comes from this place i think      > https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/     master/ <https://github.com/wikimedia/mediawiki-extensions- Wikibase/     blob/master/>      > repo/config/Wikibase.default.php#L345-L378 <https://github.com/     https://github.com/      > wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/config/      > Wikibase.default.php#L345-L378>      > And you can see the baseuri setting there too      > https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/     master/ <https://github.com/wikimedia/mediawiki-extensions- Wikibase/     blob/master/>      > repo/config/Wikibase.default.php#L369C6-L369C42 <https://     github.com/ https://github.com/      > wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/config/      > Wikibase.default.php#L369C6-L369C42>      > By default, *$wgServer . '/entity/'*      >      > So perhaps something like this might work....      >      > $wgWBRepoSettings['entitySources']['local']['baseUri'] = "<new     base uri>";      > $wgWBClientSettings['entitySources']['local']['baseUri'] = "<new     base uri>";      >      > Adam      >      > On Thu, 22 May 2025 at 04:04, Aidan Hogan <aidhog@gmail.com     mailto:aidhog@gmail.com      > <mailto:aidhog@gmail.com mailto:aidhog@gmail.com>> wrote:      >      >     Hi all,      >      >     I am running a Wikibase instance at https://qawiki.org/     https://qawiki.org/ <https://      > qawiki.org/ http://qawiki.org/> via Docker. The      >     version I am running is wikibase-bundle:1.36.3-wmde.4. (I     considered      >     updating to the latest version, but it seems daunting.) I've     recently      >     switched to HTTPS hosting, but have not managed to get the     Wikibase      >     config working fully.      >      >     I wish to keep HTTP IRIs for the RDF/SPARQL service     (otherwise the WDQS      >     updater skips all entities and/or if I force HTTPS, the query     service      >     still uses HTTP prefixes), so I set in LocalSettings.php:      >      >     $wgServer = "http://qawiki.org http://qawiki.org <http://     qawiki.org http://qawiki.org>";      >     $wgCanonicalServer = $wgServer;      >      >     To enable HTTPS elsewhere, I've tried setting:      >      >     $wgWBRepoSettings['repoApiBaseUri'] = 'https://qawiki.org/w/     api.php https://qawiki.org/w/api.php      >     <https://qawiki.org/w/api.php <https://qawiki.org/w/ api.php>>';      >     $wgSecureLogin = true;      >     $wgCookieSecure = true;      >     $wgUsePathInfo = true;      >     $wgResourceLoaderStorageVersion = 2;      >      >     Everything is mostly working okay, except some API calls are      >     directed to      >     HTTP, and fail due to mixed content. For example, visiting:      >      > https://qawiki.org/ https://qawiki.org/ <https://qawiki.org/     https://qawiki.org/>      >      >     and tying "w" in the search bar should provide autocomplete      >     suggestions,      >     but the call is heading to:      >      > http://qawiki.org/w/api.php http://qawiki.org/w/api.php?      >  action=wbsearchentities&search=What%20is%20the&format=json&errorformat=plaintext&language=en&uselang=en&type=item <http://qawiki.org/w/api.php?action=wbsearchentities&search=What%20is%20t... http://qawiki.org/w/api.php?action=wbsearchentities&search=What%20is%20the&format=json&errorformat=plaintext&language=en&uselang=en&type=item>      >      >     and is being blocked for mixed content. I don't know why it     generates a      >     HTTP URL, but I guess it relates to $wgServer.      >      >     If I set $wgServer to HTTPS, these issues disappear, but then     the WDQS      >     updater no longer works, and if I manually update with      >      >              --conceptUri https://qawiki.org/ <https://     qawiki.org/> <https://qawiki.org/ https://qawiki.org/>      >      >     the WDQS prefixes still use HTTP, and it breaks some application      >     queries.      >      >     Any help on how to "force" the front-end to call the API via     HTTPS      >     (ideally without changing $wgServer, which seems to break WDQS)      >     would be      >     appreciated!      >      >     Best,      >     Aidan      >     _______________________________________________      >     Wikibase Community User Group mailing list --      > wikibaseug@lists.wikimedia.org     mailto:wikibaseug@lists.wikimedia.org     <mailto:wikibaseug@lists.wikimedia.org     mailto:wikibaseug@lists.wikimedia.org>      >     To unsubscribe send an email to wikibaseug-     leave@lists.wikimedia.org <mailto:wikibaseug- leave@lists.wikimedia.org>      >     <mailto:wikibaseug-leave@lists.wikimedia.org     mailto:wikibaseug-leave@lists.wikimedia.org>      >      >      > _______________________________________________      > Wikibase Community User Group mailing list --     wikibaseug@lists.wikimedia.org mailto:wikibaseug@lists.wikimedia.org      > To unsubscribe send an email to wikibaseug-     leave@lists.wikimedia.org <mailto:wikibaseug- leave@lists.wikimedia.org>

_______________________________________________     Wikibase Community User Group mailing list --     wikibaseug@lists.wikimedia.org mailto:wikibaseug@lists.wikimedia.org     To unsubscribe send an email to wikibaseug- leave@lists.wikimedia.org     mailto:wikibaseug-leave@lists.wikimedia.org

-- Deepesha Burse Developer Advocate

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30-577 11 62-0 https://wikimedia.de https://wikimedia.de

Keep up to date! Current news and exciting stories about Wikimedia, Wikipedia and Free Knowledge in our newsletter (in German): Subscribe now.

Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de https://spenden.wikimedia.de Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. Geschäftsführende Vorstände: Franziska Heine.

---

Wikibase Community User Group mailing list -- wikibaseug@lists.wikimedia.org To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org

---

Wikibase Community User Group mailing list -- wikibaseug@lists.wikimedia.org To unsubscribe send an email to wikibaseug-leave@lists.wikimedia.org