[Wikidata-bugs] [Maniphest] T287231: Consider moving WDQS "munging" of RDF into Wikibase RDF output code
despens added a comment. I would like to understand the reasons why there are two versions of Wikibase RDF, one that is for example returned by requesting it for an item such as https://artbase.rhizome.org/wiki/Special:EntityData/Q2585.ttl and one that is first munged and then handed over into the triple store. Given the architecture of WIkibase, the RDF solely exists to enable SPARQL querying and federation, it is not the actual source of truth or canonical storage format, but a derivative of the JSON blobs stored in MySQL. How would already exporting the desired RDF format increase coupling, rather than removing an unnecessary step? TASK DETAIL https://phabricator.wikimedia.org/T287231 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Tarrow, RhinosF1, Aklapper, Addshore, Invadibot, MPhamWMF, maantietaja, CBogen, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T290311: Move loading of Vector skin into LocalSettings.d snippet
despens added a comment. I'm ready to do it 🚜 TASK DETAIL https://phabricator.wikimedia.org/T290311 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Addshore, despens, Aklapper, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T90492: [Task] Make Wikibase Repo work with a custom File collection, not only Wikimedia Commons
despens closed this task as "Resolved". despens claimed this task. despens added a comment. Rhizome commissioned the LocalMedia extension <https://github.com/ProfessionalWiki/WikibaseLocalMedia> with Professional.Wiki, which provides this features. The extension has also become part of the official Wikibase Docker distribution <https://github.com/wmde/wikibase-release-pipeline>. TASK DETAIL https://phabricator.wikimedia.org/T90492 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Hispano76, Danmichaelo, Loz.ross, Bcbussche, lucamauri, jmac, Yurik, Addshore, Abit, ToBeFree, Jakob_WMDE, Tarrow, LJ, Daniel_Mietchen, despens, RazShuty, PokestarFan, Lokal_Profil, Reedy, Steinsplitter, Snaterlicious, adrianheine, Ricordisamoa, gerritbot, daniel, Aklapper, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T267129: Purtle issue truncating TTL export
despens added a comment. ⛱ re-sent invite 🏖 TASK DETAIL https://phabricator.wikimedia.org/T267129 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Lucas_Werkmeister_WMDE, Addshore, Aklapper, despens, Invadibot, maantietaja, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T234943: bootstrap Wikibase installation with basic ontology
despens added a comment. > formatter URI for RDF resource exists… I think this is exactly what I mean 😉: it looks like when it comes to creating RDF data that some "data types" or "input constraints" are defined via magic properties, others have proper data types (such as date/time, string, item, etc). This has consequences for configuration (everyone needs to set up magic properties to get functionality that looks like a data type), and rendering (data types have rendering functions that for instance produce an image or link on a wikipage, how does this work with magic properties-related data?). Regarding the formatter URL, separate URLs for the data editing user interface and RDF export don't seem to make sense without considering the whole history of Wikidata's community which is not necessarily shared by federated instances. The federated Wikibase instances present a chance to rethink the role of magic properties, which I believe are posing a barrier to using Wikibase. Is there list of all magic properties on Wikidata available? TASK DETAIL https://phabricator.wikimedia.org/T234943 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Samantha_Alipio_WMDE, Pintoch, Bugreporter, Addshore, Lucas_Werkmeister_WMDE, Aklapper, Lydia_Pintscher, Invadibot, maantietaja, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T197673: Include LUA / Scribuntu
despens changed the task status from "Duplicate" to "Resolved". despens added a comment. Current Docker distribution has Scribuntu included: https://github.com/wmde/wikibase-release-pipeline/tree/main/Docker/build/WikibaseBundle TASK DETAIL https://phabricator.wikimedia.org/T197673 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Aklapper, despens, Invadibot, maantietaja, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Addshore, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T264009: Addings Sitelinks should consistently call APIs via the backend/PHP, not Javascript
despens added a comment. VisualEditor is now part of the Docker distribution: https://github.com/wmde/wikibase-release-pipeline/tree/main/Docker/build/WikibaseBundle 🎉 TASK DETAIL https://phabricator.wikimedia.org/T264009 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Addshore, Samantha_Alipio_WMDE, despens, Aklapper, Invadibot, maantietaja, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T234943: bootstrap Wikibase installation with basic ontology
despens added a comment. I think it would be meaningful to review the role of "magic properties" for independent Wikibase deployments. For instance, using them for asynchronous format validation via bots (like the constraints) is probably useful for the scale Wikidata, on smaller instances you'd rather want to use Shape Expressions in real time during data input. Formatter URLs are fine if your main way of using Wikibase data is browsing the Wikibase editing interface (having clickable links there is nice), but how they are represented in RDF and therefore the query service remains undefined. So while magic properties have a clear benefit in Wikidata, and the community can develop specific tools on top of them, extending this practice to distributed Wikibases seems not ideal, and I would be hesitant to promote their usage or creating more tools that rely on bots reading them. For instance w/r/t the formatter URLs, it would make more sense to create a data type such as "prefixed URL" that then provides simplified editing methods. TASK DETAIL https://phabricator.wikimedia.org/T234943 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Samantha_Alipio_WMDE, Pintoch, Bugreporter, Addshore, Lucas_Werkmeister_WMDE, Aklapper, Lydia_Pintscher, Invadibot, maantietaja, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T254360: The variable $wgServer server is missing in the LocalSettings.php template in the docker wikibase
despens added a comment. Latest version has it: https://github.com/wmde/wikibase-release-pipeline/blob/816b8084b7068fa1a49bbcf9e57676bd4092e151/Docker/build/Wikibase/LocalSettings.php.template#L28 TASK DETAIL https://phabricator.wikimedia.org/T254360 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, despens Cc: despens, Addshore, Aklapper, LordCyfer, Invadibot, maantietaja, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T205028: Allow the user to change the Blazegraph prefixes in the Wikibase Docker distribution
despens added a comment. I suggest using a text file that is parsed and added to both the blazegraph `prefices.conf` file, and baked into the query service GUI, format could be basic: prefix rprv: <$baseurl/prop/reference/value/> ... `$baseurl` could be taken from a global config. TASK DETAIL https://phabricator.wikimedia.org/T205028 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, DD063520, Addshore, Aklapper, thisismattmiller, Invadibot, Saarik, MPhamWMF, Johentsch, maantietaja, CBogen, Samantha_Alipio_WMDE, Akuckartz, Nandana, Namenlos314, LJ, lucamauri, Lahi, Gq86, SandraF_WMF, Andrawaag, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, YULdigitalpreservation, merbst, LawExplorer, _jensen, rosalieper, Jneubert, Scott_WUaS, Jonas, Xmlizer, Myst, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, GreenReaper, Daniel_Mietchen, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T245542: Make rdfDump.php export in WDQS-ready format
despens added a comment. To specify: the process of getting triples exported from Wikibase into Blazegraph is not great, a bunch of shell script wrappers around some Java application, neither being documented very well. It leads to weird side effects, such as requiring to use the `/wiki/` path on the Mediawiki that holds the Wikibase T274354 <https://phabricator.wikimedia.org/T274354>. The bigger story is to make the process to sync triples with Blazegraph more robust and controllable, ideally not requiring a separate container. Probably the Wikidata setup, which has to deal with an amount of edits that self-deployed Wikibases usually don't see, has different requirements. TASK DETAIL https://phabricator.wikimedia.org/T245542 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Nikerabbit, Harej, despens, Aklapper, Invadibot, MPhamWMF, maantietaja, CBogen, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Addshore, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T196042: Configurable RDF prefixes for WDQS
despens added a comment. This commit on GitHub lists patches to the WDQS query GUI to achieve custom name spaces: https://github.com/rhizomedotorg/artbase-query-gui/commit/29ce17b225a3fb9d9bcd16896778f94495fdf9c9 TASK DETAIL https://phabricator.wikimedia.org/T196042 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Seb35, tk, Aklapper, Smalyshev, Addshore, Tarrow, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T209349: Importing the SPARQL2 template into a Wikibase instance from Wikidata
despens added a comment. Scribuntu is part of the Wikibase Docker distribution, and is activated via a configuration snippet: https://github.com/wmde/wikibase-release-pipeline/blob/main/Docker/build/WikibaseBundle/LocalSettings.d.template/Scribunto.php TASK DETAIL https://phabricator.wikimedia.org/T209349 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Aklapper, Tarrow, Addshore, Andrawaag, Invadibot, maantietaja, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T267129: Purtle issue truncating TTL export
despens edited projects, added Wikibase-Docker-2017+; removed MediaWiki-extensions-WikibaseRepository, Wikibase (3rd party installations), wdwb-tech. despens added a comment. Restricted Application added a project: wdwb-tech. I am unfortunately not savvy enough to provide a stack trace, but have the (amateurish) patch that solves the issue for Rhizome available on GitHub: https://github.com/rhizomedotorg/wikibase-docker/commit/d810a86021490b2a9aa99f476251fd4ac754bcb9 (both @Lucas_Werkmeister_WMDE and @Addshore are invited to the repo) TASK DETAIL https://phabricator.wikimedia.org/T267129 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Lucas_Werkmeister_WMDE, Addshore, Aklapper, despens, Invadibot, maantietaja, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331, darthmon_wmde, lucamauri, Lydia_Pintscher ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T277027: dispatchChanges.php does not work with the Wikibase Docker distribution
despens added a comment. For dispatchChanges.php to work on a Wikibase install, the following conditions have to be met: 1. The local wiki has to be registered in the "sites" table. This can be done by running addSite <https://www.mediawiki.org/wiki/Manual:AddSite.php>, for instance: $ docker exec -ti wikibase php ./maintenance/addSite.php \ --language en \ --filepath 'https://artbase.rhizome.org/w/$1' \ --pagepath 'https://artbase.rhizome.org/wiki/$1' \ --server https://artbase.rhizome.org \ --interwiki-id artbase \ artbase Rhizome Now it should be possible to add local sitelinks within your own wiki. 2. Perhaps during some unlucky previous experiments, the connection to the local wiki is registered wrongly, which might then introduce big delays into dispatching. Truncate the table wb_changes_dispatch in your database for good measure: MySQL [wiki]> truncate wb_changes_dispatch; 3. several scripts have to be run in cronjobs, here is how this looks for us: $ crontab -l # m h dom mon dow command * * * * * docker exec -u www-data wikibase php maintenance/runJobs.php * * * * * docker exec -u www-data wikibase php extensions/Wikibase/repo/maintenance/dispatchChanges.php 3 3 8 * * docker exec -u www-data wikibase php extensions/Wikibase/repo/maintenance/pruneChanges.php TASK DETAIL https://phabricator.wikimedia.org/T277027 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Addshore, despens, Aklapper, Invadibot, maantietaja, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T277027: dispatchChanges.php does not work with the Wikibase Docker distribution
despens added a comment. After adding the LocalSettings changed proposed above (`$wgWBClientSettings['repoDatabase'] = false;`), changes are getting dispatched, but very irregularly. The `dispatchChanges.php` script in most cases is unable to get a "database lock": ubuntu@wikibase:~/wikibase$ docker exec -u www-data artbase-wikibase php extensions/Wikibase/repo/maintenance/dispatchChanges.php --max-time=60 10:49:33 Starting loop for unlimited passes or 60 seconds 10:49:33 Posted 1 changes to wiki, up to ID 136916, timestamp 20210527104904. Lag is 29 seconds. Next ID is 136916. 10:49:33 Posted 1 changes to artbase, up to ID 136916, timestamp 20210527104904. Lag is 29 seconds. Next ID is 136916. 10:49:33 Wikibase\Repo\Store\Sql\SqlChangeDispatchCoordinator::selectClient: Could not lock any of the candidate client wikis for dispatching 10:49:43 Wikibase\Repo\Store\Sql\SqlChangeDispatchCoordinator::selectClient: Could not lock any of the candidate client wikis for dispatching 10:49:53 Wikibase\Repo\Store\Sql\SqlChangeDispatchCoordinator::selectClient: Could not lock any of the candidate client wikis for dispatching 10:50:03 Wikibase\Repo\Store\Sql\SqlChangeDispatchCoordinator::selectClient: Could not lock any of the candidate client wikis for dispatching 10:50:13 Wikibase\Repo\Store\Sql\SqlChangeDispatchCoordinator::selectClient: Could not lock any of the candidate client wikis for dispatching 10:50:24 Wikibase\Repo\Store\Sql\SqlChangeDispatchCoordinator::selectClient: Could not lock any of the candidate client wikis for dispatching 10:50:34 Done, exiting after 10 passes and 60.152252912521 seconds. Also it looks like changes are dispatched to 'wiki', which I do not know the origins of, nor am aware of having it set up anywhere. In general it works, but laggy, and creating big log files. :) TASK DETAIL https://phabricator.wikimedia.org/T277027 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Addshore, despens, Aklapper, Invadibot, maantietaja, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T272357: [Story] Allow wikibases to not populate the wb_changes table if it is not going to be used
despens added a comment. I'm not quite understanding what this is supposed to be fixing. Would changes in Wikibase Items trigger a cache purge of local sitelink'ed pages, without having to set up the whole notification system? TASK DETAIL https://phabricator.wikimedia.org/T272357 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Samantha_Alipio_WMDE, LucasWerkmeister, Aklapper, Addshore, Invadibot, maantietaja, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Asahiko, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T205028: Allow the user to change the Blazegraph prefixes in the Wikibase Docker distribution
despens added a comment. I would rather recommend adding desired prefixes to `prefixes.conf`. Editing `ldf-config.json` didn't do anything for me. TASK DETAIL https://phabricator.wikimedia.org/T205028 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, DD063520, Addshore, Aklapper, thisismattmiller, Invadibot, Saarik, MPhamWMF, Johentsch, maantietaja, CBogen, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Namenlos314, LJ, lucamauri, Lahi, Gq86, SandraF_WMF, Andrawaag, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, YULdigitalpreservation, merbst, LawExplorer, _jensen, rosalieper, Jneubert, Scott_WUaS, Jonas, Xmlizer, Asahiko, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Daniel_Mietchen, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T274354: rdf munger and hence wdqs-updater requires siteLinks to be formed using a specific articlePath
despens added a comment. - The URL was indeed `https://artbase.rhizome.org/entity/null` with a `null` - I am unable to reproduce the log at the moment. This only can be done on the production machine (site links do not work on a localhost-based docker deployment, T268231 <https://phabricator.wikimedia.org/T268231>, T264009 <https://phabricator.wikimedia.org/T264009>) and the project deadline is too close right now. 😅 TASK DETAIL https://phabricator.wikimedia.org/T274354 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: dcausse, Addshore, despens, Aklapper, MPhamWMF, maantietaja, CBogen, Akuckartz, darthmon_wmde, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, abian, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T263427: Unable to process a particular wikibase dump using munge.sh (localised namespace name)
despens added a comment. It would be cool if the munger's validation behaviour would be configurable, which could maybe remedy some weird behavior overall, see T274354 <https://phabricator.wikimedia.org/T274354> TASK DETAIL https://phabricator.wikimedia.org/T263427 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Addshore, Andrawaag, JeroenDeDauw, WMDE-leszek, dcausse, Aklapper, Nikerabbit, MPhamWMF, maantietaja, CBogen, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, Asahiko, abian, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Nemo_bis, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T265198: Don’t require extra cronjobs / maintenance scripts for Wikibase
despens added a comment. In T265198#6883296 <https://phabricator.wikimedia.org/T265198#6883296>, @Addshore wrote: > This error could do with it's own phabricator ticket. → T277027 <https://phabricator.wikimedia.org/T277027> TASK DETAIL https://phabricator.wikimedia.org/T265198 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Addshore, Aklapper, LucasWerkmeister, maantietaja, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, abian, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T277027: dispatchChanges.php does not work with the Wikibase Docker distribution
despens created this task.
despens added a project: Wikibase-Containers.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
With the Wikibase Docker distribution, `dispatchChanges.php` doesn't seem to
work:
$ docker exec artbase-wikibase php
extensions/Wikibase/repo/maintenance/dispatchChanges.php
OutOfBoundsException from line 60 of
/var/www/html/extensions/Wikibase/lib/includes/SettingsArray.php: Attempt to
get non-existing setting "repoDatabase"
#0
/var/www/html/extensions/Wikibase/repo/maintenance/dispatchChanges.php(93):
Wikibase\Lib\SettingsArray->getSetting('repoDatabase')
#1
/var/www/html/extensions/Wikibase/repo/maintenance/dispatchChanges.php(247):
Wikibase\Repo\Maintenance\DispatchChanges->getClientWikis(Array)
#2 /var/www/html/maintenance/doMaintenance.php(107):
Wikibase\Repo\Maintenance\DispatchChanges->execute()
#3
/var/www/html/extensions/Wikibase/repo/maintenance/dispatchChanges.php(403):
require_once('/var/www/html/m...')
#4 {main}
What is `repoDatabase`, and what value should it contain?
TASK DETAIL
https://phabricator.wikimedia.org/T277027
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: despens
Cc: despens, Aklapper, maantietaja, Samantha_Alipio_WMDE, Akuckartz, Jelabra,
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen,
rosalieper, Scott_WUaS, Asahiko, abian, Wikidata-bugs, aude, Addshore, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T265198: Don’t require extra cronjobs / maintenance scripts for Wikibase
despens added a comment.
Restricted Application added a project: wdwb-tech-focus.
With the Wikibase Docker distribution, `dispatchChanges.php` doesn't seem to
work:
$ docker exec artbase-wikibase php
extensions/Wikibase/repo/maintenance/dispatchChanges.php
OutOfBoundsException from line 60 of
/var/www/html/extensions/Wikibase/lib/includes/SettingsArray.php: Attempt to
get non-existing setting "repoDatabase"
#0
/var/www/html/extensions/Wikibase/repo/maintenance/dispatchChanges.php(93):
Wikibase\Lib\SettingsArray->getSetting('repoDatabase')
#1
/var/www/html/extensions/Wikibase/repo/maintenance/dispatchChanges.php(247):
Wikibase\Repo\Maintenance\DispatchChanges->getClientWikis(Array)
#2 /var/www/html/maintenance/doMaintenance.php(107):
Wikibase\Repo\Maintenance\DispatchChanges->execute()
#3
/var/www/html/extensions/Wikibase/repo/maintenance/dispatchChanges.php(403):
require_once('/var/www/html/m...')
#4 {main}
What is `repoDatabase`?
TASK DETAIL
https://phabricator.wikimedia.org/T265198
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: despens
Cc: despens, Addshore, Aklapper, LucasWerkmeister, Samantha_Alipio_WMDE,
Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden,
LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude,
Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T274354: rdf munger and hence wdqs-updater requires siteLinks to be formed using a specific articlePath
despens updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T274354 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Aklapper, Samantha_Alipio_WMDE, Akuckartz, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T274354: rdf munger and hence wdqs-updater requires siteLinks to be formed using a specific articlePath
despens created this task. despens added projects: Wikibase, Wikibase-Containers. Restricted Application added a subscriber: Aklapper. Restricted Application added projects: Wikidata, wdwb-tech-focus. TASK DESCRIPTION When using a non-standard $wgArticlePath (that is, not `/wiki/$1`), the automatic process of feeding Wikibase data into the query service will stop working. The error message when running munge: 0:16:33.843 [main] INFO o.wikidata.query.rdf.tool.rdf.Munger - Unrecognized subjects: [ then follow thousands of statements, all in the form https://artbase.rhizome.org/entity/statement/Q4198-xx -- then the end of the error: ] while processing https://artbase.rhizome.org/entity/null. Expected only sitelinks and subjects starting with https://artbase.rhizome.org/wiki/Special:EntityData/ and [https://artbase.rhizome.org/entity/] This is for a wiki that is set up with the $wgArticlePath `/$1`, according information in the `sites` table, and a correctly changed .htaccess for Apache to handle the URL routes. When changing the $wgArticlePath back to the default `/wiki/$1`, (including switching back information in the `sites` table and reversing to detault .htaccess) the Munger <https://github.com/wikimedia/wikidata-query-rdf/blob/master/tools/src/main/java/org/wikidata/query/rdf/tool/rdf/Munger.java> process completes without any issues. I am unclear why the Munger would verify siteLinks in the first place (or do any data validation), but if it needs to do that it should check for linked wiki's articlePath, which can be found out using the Mediawiki API <https://artbase.rhizome.org/w/api.php?action=query&meta=siteinfo&siprop=general>. My suggestion would be to use the existing command line switch `--skipSiteLinks` to at least not check for the formatting of siteLinks when they're not going to be exported to the query service. Preferred would be another switch that would accept any type of siteLink. TASK DETAIL https://phabricator.wikimedia.org/T274354 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Aklapper, Samantha_Alipio_WMDE, Akuckartz, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T270891: wikibase-docker no longer works with MediaWiki 1.34
despens added a comment. Thx! Also see T271747 <https://phabricator.wikimedia.org/T271747> TASK DETAIL https://phabricator.wikimedia.org/T270891 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Addshore, Samantha_Alipio_WMDE, Aklapper, Danmichaelo, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Luke081515, Asahiko, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T271747: Update docker compose to use Wikibase version 1.35
despens created this task. despens added a project: Wikibase-Containers. Restricted Application added a subscriber: Aklapper. Restricted Application added a project: Wikidata. TASK DESCRIPTION https://github.com/wmde/wikibase-docker/blob/master/docker-compose.yml#L16 Since version 1.34 is EOL, the docker-compose.yml should be updated to 1.35. TASK DETAIL https://phabricator.wikimedia.org/T271747 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Aklapper, despens, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T270891: wikibase-docker no longer works with MediaWiki 1.34
despens added a comment. How long will extensions for 1.35 be supported? TASK DETAIL https://phabricator.wikimedia.org/T270891 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Addshore, Samantha_Alipio_WMDE, Aklapper, Danmichaelo, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Luke081515, Asahiko, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T268231: wdqs-updater configuration and data validation issues
despens renamed this task from "wdqs-updater stops working once SiteLinks are used" to "wdqs-updater configuration and data validation issues". TASK DETAIL https://phabricator.wikimedia.org/T268231 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Addshore, Aklapper, despens, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T268231: wdqs-updater stops working once SiteLinks are used
despens added a comment. I was able to fix the local issue by adding `WIKIBASE_SCHEME=https` to wdqs-updater environment. The issues remain: - two variables (instead of one) define a URL that is used for both API access and data validation. This makes a setup not portable and greatly hinders local testing. - data should not be validated in the updater (I guess structural RDF validation happens, that cannot cause harm) I guess this task has to be renamed 😉 TASK DETAIL https://phabricator.wikimedia.org/T268231 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Addshore, Aklapper, despens, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T268231: wdqs-updater stops working once SiteLinks are used
despens added a comment. When chaning `WIKIBASE_HOST` to `artbase.rhizome.org`, SiteLinks are still rejected, probably because the protocol is `https` instead of `https`: artbase-query-updater | 14:18:50.580 [update 2] INFO o.wikidata.query.rdf.tool.rdf.Munger - Unrecognized subjects: [https://artbase.rhizome.org/entity/statement/Q1996-E4FAB500-453A-4896-B3BC-ED840ADB5DB0, https://artbase.rhizome.org/entity/statement/Q1996-cf52a70e-496a-b8f6-8ee8-979b9230ff42, https://artbase.rhizome.org/entity/statement/Q1996-3883cd45-4abd-52cc-fd01-40d9b1676948, https://artbase.rhizome.org/entity/statement/Q1996-40b62fbb-491d-9387-a353-9a960aa6f1ea, https://artbase.rhizome.org/entity/Q1996, https://artbase.rhizome.org/entity/statement/Q1996-76ee588f-404f-82ae-1514-bc11e61327bf, https://artbase.rhizome.org/entity/statement/Q1996-b270ab2e-424a-8e2e-1f69-d0946c26b429, https://artbase.rhizome.org/entity/statement/Q1996-07e62af6-4c07-7905-4d2a-df74c0da, https://artbase.rhizome.org/value/d49b98a030ea836c922381a07d3a55a5] while processing http://artbase.rhizome.org/entity/Q1996. Expected only sitelinks and subjects starting with http://artbase.rhizome.org/wiki/Special:EntityData/ and [http://artbase.rhizome.org/entity/] In general it seems weird that wdqs-updater is doing its own validation of data it is supposed to shove into wdqs: if there is any issue with any kind of data, it must be flagged on creation in Wikibase. TASK DETAIL https://phabricator.wikimedia.org/T268231 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Addshore, Aklapper, despens, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T268231: wdqs-updater stops working once SiteLinks are used
despens created this task. despens added a project: Wikibase-Containers. Restricted Application added a subscriber: Aklapper. Restricted Application added a project: Wikidata. TASK DESCRIPTION Once a public docker setup of Wikibase is using SiteLinks to connect local items with local wikipages, the updating process that feeds changes to the query service will stop working, complaining about not being able to update any item that contains site links. Example error message: artbase-query-updater | org.wikidata.query.rdf.tool.rdf.Munger$BadSubjectException: Unrecognized subjects: [https://artbase.rhizome.org/entity/Q551, https://artbase.rhizome.org/entity/statement/Q551-FAEED5FD-26DC-4722-8C8A-5783FF55A0BD, https://artbase.rhizome.org/entity/statement/Q551-A66E3A8D-A2B1-49E4-80A0-E69590DC93B4, https://artbase.rhizome.org/entity/statement/Q551-92C4242A-16E1-4EB9-A8A7-7C766A763CF6, https://artbase.rhizome.org/entity/statement/Q551-C8CF6FB7-1DA3-4583-A01F-65EFA3E43C6C, https://artbase.rhizome.org/entity/statement/Q551-854800D6-FFB6-4A7B-BD1F-233226A1AF21, https://artbase.rhizome.org/entity/statement/Q551-48719F5B-28F4-44E6-9708-25C60F1BDBE6, https://artbase.rhizome.org/entity/statement/Q551-19EA4083-8A96-4ACA-9938-68FABF2D5741, https://artbase.rhizome.org/entity/statement/Q551-3EA1AA0C-FBC3-43DF-A574-A2F04F3D34D0]. Expected only sitelinks and subjects starting with http://wikibase.svc/wiki/Special:EntityData/ and [http://wikibase.svc/entity/] Of course this has all kinds of side effects on the whole setup, basically the SPARQL endpoint is not reflecting the contents of the local Wikibase. In the default `docker-compose.yaml`, `WIKIBASE_HOST` is set to `wikibase.svc`. AFAIK it is not documented where exactly this variable is used. Anyway, in no case `wikibase.svc` would be a meaningful SiteLink host, since this DNS name is only accessible from within the docker network. Relevant excerpt from default `docker-compose.yaml`: wdqs-updater: image: wikibase/wdqs:0.3.10 restart: unless-stopped command: /runUpdate.sh depends_on: - wdqs - wikibase networks: default: aliases: - wdqs-updater.svc environment: - WIKIBASE_HOST=wikibase.svc - WDQS_HOST=wdqs.svc - WDQS_PORT= This appears connected to T264009 <https://phabricator.wikimedia.org/T264009>, in which the main issue is the use of a URL variable for very different purposes, under the assumption that all URLs must be globally accessible. TASK DETAIL https://phabricator.wikimedia.org/T268231 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Aklapper, despens, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T267129: Purtle issue truncating TTL export
despens added a comment. It is not entierly clear why the error happens. A hint might be that the last item that was correctly processed was followed by a gap in the item list. `Q7246` is fine, `Q7247` for some reason does not exist (it was _not_ deleted, it just never was created), then the row continues with `Q7248`. I have locally changed the script so if `$local` is found to be an instance of Closure, the output will be skipped. We have to use the TTL export to initialize our Wikibase's SPARQL query endpoint. TASK DETAIL https://phabricator.wikimedia.org/T267129 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Aklapper, despens, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T267129: Purtle issue truncating TTL export
despens created this task.
despens added a project: Wikibase-Containers.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
When running `php ./extensions/Wikibase/repo/maintenance/dumpRdf.php --server
https://artbase.rhizome.org`, the RDF dumper exits with the following error
message:
Recoverable fatal error: Object of class Closure could not be converted to
string in /var/www/html/vendor/wikimedia/purtle/src/TurtleRdfWriter.php on line
88
Inside `TurtleRdfWriter.php`, the line `$this->write( "$base:$local" );`
causes the issue: apparently `$local` is a Closure that can not be converted to
a string.
When the error happens, `var_dump` for `$base` returns `string(3) "owl"`, and
for `$local` returns `object(Closure)#335 (0) {}`.
In my TTL export, this happened about half-way through the export, the rest
of the data was not exported.
TASK DETAIL
https://phabricator.wikimedia.org/T267129
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: despens
Cc: Aklapper, despens, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi,
Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS,
Asahiko, Wikidata-bugs, aude, Addshore, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T197660: Accept arbitrary lines to be appended to deployed LocalSettings.php
despens added a comment. Reformulated more specifically here: T264007 <https://phabricator.wikimedia.org/T264007> Regarding config options that were customized by Rhizome: - We had to activate Scribuntu: it comes with the Mediawiki docker image, but is not loaded from the LocalSettings.php that comes with Wikibase image - Setting a logo image - We're just using more extensions than installed by default in the Wikibase image — at the moment I do not see how that could be made easier for the types of extensions we use - Some tweaks regarding name spaces and page titles that — not easily abstracted Overall, our main concern is that after an update we can use the default LocalSettings.php because we assume that will provide the basic functionality we want to build upon. TASK DETAIL https://phabricator.wikimedia.org/T197660 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Aklapper, Tarrow, Addshore, despens, Samantha_Alipio_WMDE, Akuckartz, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T264007: Implement modular LocalSettings.php configuration in wikibase-containers
despens added a comment. Also see T246952 <https://phabricator.wikimedia.org/T246952> TASK DETAIL https://phabricator.wikimedia.org/T264007 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, despens Cc: despens, Aklapper, Samantha_Alipio_WMDE, Akuckartz, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T264009: Addings Sitelinks should consistently call APIs via the backend/PHP, not Javascript
despens created this task. despens added a project: Wikibase-Containers. Restricted Application added a subscriber: Aklapper. Restricted Application added projects: Wikidata, User-Addshore. TASK DESCRIPTION The `sites` database table in Mediawiki lists public URLs for remote Wikis. When adding SiteLinks in between wikipages and Wikibase items, front-end code (Javascript, running in the same network as the browser) and back-end code (PHP, running in the network of the server) use the same URLs to query wiki APIs of (possibly) remote wikis. In the docker distribution, it is impossible to make a docker-setup with SiteLinks that can be moved in between production and a local testing setup: there is no way to enter URLs in the sites table that would be accessible from "inside" and "outside" the container and consistently pointing to the whatever the desired version of a private Wikibase is. Effectively that means that a local testing version needs a different `sites` table than the publicly deployed version, which makes database dumps and in general Wikibase setups non-portable by design. For instance, even if I set up an alias for the Wikibase container that is the same as the public name for my Wikibase, the back-end will talk to the local version and the front-end to the deployed version. The docker-internal one runs with http, the deployed version runs with https. If I use localhost, a local IP, or internal docker network IP, the public deployment obviously won't work. It would be easier to manage this if the front-end wouldn't send out requests to (possible) remote wiki APIs, but only query its local back-end, which then could handle talking to remote hosts if required. A "remote" wiki could be set up as localhost from the perspective of the server, and be consistently reachable in both a test setup or a production deployment. TASK DETAIL https://phabricator.wikimedia.org/T264009 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, despens Cc: despens, Aklapper, Samantha_Alipio_WMDE, Akuckartz, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T264007: Implement modular LocalSetting.php configuration
despens created this task.
despens added a project: Wikibase-Containers.
Restricted Application added a subscriber: Aklapper.
Restricted Application added projects: Wikidata, User-Addshore.
TASK DESCRIPTION
Currently, the Wikibase docker distribution uses `envsubst` to render
settings declared in environment variables from a template file into a single
`LocalSettings.php`. If users do not like this, they have to provide their own
`LocalSettings.php` and map it into the container.
There are several issues with this approach:
- The `envsubst` approach is rather exotic
<https://github.com/wmde/wikibase-docker/blob/262ffef7cc550381309c360e3e92507e85cd8bf6/wikibase/1.34/base/entrypoint.sh#L36>
and requires the essential `$` character in PHP to be escaped as `${DOLLAR}`.
- Users that map their own `LocalSettings.php` need to make sure that it
still contains all the settings made in the default file. This is especially
crucial during version updates. Unfortunately, the source code for the default
`LocalSettings.php` file is distributed across two docker containers (1
<https://github.com/wmde/wikibase-docker/blob/master/wikibase/1.34/base/LocalSettings.php.template>,
2
<https://github.com/wmde/wikibase-docker/blob/master/wikibase/1.34/bundle/LocalSettings.php.wikibase-bundle.template>),
wikibase `base` and `bundle`, and as described above pretty hard to parse and
error-prone to adopt.
Instead, the default `LocalSettings.php` should be changed to read
configuration settings via the standard PHP function `getenv()` and then load
optional user-specific configuration from a directory. This would allow users
to leave the default `LocalSettings.php` just as provided by the docker
distribution. Instead of mapping a custom `LocalSettings.php` into the
container, they would map a directory containing _additional_ configuration,
for instance loading more extensions or skins.
Here is an example of how the official `LocalSettings.php` could look, as in
use by Rhizome:
https://gist.github.com/despens/1fb618747488298f6f83ea9468661fd3
Additional configuration is loaded from a directory called
`LocalSettings.php.d`—of course that could be named differently.
That directory is mapped into the container and holds the files 000_main.php,
100_namespaces.php,200_extensions-wikibase.php, 201_extensions-localmedia.php,
202_extensions-scribuntu.php, 203_extensions-geshi.php,
204_extensions-sendgrid.php, 205_extensions-visualeditor.php,
301_theming-rhizome.php, 400_permissions.php, 500_debugging.php — you get the
idea.
This approach allows for the following mindblowing workflows:
- Users can upgrade Wikibase without having to weed through the default
`LocalSettings.php` that is required for just basic operation, and compare it
against their customized version.
- Should they need to examine the default file, it will be easily readable
and they could copy lines verbatim from the git repository.
- On upgrades, users will benefit of new features being enabled and not
accidentally miss the good stuff or end up with a misconfiguration.
- Different team members can focus on configuring specific parts of their
Wikibase and not worry about the rest of the configuration.
- Version control will be improved.
TASK DETAIL
https://phabricator.wikimedia.org/T264007
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Addshore, despens
Cc: despens, Aklapper, Samantha_Alipio_WMDE, Akuckartz, darthmon_wmde, Jelabra,
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen,
rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Addshore, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T197660: Accept arbitrary lines to be appended to deployed LocalSettings.php
despens added a comment. - I would recommend looking at how nextcloud handles docker configuration <https://docs.nextcloud.com/server/19/admin_manual/configuration_server/config_sample_php_parameters.html#multiple-config-php-file>: defaults shipped in the docker container and configured by environment variables are handled in the default config.php file. Additionally, any file called *.config.php is loaded and can override these settings. Something similar could easily be adopted as a convention for wikibase and satisfy users that would like to just use the defaults, use augmented defaults, or use just their own settings. - The "rendering" of environment variables into LocalSettings.php when the docker container is run for the first time is very problematic, because future changes to the environment variables won't have any effect. This is frustrating when trying to debug issues related to interactions in between containers, reverse proxy settings, or moving a wikibase install in between local debugging and publicly deployed location. — We have moved to using `gentenv()` in our `LocalSettings.php` which seems much more dockerish :) TASK DETAIL https://phabricator.wikimedia.org/T197660 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Aklapper, Tarrow, Addshore, despens, Samantha_Alipio_WMDE, Akuckartz, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T90492: [Task] Make Wikibase Repo work with a custom File collection, not only Wikimedia Commons
despens added a comment. Superceded by T258932 <https://phabricator.wikimedia.org/T258932> TASK DETAIL https://phabricator.wikimedia.org/T90492 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Danmichaelo, Loz.ross, Bcbussche, lucamauri, jmac, Yurik, Addshore, Abit, ToBeFree, Jakob_WMDE, Tarrow, LJ, Daniel_Mietchen, despens, RazShuty, PokestarFan, Lokal_Profil, Reedy, Steinsplitter, Snaterlicious, adrianheine, Ricordisamoa, gerritbot, daniel, Aklapper, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T251021: Wikibase falls back on local media files when unsing Commons Media data type.
despens created this task. despens added a project: Wikibase-Containers. Restricted Application added a subscriber: Aklapper. Restricted Application added projects: Wikidata, User-Addshore. TASK DESCRIPTION Rhizome's Wikibase runs on Wikibase 1.34 bundle (Special:Version <https://artbase.rhizome.org/wiki/Special:Version>) On statement of the "Commons media file" type, if Wikibase falls back to displaying local images if the referenced file is not found on commons. Example: https://artbase.rhizome.org/wiki/Item:Q2508 The statement's value is `Ca-250.jpg`, with a link pointing to the non-existing https://commons.wikimedia.org/wiki/File:Ca-250.jpg The local image https://artbase.rhizome.org/w/images/b/b8/Ca-250.jpg is displayed. This happens across all "Commons media file" properties in that deployment. (This is fun because T90492 <https://phabricator.wikimedia.org/T90492>) TASK DETAIL https://phabricator.wikimedia.org/T251021 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, despens Cc: Addshore, despens, Aklapper, Samantha_Alipio_WMDE, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331, DannyS712 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T197660: Accept arbitrary lines to be appended to deployed LocalSettings.php
despens added a comment. The erroneous bug report T246952 <https://phabricator.wikimedia.org/T246952> is a good illustration of how the current handling of LocalSettings.php in the container is problematic: When running the Docker distribution of Wikibase, and any customization is desired, such as loading an additional extension, container users have to provide their own LocalSettings.php Since only one LocalSettings.php is loaded (and that file is "rendered" when the container is started for the first time) container users have to keep track of any changes to the default LocalSettings.php and keep their customized LocalSettings.php in sync, every time the container is updated. This is a recipe for human error. My suggestion would be that the default LocalSettings.php - isn't "rendered" dependent on environment variables, but uses `getenv` to read the environment variables - at the end of the file loads additional configuration from let's say `UserSettings.php`, a file that is by default empty, but can be mapped into the container. That file would only contain customizations and would not need to repeat anything declared in the default LocalSettings.php that is required for the Docker setup to work. TASK DETAIL https://phabricator.wikimedia.org/T197660 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Aklapper, Tarrow, Addshore, despens, Samantha_Alipio_WMDE, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T246952: Include Scribuntu in wikibase:1.34 Docker image
despens closed this task as "Resolved". despens added a comment. Not true, Scribuntu is included in the Docker image and works. The issue arose from customizations in LocalSettings.php and not being able to merge these customizations with default settings that are shipped with the container. — That's something for another issue/task. TASK DETAIL https://phabricator.wikimedia.org/T246952 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, despens Cc: despens, Aklapper, Samantha_Alipio_WMDE, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T246952: Include Scribuntu in wikibase:1.34 Docker image
despens created this task. despens added a project: Wikibase-Containers. Restricted Application added a subscriber: Aklapper. Restricted Application added projects: Wikidata, User-Addshore. TASK DESCRIPTION According to the Scribuntu Extension page <https://www.mediawiki.org/wiki/Extension:Scribunto>, Scribuntu is included with Mediawiki 1.34. This is the Mediawiki version used in the latest Wikibase Docker image. However, Scribuntu is apparently not included. It is unclear how to manually add Scribuntu to the Docker image. The way that worked previously—using a volume to map the extension's files into the container—has apparently become incompatible with Mediawiki 1.34. TASK DETAIL https://phabricator.wikimedia.org/T246952 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, despens Cc: despens, Aklapper, Samantha_Alipio_WMDE, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T245542: Make rdfDump.php export in WDQS-ready format
despens created this task. despens added a project: Wikibase-Containers. Restricted Application added a subscriber: Aklapper. Restricted Application added a project: Wikidata. TASK DESCRIPTION At the moment, the Wikibase `dumpRdf.php` script produces TTL that should be piped through the Munge script before getting loaded into WDQS. The Munge script removes some triples for better performance <https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#WDQS_data_differences> and splits the TTL into smaller chunks before being loaded into Blazegraph. This step could be skipped if `dumpRdf.php` had an option to write TTL already in the optimized format, and optionally export a series of files instead of just one. TASK DETAIL https://phabricator.wikimedia.org/T245542 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Aklapper, Samantha_Alipio_WMDE, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T196042: Configurable RDF prefixes for WDQS
despens added a comment. This etherpad <https://etherpad.wikimedia.org/p/Wikibase-Extensions-Federation> contains notes on WDQS namespaces under "Configure your own name space for query service" TASK DETAIL https://phabricator.wikimedia.org/T196042 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: despens, Seb35, tk, Aklapper, Smalyshev, Addshore, Tarrow, Samantha_Alipio_WMDE, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T245352: [SUPPORT] Munging errors "Unrecognized subjects"
despens added a comment. OK now I am specifying the `conceptURI`, and now all data is moving fine into the query service! docker-compose exec wdqs ./munge.sh -f /tmp/db-dumps/2020-02-18.ttl -d /tmp/db-dumps/mungedOut -- --conceptUri https://artbase.rhizome.org I was under the impression the `conceptUri` was optional when you use the default 🤦♂️ Sorry for the trouble. TASK DETAIL https://phabricator.wikimedia.org/T245352 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, despens Cc: despens, Aklapper, Samantha_Alipio_WMDE, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Asahiko, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T245352: [SUPPORT] Munging errors "Unrecognized subjects"
despens added a comment. The environments are the same for `wdqs` and `wdqs-updater` containers, here are the full entries: environment: - WIKIBASE_SCHEME=https - WIKIBASE_HOST=artbase.rhizome.org - WDQS_HOST=wdqs.svc - WDQS_PORT= TASK DETAIL https://phabricator.wikimedia.org/T245352 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, despens Cc: despens, Aklapper, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Asahiko, Wikidata-bugs, aude, Lydia_Pintscher, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T245352: Munging errors "Unrecognized subjects"
despens updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T245352 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, despens Cc: despens, Aklapper, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Asahiko, Wikidata-bugs, aude, Addshore, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T245352: Munging errors "Unrecognized subjects"
despens created this task.
despens added a project: Wikibase-Containers.
Restricted Application added a subscriber: Aklapper.
Restricted Application added projects: Wikidata, User-Addshore.
TASK DESCRIPTION
I am following this excellent tutorial by @Addshore
<https://addshore.com/2019/11/changing-the-concept-uri-of-an-existing-wikibase-with-data/>
to reset my WDQS after migrating data to a new Wikibase.
The munging throws an error:
#logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -
%msg%n
23:57:52.108 [main] INFO org.wikidata.query.rdf.tool.Munge - Switching to
/tmp/db-dumps/mungedOut/wikidump-1.ttl.gz
23:58:02.401 [main] INFO o.wikidata.query.rdf.tool.rdf.Munger -
Unrecognized subjects:
[https://artbase.rhizome.org/entity/statement/Q4198-2BB92CD9-DB2D-4482-87F1-115C209FE3A9,
https://artbase.rhizome.org/prop/statement/value/P109,
https://artbase.rhizome.org/entity/statement/Q1623-28C1990A-7E66-442C-8617-37D890C63B30,
https://artbase.rhizome.org/prop/statement/value/P107,
https://artbase.rhizome.org/prop/statement/value/P108,
https://artbase.rhizome.org/prop/statement/value/P101,
https://artbase.rhizome.org/prop/statement/value/P102,
https://artbase.rhizome.org/entity/statement/ [...]
...then follows a list of each and every triple in my Wikibase as
"Unrecognized subject". Finally, the output concludes with...
at
org.wikidata.query.rdf.tool.rdf.Munger$MungeOperation.finishCommon(Munger.java:965)
at
org.wikidata.query.rdf.tool.rdf.Munger$MungeOperation.munge(Munger.java:493)
at org.wikidata.query.rdf.tool.rdf.Munger.munge(Munger.java:148)
at org.wikidata.query.rdf.tool.rdf.Munger.munge(Munger.java:192)
at
org.wikidata.query.rdf.tool.Munge$EntityMungingRdfHandler.munge(Munge.java:255)
at
org.wikidata.query.rdf.tool.Munge$EntityMungingRdfHandler.endRDF(Munge.java:243)
at
org.wikidata.query.rdf.tool.rdf.DelegatingRdfHandler.endRDF(DelegatingRdfHandler.java:28)
at org.openrdf.rio.turtle.TurtleParser.parse(TurtleParser.java:223)
at org.wikidata.query.rdf.tool.Munge.run(Munge.java:115)
at org.wikidata.query.rdf.tool.Munge.main(Munge.java:76)
http://www.w3.org/TR/html4/loose.dtd";>blazegraph™ by SYSTAPtotalElapsed=188ms, elapsed=65ms, connFlush=0ms, batchResolve=0,
whereClause=0ms, deleteClause=0ms, insertClause=0msCOMMIT: totalElapsed=242ms, commitTime=1581813802754,
mutationCount=6Processing wikidump-1.ttl.gz
http://www.w3.org/TR/html4/loose.dtd";>blazegraph™ by SYSTAPtotalElapsed=92ms, elapsed=92ms, connFlush=0ms, batchResolve=0,
whereClause=0ms, deleteClause=0ms, insertClause=0msCOMMIT: totalElapsed=131ms, commitTime=1581813803605,
mutationCount=6File wikidump-2.ttl.gz not found, terminating
The munger creates a `wikidump-1.ttl.gz` that is 535 bytes long.
I wonder what the issue is with my exported TTL file, but it doesn't look
problematic to me, all namespaces are defined at the top of the file with the
correct base URI https://artbase.rhizome.org and the docker-compose file
contains the environment to make that known to WDQS:
environment:
- WIKIBASE_SCHEME=https
- WIKIBASE_HOST=artbase.rhizome.org
I was trying to examine the munger's code to see when it throws the
"Unrecognized subjects" error but the Dockerfile
<https://github.com/wmde/wikibase-docker/blob/master/wdqs/0.3.10/Dockerfile>
just loads compiled JVM binaries and I don't know where to find the source.
TASK DETAIL
https://phabricator.wikimedia.org/T245352
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Addshore, despens
Cc: despens, Aklapper, darthmon_wmde, Jelabra, Nandana, Lahi, Gq86,
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS,
Asahiko, Wikidata-bugs, aude, Addshore, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T88454: [RFC] Support for line breaks in mono-lingual text data type
despens added a comment. I don't see a need for this feature anymore, and would even see this as giving people coming from RDBMS wrong ideas on how to transition to linked data. At least this was the case for myself :) TASK DETAIL https://phabricator.wikimedia.org/T88454 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: Addshore, Jonas, adrianheine, thiemowmde, Lydia_Pintscher, despens, Aklapper, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, TomT0m, _jensen, rosalieper, Scott_WUaS, Wong128hk, Luke081515, Wikidata-bugs, aude, fbstj, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T205023: Add documentation for modifying the theme color in the Wikibase Docker distribution
despens added a comment. I have done some customization with MediaWiki:Common.css, which is pretty easy. But the logo could be set in the docker-compose file indeed.TASK DETAILhttps://phabricator.wikimedia.org/T205023EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Jan_Dittrich, Aklapper, thisismattmiller, Nandana, LJ, Cpaulf30, Lahi, Gq86, SandraF_WMF, Andrawaag, GoranSMilovanovic, Ivana_Isadora, Jayprakash12345, QZanden, YULdigitalpreservation, Gstupp, LawExplorer, Abbe98, srodlund, Wikidata-bugs, aude, Daniel_Mietchen, Dinoguy1000, Lydia_Pintscher, Addshore, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T205922: Impossible to establish site links
despens added a comment. Screencap of how this looks: F26269900: sitelinks.gifTASK DETAILhttps://phabricator.wikimedia.org/T205922EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Aklapper, despens, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T205922: Impossible to establish site links
despens created this task.despens added a project: Wikibase-Containers.Restricted Application added a subscriber: Aklapper.Restricted Application added a project: Wikidata. TASK DESCRIPTIONAt the moment it seems impossible to create site links from an item to either Wikipedia or even the Mediawiki that comes with the docker image. It would be good to have documentation about how to set this up or have it as an option in the docker-compose file.TASK DETAILhttps://phabricator.wikimedia.org/T205922WORKBOARDhttps://phabricator.wikimedia.org/project/board/3079/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Aklapper, despens, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T197682: URIs returned by Query Service contain docker network name
despens closed this task as "Resolved".despens claimed this task. TASK DETAILhttps://phabricator.wikimedia.org/T197682EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: tk, Aklapper, Addshore, despens, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197682: URIs returned by Query Service contain docker network name
despens added a comment. What hast worked is setting WIKIBASE_HOST in the docker-compose file to the actual public hostname and in the Wikibase's LocalSettings.php adding an explicit concep URI prefix *with http protocol*, like `$wgWBRepoSettings['conceptBaseUri'] = "http://staging.catalog.rhizome.org/";TASK DETAILhttps://phabricator.wikimedia.org/T197682EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: tk, Aklapper, Addshore, despens, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197658: Provide easy script to reset Blazegraph
despens added a comment. We have been able to put the ttl-dump into Blazegraph now with the following process: in the wdqs container, install curl: # apk add --no-cache curl export ttl dump into directory shared in between containers; command on docker host: # docker exec dockercomposefiles_wikibase_1 php extensions/Wikibase/repo/maintenance/dumpRdf.php > dumps/ttl-20180917.ttl inside wdqs container, import ttl file by directly instructing blazegraph to load it: # curl "http://localhost:/bigdata/namespace/wdq/sparql" --data-urlencode "update=DROP ALL; LOAD ;" queries are now possible via the query service, example query Big Issue None of the query building helpers in WDQS work. The interface doesn't know about any properties or objects. Questions What is required to make the query building functions in WDQS work? what do munge.sh and loadData.sh do apart from splitting up a potentially large TTL file into smaller chunks? (Since Rhizome's data is quite small at the moment, we wouldn't really need to split up the data.) TASK DETAILhttps://phabricator.wikimedia.org/T197658EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Tarrow, Smalyshev, tk, Aklapper, Addshore, despens, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Gstupp, merbst, LawExplorer, Avner, Gehel, Abbe98, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197658: Provide easy script to reset Blazegraph
despens added a comment.
Thank you @Smalyshev!
It seems like the --conceptUri switch is a part of munger. It is not accepted as a parameter for runUpdate.sh.
After checking this, I did also modify the Wikibase's LocalSettings.php to explicitely use http (without 's') for concept URLs:
$wgWBRepoSettings['conceptBaseUri'] = 'http://staging.catalog.rhizome.org/entity/';
The API delivers RDF with the http protocol used in all local name spaces, too: http://staging.catalog.rhizome.org/wiki/Special:EntityData/Q1996.ttl
Now, running the updater still only updates 26 edits:
bash-4.4# ./runUpdate.sh -- -w staging.catalog.rhizome.org -s 2001010100 --init
Updating via http://localhost:/bigdata/namespace/wdq/sparql
OpenJDK 64-Bit Server VM warning: Cannot open file /var/log/wdqs/wdqs-updater_jvm_gc.pid119.log due to No such file or directory
I> No access restrictor found, access to any MBean is allowed
Jolokia: Agent started with URL http://127.0.0.1:8778/jolokia/
#logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
05:57:09.390 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got 26 changes, from Q2596@77721@20180130201206|81595 to Q4977@77814@20180215170648|81689
05:57:09.809 [main] INFO org.wikidata.query.rdf.tool.Updater - Polled up to 2018-02-15T17:06:48Z (next: 20180215170711|81690) at (0.0, 0.0, 0.0) updates per second and (0.0, 0.0, 0.0) milliseconds per second
05:57:09.885 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Skipping change with bogus title: Main Page
05:57:09.887 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got 9 changes, from Q4977@77815@20180215170711|81690 to Q1166@77841@20180708070530|81717
05:57:09.976 [main] INFO org.wikidata.query.rdf.tool.Updater - Polled up to 2018-07-08T07:05:30Z at (0.0, 0.0, 0.0) updates per second and (0.0, 0.0, 0.0) milliseconds per second
05:57:10.008 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got no real changes
05:57:10.009 [main] INFO org.wikidata.query.rdf.tool.Updater - Sleeping for 10 secs
05:57:20.036 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got no real changes
So I guess the whole change history is not available in the Wikibase API after migrating the database from the previous install.
Would it be correct then to export the full ttl dump, load it into Blazegraph, and then run the updater again?TASK DETAILhttps://phabricator.wikimedia.org/T197658EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Tarrow, Smalyshev, tk, Aklapper, Addshore, despens, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Gstupp, merbst, LawExplorer, Avner, Gehel, Abbe98, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197658: Provide easy script to reset Blazegraph
despens added a comment.
When removing the alias staging.catalog.rhizome.org from the wikibase container in the docker-compose file, the connection is made via the docker network and can be established. However, the contents of the Wikibase are still rejected:
bash-4.4# ./runUpdate.sh -- -w staging.catalog.rhizome.org -s 2001010100 --init
Updating via http://localhost:/bigdata/namespace/wdq/sparql
OpenJDK 64-Bit Server VM warning: Cannot open file /var/log/wdqs/wdqs-updater_jvm_gc.pid125.log due to No such file or directory
I> No access restrictor found, access to any MBean is allowed
Jolokia: Agent started with URL http://127.0.0.1:8778/jolokia/
#logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
11:04:25.240 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got 26 changes, from Q2596@77721@20180130201206|81595 to Q4977@77814@20180215170648|81689
11:04:25.896 [update 4] WARN org.wikidata.query.rdf.tool.Updater - Contained error syncing. Giving up on Q4966
org.wikidata.query.rdf.tool.rdf.Munger$BadSubjectException: Unrecognized subjects: [https://staging.catalog.rhizome.org/entity/statement/Q4966-3e9eee06-4352-81b8-04cc-c1526542629e, https://staging.catalog.rhizome.org/entity/statement/Q4966-2beb1833-409f-0b9f-c075-571cc6b78eb0, https://staging.catalog.rhizome.org/entity/statement/Q4966-69862d13-4a1e-5770-c402-c37cf7441093, https://staging.catalog.rhizome.org/entity/statement/Q4966-9b394b4f-4c87-6aad-a016-042256e4d990, https://staging.catalog.rhizome.org/entity/Q4966, https://staging.catalog.rhizome.org/value/2b3197a343b1554b824b915aa6ffd70f]. Expected only sitelinks and subjects starting with http://staging.catalog.rhizome.org/wiki/Special:EntityData/ and http://staging.catalog.rhizome.org/entity/
at org.wikidata.query.rdf.tool.rdf.Munger$MungeOperation.finishCommon(Munger.java:833)
at org.wikidata.query.rdf.tool.rdf.Munger$MungeOperation.munge(Munger.java:430)
at org.wikidata.query.rdf.tool.rdf.Munger.munge(Munger.java:223)
at org.wikidata.query.rdf.tool.Updater.handleChange(Updater.java:305)
at org.wikidata.query.rdf.tool.Updater.lambda$handleChanges$0(Updater.java:188)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
11:04:25.897 [update 6] WARN org.wikidata.query.rdf.tool.Updater - Contained error syncing. Giving up on Q4967
[...repeated for hundreds of Q-ids...]
Any idea what is going on here? Is the data in the Wikibase itself structured wrongly?TASK DETAILhttps://phabricator.wikimedia.org/T197658EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Tarrow, Smalyshev, tk, Aklapper, Addshore, despens, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Gstupp, merbst, LawExplorer, Avner, Gehel, Abbe98, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197658: Provide easy script to reset Blazegraph
despens added a comment.
I think there is lots of ambiguity here...
For the record: I'm entering the WDQS container, not the WDQS-updater one:
root@wikibase-docker:~# docker exec -ti dockercomposefiles_wdqs_1 bash
From inside that docker, I'm executing the command:
bash-4.4# ./runUpdate.sh -- -w staging.catalog.rhizome.org -s 2001010100
The connection fail seems to happen when the updater tries to connect to Rhizome's Wikibase:
bash-4.4# ./runUpdate.sh -- -w staging.catalog.rhizome.org -s 2001010100
Updating via http://localhost:/bigdata/namespace/wdq/sparql
OpenJDK 64-Bit Server VM warning: Cannot open file /var/log/wdqs/wdqs-updater_jvm_gc.pid616.log due to No such file or directory
I> No access restrictor found, access to any MBean is allowed
Jolokia: Agent started with URL http://127.0.0.1:8778/jolokia/
#logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
10:48:42.193 [main] ERROR org.wikidata.query.rdf.tool.Update - Error during updater run.
java.lang.RuntimeException: org.apache.http.conn.HttpHostConnectException: Connect to staging.catalog.rhizome.org:443 [staging.catalog.rhizome.org/172.18.0.5] failed: Connection refused (Connection refused)
The connection to the Wikibase is refused. It points to an internal docker network IP address and tries to connect via HTTPS, but the docker setup doesn't provide HTTPS naturally.
However, if I'm running the updater without specifying the Wikibase host with the -w switch, it happily gets the triples of Wikidata proper into my modest Blazegraph instance:
bash-4.4# ./runUpdate.sh -- -s 2001010100 --init
Updating via http://localhost:/bigdata/namespace/wdq/sparql
OpenJDK 64-Bit Server VM warning: Cannot open file /var/log/wdqs/wdqs-updater_jvm_gc.pid644.log due to No such file or directory
I> No access restrictor found, access to any MBean is allowed
Jolokia: Agent started with URL http://127.0.0.1:8778/jolokia/
#logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
10:55:06.656 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got 79 changes, from Q43576244@725717221@20180814105503|761278916 to Q55870317@725717323@20180814105519|761279016
10:55:15.531 [main] INFO org.wikidata.query.rdf.tool.Updater - Polled up to 2018-08-14T10:55:19Z (next: 20180814105519|761279017) at (0.0, 0.0, 0.0) updates per second and (0.0, 0.0, 0.0) milliseconds per second
10:55:15.762 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got 77 changes, from Q23647613@725717330@20180814105520|761279026 to Q39895159@725717420@20180814105536|761279115
[...]
So to me it looks like the localhost: doesn't seem too wrong, just the source of the triples cannot be set.TASK DETAILhttps://phabricator.wikimedia.org/T197658EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Tarrow, Smalyshev, tk, Aklapper, Addshore, despens, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Gstupp, merbst, LawExplorer, Avner, Gehel, Abbe98, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197658: Provide easy script to reset Blazegraph
despens added a comment.
I think I need more guidance on how to run this script. I did use the --start and --init switches before.
When calling ./runUpdate.sh -- -v -s 2001010112 --init it doesn't seem possible to connect to Blazegraph because the updater already runs?
bash-4.4# ./runUpdate.sh -- -v -s 2001010112 --init
Updating via http://localhost:/bigdata/namespace/wdq/sparql
OpenJDK 64-Bit Server VM warning: Cannot open file /var/log/wdqs/wdqs-updater_jvm_gc.pid355.log due to No such file or directory
Could not start Jolokia agent: java.net.BindException: Address in use
#logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
18:36:01.641 [main] INFO o.w.q.rdf.tool.options.OptionsUtils - Verbose mode activated
#logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
18:36:02.229 [main] DEBUG o.w.query.rdf.tool.rdf.RdfRepository - Setting last updated time to Mon Jan 01 12:00:00 GMT 2001
18:36:02.242 [main] DEBUG o.w.query.rdf.tool.rdf.RdfRepository - Running SPARQL: DELETE {
?o .
}
WHERE {
?o .
};
INSERT DATA {
"2001-01-01T12:00:00.000Z"^^ .
}
18:36:02.277 [main] INFO o.w.query.rdf.tool.rdf.RdfRepository - HTTP request failed: java.util.concurrent.ExecutionException: java.net.ConnectException: Connection refused, attempt 1, will retry
18:36:04.280 [main] INFO o.w.query.rdf.tool.rdf.RdfRepository - HTTP request failed: java.util.concurrent.ExecutionException: java.net.ConnectException: Connection refused, attempt 2, will retry
18:36:08.283 [main] INFO o.w.query.rdf.tool.rdf.RdfRepository - HTTP request failed: java.util.concurrent.ExecutionException: java.net.ConnectException: Connection refused, attempt 3, will retry
18:36:16.286 [main] INFO o.w.query.rdf.tool.rdf.RdfRepository - HTTP request failed: java.util.concurrent.ExecutionException: java.net.ConnectException: Connection refused, attempt 4, will retry
18:36:26.289 [main] INFO o.w.query.rdf.tool.rdf.RdfRepository - HTTP request failed: java.util.concurrent.ExecutionException: java.net.ConnectException: Connection refused, attempt 5, will retry
18:36:36.291 [main] INFO o.w.query.rdf.tool.rdf.RdfRepository - HTTP request failed: java.util.concurrent.ExecutionException: java.net.ConnectException: Connection refused, attempt 6, will fail
18:36:36.294 [main] ERROR org.wikidata.query.rdf.tool.Update - Error during initialization.
org.wikidata.query.rdf.tool.exception.FatalException: Error updating triple store
at org.wikidata.query.rdf.tool.rdf.RdfRepository.execute(RdfRepository.java:732)
at org.wikidata.query.rdf.tool.rdf.RdfRepository.updateLeftOffTime(RdfRepository.java:665)
at org.wikidata.query.rdf.tool.Update.buildRecentChangePollerChangeSource(Update.java:156)
at org.wikidata.query.rdf.tool.Update.buildChangeSource(Update.java:141)
at org.wikidata.query.rdf.tool.Update.main(Update.java:65)
Caused by: com.github.rholder.retry.RetryException: Retrying failed to complete successfully after 6 attempts.
at com.github.rholder.retry.Retryer.call(Retryer.java:174)
at org.wikidata.query.rdf.tool.rdf.RdfRepository.execute(RdfRepository.java:721)
... 4 common frames omitted
Caused by: java.util.concurrent.ExecutionException: java.net.ConnectException: Connection refused
at org.eclipse.jetty.client.util.FutureResponseListener.getResult(FutureResponseListener.java:118)
at org.eclipse.jetty.client.util.FutureResponseListener.get(FutureResponseListener.java:101)
at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:639)
at org.wikidata.query.rdf.tool.rdf.RdfRepository.lambda$execute$0(RdfRepository.java:722)
at com.github.rholder.retry.AttemptTimeLimiters$NoAttemptTimeLimit.call(AttemptTimeLimiters.java:78)
at com.github.rholder.retry.Retryer.call(Retryer.java:160)
... 5 common frames omitted
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at org.eclipse.jetty.io.SelectorManager.finishConnect(SelectorManager.java:340)
at org.eclipse.jetty.io.SelectorManager$ManagedSelector.processConnect(SelectorManager.java:671)
at org.eclipse.jetty.io.SelectorManager$ManagedSelector.processKey(SelectorManager.java:640)
at org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:607)
at org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:545)
at org.eclipse.jetty.util.thread.NonBlockingThread.run(NonBlockingThread.java:52)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:610)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:539)
at java.lang.Thread.run(Thread.java:748)
Exception in thread "main" org.wikidata.query.rdf.tool.exception.FatalException: Error updating triple store
at org.wikidata.query.rdf.tool.rdf.RdfRepository.execute(Rd
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T197658: Provide easy script to reset Blazegraph
despens added a subscriber: Tarrow.despens added a comment.
After some consultation with @Tarrow
I removed the query service volume (starting from scratch with Blazegraph)
Updated all instances of wikibase.svc in docker-compose.yml to the full public domain name.
Entered the wdqs-updater container and ran the updating command again.
This created the following error:
# docker exec -it dockercomposefiles_wdqs-updater_1 bash
bash-4.4# nano
bash: nano: command not found
bash-4.4# /runUpdate.sh -- -v --start 2001010112 -t 2 --verify -W https://staging.catalog.rhizome.org/ -U http://staging.catalog.rhizome.org/ --init
wait-for-it.sh: waiting 120 seconds for staging.catalog.rhizome.org:80
wait-for-it.sh: staging.catalog.rhizome.org:80 is available after 0 seconds
wait-for-it.sh: waiting 120 seconds for wdqs.svc:
wait-for-it.sh: wdqs.svc: is available after 0 seconds
Updating via http://wdqs.svc:/bigdata/namespace/wdq/sparql
OpenJDK 64-Bit Server VM warning: Cannot open file /var/log/wdqs/wdqs-updater_jvm_gc.pid202.log due to No such file or directory
Could not start Jolokia agent: java.net.BindException: Address in use
#logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
09:19:27.957 [main] INFO org.wikidata.query.rdf.tool.Update - Checking where we left off
09:19:27.960 [main] INFO o.w.query.rdf.tool.rdf.RdfRepository - Checking for left off time from the updater
09:19:28.099 [main] INFO o.w.query.rdf.tool.rdf.RdfRepository - Found left off time from the updater
09:19:28.101 [main] ERROR org.wikidata.query.rdf.tool.Update - Error during initialization.
java.lang.IllegalStateException: RDF store reports the last update time is before the minimum safe poll time. You will have to reload from scratch or you might have missing data.
at org.wikidata.query.rdf.tool.Update.buildRecentChangePollerChangeSource(Update.java:168)
at org.wikidata.query.rdf.tool.Update.buildChangeSource(Update.java:141)
at org.wikidata.query.rdf.tool.Update.main(Update.java:65)
Exception in thread "main" java.lang.IllegalStateException: RDF store reports the last update time is before the minimum safe poll time. You will have to reload from scratch or you might have missing data.
at org.wikidata.query.rdf.tool.Update.buildRecentChangePollerChangeSource(Update.java:168)
at org.wikidata.query.rdf.tool.Update.buildChangeSource(Update.java:141)
at org.wikidata.query.rdf.tool.Update.main(Update.java:65)
I'm now wondering if runUpdater.sh is starting up the updater service in general, which seems to be already running:
Could not start Jolokia agent: java.net.BindException: Address in use
The exception java.lang.IllegalStateException: RDF store reports the last update time is before the minimum safe poll time. You will have to reload from scratch or you might have missing data. doesn't make sense to me... What should be reloaded? Isn't the command I issued all about ignoring the save poll time?
Blazegraph still seems to be empty, see test query.TASK DETAILhttps://phabricator.wikimedia.org/T197658EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Tarrow, Smalyshev, tk, Aklapper, Addshore, despens, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Gstupp, merbst, LawExplorer, Avner, Gehel, Abbe98, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197658: Provide easy script to reset Blazegraph
despens added a comment.
Thanks @Smalyshev! Indeed the double dashes were the issue!
I did run the command as you provided it inside the wdqs-updater container.
It doesn't seem to change the contents of Blazegraph, there is still almost no data available at WDQS, apart from a few items.
I wonder if the change data is expired somehow in my Wikibase? The output says Found start time in the RDF store: 2018-07-08T07:05:29Z and indeed not much has happened since that time, but everything happened before!
Would it make sense to erase Blazegraph and then start ./runUpdate.sh?
Here is the output of runUpdate.sh
wait-for-it.sh: waiting 120 seconds for wikibase.svc:80
wait-for-it.sh: wikibase.svc:80 is available after 0 seconds
wait-for-it.sh: waiting 120 seconds for wdqs.svc:
wait-for-it.sh: wdqs.svc: is available after 0 seconds
Updating via http://wdqs.svc:/bigdata/namespace/wdq/sparql
OpenJDK 64-Bit Server VM warning: Cannot open file /var/log/wdqs/wdqs-updater_jvm_gc.pid99.log due to No such file or directory
Could not start Jolokia agent: java.net.BindException: Address in use
#logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
10:02:53.443 [main] INFO org.wikidata.query.rdf.tool.Update - Checking where we left off
10:02:53.446 [main] INFO o.w.query.rdf.tool.rdf.RdfRepository - Checking for left off time from the updater
10:02:53.663 [main] INFO o.w.query.rdf.tool.rdf.RdfRepository - Found left off time from the updater
10:02:53.664 [main] INFO org.wikidata.query.rdf.tool.Update - Found start time in the RDF store: 2018-07-08T07:05:29Z
10:02:54.014 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got 1 changes, from Q1166@77841@20180708070530|81717 to Q1166@77841@20180708070530|81717
10:02:54.259 [update 0] WARN org.wikidata.query.rdf.tool.Updater - Contained error syncing. Giving up on Q1166
org.wikidata.query.rdf.tool.rdf.Munger$BadSubjectException: Unrecognized subjects: [https://staging.catalog.rhizome.org/wiki/Special:EntityData/Q1166, https://staging.catalog.rhizome.org/entity/Q1166, https://staging.catalog.rhizome.org/entity/statement/Q1166-83bdfae9-469c-aaa2-8241-823fa96365e5, https://staging.catalog.rhizome.org/entity/statement/Q1166-A687AA4E-AC6C-4BCA-8010-35C23EF783C3, https://staging.catalog.rhizome.org/entity/statement/Q1166-511bb92d-497e-f37f-7b8b-2cce2730042a, https://staging.catalog.rhizome.org/entity/statement/Q1166-85603605-496B-4865-8F1C-FBB19E478DFF, https://staging.catalog.rhizome.org/entity/statement/Q1166-21D3661A-56E5-45AF-8DCB-019D30E5E3AC, https://staging.catalog.rhizome.org/entity/statement/Q1166-B2C4587C-9318-4717-B5C9-32A13B1CC2AC, https://staging.catalog.rhizome.org/entity/statement/Q1166-4d8aad6f-429f-270e-ca33-4d032f5f7f5b, https://staging.catalog.rhizome.org/entity/statement/Q1166-fcdfc3a7-4c2e-d1a8-d7e0-3a5d523ca48e]. Expected only sitelinks and subjects starting with http://wikibase.svc/wiki/Special:EntityData/ and http://wikibase.svc/entity/
at org.wikidata.query.rdf.tool.rdf.Munger$MungeOperation.finishCommon(Munger.java:833)
at org.wikidata.query.rdf.tool.rdf.Munger$MungeOperation.munge(Munger.java:430)
at org.wikidata.query.rdf.tool.rdf.Munger.munge(Munger.java:223)
at org.wikidata.query.rdf.tool.Updater.handleChange(Updater.java:305)
at org.wikidata.query.rdf.tool.Updater.lambda$handleChanges$0(Updater.java:188)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
10:02:54.342 [main] INFO org.wikidata.query.rdf.tool.Updater - Polled up to 2018-07-08T07:05:30Z at (0.0, 0.0, 0.0) updates per second and (0.0, 0.0, 0.0) milliseconds per second
10:02:54.370 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got no real changes
10:02:54.370 [main] INFO org.wikidata.query.rdf.tool.Updater - Sleeping for 10 secs
10:03:04.395 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got no real changes
10:03:04.396 [main] INFO org.wikidata.query.rdf.tool.Updater - Sleeping for 10 secs
10:03:14.419 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got no real changes
10:03:14.419 [main] INFO org.wikidata.query.rdf.tool.Updater - Sleeping for 10 secs
10:03:24.442 [main] INFO o.w.q.r.t.change.RecentChangesPoller - Got no real changes
10:03:24.443 [main] INFO org.wikidata.query.rdf.tool.Updater - Sleeping for 10 secs
[...and so forth...]TASK DETAILhttps://phabricator.wikimedia.org/T197658EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Smalyshev, tk, Aklapper, Addshore, despens, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Gstupp, merbst, LawExplorer, Avner, Gehel, Abbe98, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybu
[Wikidata-bugs] [Maniphest] [Commented On] T197663: Occurrences of localhost in several places in Mediawiki
despens added a comment. I had to correctly configure the reverse proxy for the .htaccess redirect to function. The problem is indeed fixed, feel free to close. When all is done I will share the complete setup.TASK DETAILhttps://phabricator.wikimedia.org/T197663EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Aklapper, Addshore, despens, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197649: Add Scribunto extension to bundle
despens added a comment. Scribuntu is easy enough to install actually, however it would be nice to be included alongside activated GeSHi and CodeEditor extensions. Scribunto demo on Rhizome's catalogTASK DETAILhttps://phabricator.wikimedia.org/T197649EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Aklapper, despens, Tarrow, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T197665: Redirecting issues Mediawiki
despens closed this task as "Resolved".despens claimed this task.despens added a comment. Mediawiki-initiated redirects have been solved by setting $wgServer in LocalSettings.php. Apache-level redirects, as in https://staging.catalog.rhizome.org/entity/ still use localhost. This seems to be caused by the .htaccess file that comes with the docker, containing # rewrite /entity/ URLs like wikidata per # https://meta.wikimedia.org/wiki/Wikidata/Notes/URI_scheme RewriteRule ^/?entity/(.*)$ /wiki/Special:EntityData/$1 [R=303,QSA] It works as soon as I set the reverse proxy to transparent. (transparent directive in Caddy.) Closing!TASK DETAILhttps://phabricator.wikimedia.org/T197665EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Aklapper, Addshore, despens, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T198956: Adding custom extensions with volumes, add php composer to image
despens closed this task as "Invalid".despens added a comment. The SendGrid extension magically worked without running php composer. Closing since I am not sure what exactly composer does and how it does or doesn't affect other extensions.TASK DETAILhttps://phabricator.wikimedia.org/T198956EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197666: OAuth extension not working in Mediawiki
despens added a comment. After adding wfLoadExtension( 'OAuth' ); and $wgSecretKey = ""; to LocalSettings.php, the special page https://staging.catalog.rhizome.org/wiki/Special:OAuth/initiate returns another error: A database query error has occurred. This may indicate a bug in the software. [4c8f6a094aeb89788c334f87] 2018-07-07 18:43:41: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" Retrieved from "https://staging.catalog.rhizome.org/wiki/Special:OAuth/initiate" It would be helpful if the extensions that are part of the docker distribution would be documented in the LocalSettings.php.templater file so when providing a custom one it would be clear what settings it needs to contain. I am at a loss what the database query issue might be. Since I did migrate the database from my legacy Wikibase install (and ran the updater script), I wonder if the updater script is incomplete.TASK DETAILhttps://phabricator.wikimedia.org/T197666EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Aklapper, Addshore, Tarrow, despens, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197666: Quickstatements login calling non-existing part in Mediawiki
despens added a comment. @Addshore I am using Caddy. However the issue is apparently that the OAuth extension doesn't work, Quickstatements tries to load https://staging.catalog.rhizome.org/wiki/Special:OAuth/initiate According to Special:Version OAuth is present.TASK DETAILhttps://phabricator.wikimedia.org/T197666EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Aklapper, Addshore, Tarrow, despens, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T197666: OAuth extension not working in Mediawiki
despens renamed this task from "Quickstatements login calling non-existing part in Mediawiki" to "OAuth extension not working in Mediawiki". TASK DETAILhttps://phabricator.wikimedia.org/T197666EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Aklapper, Addshore, Tarrow, despens, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197658: Provide easy script to reset Blazegraph
despens added a comment.
I am looking at runUpdate.sh inside the wdqs container, which I believe is documented here.
In order to import all statements, I tried to set a start time long in the past, yielding errors:
bash-4.4# pwd
/wdqs
bash-4.4# ./runUpdate.sh -v --start 2001010112 -t 2 --verify -W https://staging.catalog.rhizome.org/ -U http://staging.catalog.rhizome.org/ --init
./runUpdate.sh: illegal option -- v
./runUpdate.sh: illegal option -- -
Updating via http://localhost:/bigdata/namespace/wdq/sparql
OpenJDK 64-Bit Server VM warning: Cannot open file /var/log/wdqs/wdqs-updater_jvm_gc.pid238.log due to No such file or directory
I> No access restrictor found, access to any MBean is allowed
Jolokia: Agent started with URL http://127.0.0.1:8778/jolokia/
#logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
Invalid argument: com.lexicalscope.jewel.cli.ArgumentValidationException: Option only takes one value; cannot use [2001010112]: --sparqlUrl -u value : URL to post updates and queries.
Unexpected Option: W
Unexpected Option: U
The options available are:
[--batchSize -b value] : Number of recent changes fetched at a time.
[--entityNamespaces value] : If specified must be numerical indexes of Item and Property namespaces that defined in Wikibase repository, comma separated.
[--help] : Show this message
[--idrange value] : If specified must be -. Ids are iterated instead of recent changes. Start and end are inclusive.
[--ids value...] : If specified must be or list of , comma or space separated.
[--init -I] : Initialize last update time to start time
[--keepTypes] : Preserve all types
[--labelLanguage value...] : Only import labels, aliases, and descriptions in these languages.
[--pollDelay -d value] : Poll delay when no updates found
[--singleLabel value...] : Only import a single label and description using the languages specified as a fallback list. If there isn't a label in any of the specified languages then no label is imported. Ditto for description.
[--skipSiteLinks] : Skip site links
--sparqlUrl -u value : URL to post updates and queries.
[--start -s value] : Start time in 2015-02-11T17:11:08Z or 20150211170100 format.
[--tailPoller -T value] : Use secondary poller with given gap (seconds) to catch up missed updates
[--threadCount -t value] : Thread count
[--verbose -v] : Verbose mode
[--verify -V] : Verify updates (may have performance impact)
[--wikibaseHost -w value] : Wikibase host
[--wikibaseScheme value] : Wikidata url scheme
Does that mean I am trying to run the wrong runUpdate.sh, or is this another version from the one documented?TASK DETAILhttps://phabricator.wikimedia.org/T197658EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: tk, Aklapper, Addshore, despens, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Gstupp, merbst, LawExplorer, Avner, Gehel, Abbe98, Jonas, FloNight, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T198956: Adding custom extensions with volumes, add php composer to image
despens created this task.despens added a project: Wikibase-Containers.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTIONI added a volume line to docker-compose.yml that allows me to get custom extensions into the Wikibase docker, in this case the SendGrid extension: - ./mediawiki-extensions/SendGrid:/var/www/html/extensions/SendGrid It is now possible to get the extension files in place from the docker host machine. However, as the case with many extensions, downloading the files and adding the extension to LocalSettings.php is not enough: Note: You will have to run composer update in extensions/SendGrid/ folder so that composer can pick up the required SendGrid dependencies for the extension to run smoothly. I wouldn't want to install php composer on the host machine and run it there; would it make sense for composer to be included in the Wikibase docker image probably? Perhaps it can be installed ad-hoc, but since it doesn't seem to be possible to run commands as user www-data (su won't allow it b/c of missing password and sudo ist not available at all), I wasn't able to complete the process.TASK DETAILhttps://phabricator.wikimedia.org/T198956WORKBOARDhttps://phabricator.wikimedia.org/project/board/3079/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197658: Provide easy script to reset Blazegraph
despens added a comment. This issue is about clearing blazegraph and importing the complete dataset from Wikibase. This is required for migrating an existing Wikibase instance or for recovering from failure. My approach would be to write a script running on the docker host that: creates a local empty file docker-mounts that file in Wikibase container triggers the TTL export script unmounts the file in Wikibase container mounts the file in query service container triggers the process for importing into blazegraph unmounts the file from query service removes the file However I am wondering if that will be enough to get the full benefits of the WDQS, like name autocompletion? Of course if there is an easier way for doing this, like telling the WDQS update service that it should get all changes from the beginning of time just once, I would totally use that. 🙂TASK DETAILhttps://phabricator.wikimedia.org/T197658EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: tk, Aklapper, Addshore, despens, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Gstupp, merbst, LawExplorer, Avner, Gehel, Abbe98, Jonas, FloNight, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197663: Occurrences of localhost in several places in Mediawiki
despens added a comment. I was able to solve Mediawiki redirection problems by adding the public host name a mounted LocalSettings.php in $wgServer. This doesn't solve Apache-level redirects that for example seem to be taking place when requesting https://staging.catalog.rhizome.org/entity/Q3366 The original docker-compose.yml doesn't have a place to put in a public host name. So that it could go into LocalSettings.php and the Apache setup as far as I can see. It would be a great addition being able to configure this.TASK DETAILhttps://phabricator.wikimedia.org/T197663EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Aklapper, Addshore, despens, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T197675: Mediawiki "Fatal exception"
despens closed this task as "Invalid".despens added a comment. Not currently reproducibleTASK DETAILhttps://phabricator.wikimedia.org/T197675EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Addshore, Aklapper, despens, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T197660: Accept arbitrary lines to be appended to deployed LocalSettings.php
despens added a subscriber: Tarrow.despens added a comment. Again, plese excuse the brevity of the original ticket. This is based on a migration use-case executed together with @Tarrow, in which Rhizome's legacy Wikibase data is transferred to the new docker-based setup. This was also to test if the same data could be easily migrated with newer versions of the docker images being released. In general the test was successful! 👍 There was just an issue with mixing existing LocalSettings with the new sensible defaults provided by the docker install. Most things concerning the basic setup of the docker I wouldn't want to touch and it is great that they are provided in such an easy, pre-made form. For customizations to be portable to new releases of the docker image, it might make sense to add a way for the LocalSettings.php file to be appended to (or working with a php based import). These extra lines could just handle non-critical settings like namespace, licensing, logo or naming settings, while the settings required for operation would be handled by the docker compose process. Next week I aim to provide a list of customized settings used in Rhizome's Wikibase and what happens if they're transferred to the docker LocalSettings.php Thank you for linking to your blog post, this is helpful information.TASK DETAILhttps://phabricator.wikimedia.org/T197660EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Tarrow, Addshore, despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Reopened] T197682: URIs returned by Query Service contain docker network name
despens reopened this task as "Stalled".despens added a comment. Is the WIKIBASE_HOST variable used for both communication with Wikibase and the URI prefix? I think that in the frame of this docker compose install, it is unlikely that a user would want to point to another Wikibase host, but might want to just configure the prefix. This seems important when switching from staging to production.TASK DETAILhttps://phabricator.wikimedia.org/T197682EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Addshore, despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197667: Integrate visual editor
despens added a comment. I see the scoping problem, on the other hand, it would be overkill to require two containers for a simple Wikibase deployment in which I am guessing the regular Wiki part would also be used. Given a separate parsoid container would make the configuration of visual editor relatively simple though.TASK DETAILhttps://phabricator.wikimedia.org/T197667EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Addshore, despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197663: Occurrences of localhost in several places in Mediawiki
despens added a comment. Entity-URLs are auto-generated as http://localhost:8181/entity/Q1996 When trying to edit a statement, the Wikibase front-end sends Ajax-Requests to localhost, causing XSS errors visible on the browser JS console, such as Blocked loading mixed active content “http://localhost:8181/w/api.php?action="">TASK DETAILhttps://phabricator.wikimedia.org/T197663EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Addshore, despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197665: Redirecting issues Mediawiki
despens added a comment. Please excuse, my last set of tickets was added during a Wikibase workshop. The deployment I am linking to uses the standard container, a Caddy webserver is proxying HTTP to the exposed container ports. The problem with my Wikibase/Mediawiki is that it is using localhost for any redirects. The URL http://staging.catalog.rhizome.org/ should redirect to http://staging.catalog.rhizome.org/wiki/Main_Page but instead redirects to http://localhost:8181/wiki/Main_Page The template file for LocalSettings.php doesn't provide settings for the base URI and is unclear about if the container is by itself trying to find out the base URI or if this a setting that has to be provided manually.TASK DETAILhttps://phabricator.wikimedia.org/T197665EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Addshore, despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T192800: WDQS could allow discovery of skos:exactMatch links via autocomplete
despens added a comment. During the Berlin workshop it seemed like there was an agreement that every Wikibase should provide a manifest with key information about its properties, see T197588TASK DETAILhttps://phabricator.wikimedia.org/T192800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Multichill, Smalyshev, Daniel_Mietchen, LJ, Andrawaag, Aklapper, Lahi, Gq86, Darkminds3113, SandraF_WMF, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Salgo60, Avner, Culex, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T197682: URIs returned by Query Service contain docker network name
despens updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION[[ https://query.staging.catalog.rhizome.org/#SELECT%20%2a%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3Fperson%20wdt%3AP3%20wd%3AQ6.%0A%7D%0ALIMIT%20100 | Example Query for person ]]TASK DETAILhttps://phabricator.wikimedia.org/T197682EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T197682: URIs returned by Query Service contain docker network name
despens created this task.despens added a project: Wikibase-Containers.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTION[[ https://query.staging.catalog.rhizome.org/#SELECT%20%2a%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3Fperson%20wdt%3AP3%20wd%3AQ6.%0A%7D%0ALIMIT%20100 | Example Query for person ]TASK DETAILhttps://phabricator.wikimedia.org/T197682WORKBOARDhttps://phabricator.wikimedia.org/project/board/3079/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197658: Provide easy script to reset Blazegraph
despens added a comment. At Rhizome we used the following command to reset Blazegraph: curl "http://localhost:/blazegraph/namespace/kb/sparql" --data-urlencode "update=DROP ALL; LOAD ;"TASK DETAILhttps://phabricator.wikimedia.org/T197658EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T197663: Occurrences of localhost in several places in Mediawiki
despens updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...- frontend ajax requests to APIs (Wikibase editor UI) - submitting edit formsTASK DETAILhttps://phabricator.wikimedia.org/T197663EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T197663: Occurrences of localhost in several places in Mediawiki
despens updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...- frontend ajax requests to APIs (Wikibase editor UI)TASK DETAILhttps://phabricator.wikimedia.org/T197663EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T197663: Occurrences of localhost in several places in Mediawiki
despens updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION- entity URIs (see [[ https://staging.catalog.rhizome.org/wiki/Item:Q1996 | example ]]) - frontend ajax requests to APIsTASK DETAILhttps://phabricator.wikimedia.org/T197663EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T197675: Mediawiki "Fatal exception"
despens created this task.despens added a project: Wikibase-Containers.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTIONFatal exception of type "TypeError" appears when debug output is enabled. Example, actually appears on all main namespace pages.TASK DETAILhttps://phabricator.wikimedia.org/T197675WORKBOARDhttps://phabricator.wikimedia.org/project/board/3079/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Aklapper, despens, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T197673: Include LUA / Scribuntu
despens created this task.despens added a project: Wikibase-Containers.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTIONSetup makes sense for WikibaseTASK DETAILhttps://phabricator.wikimedia.org/T197673WORKBOARDhttps://phabricator.wikimedia.org/project/board/3079/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T195990: If a LocalSettings.php file is specified then most ENV vars are not actually needed
despens added a comment. I think it would be good to have most of the LocalSettings.php provided with meaningful conventions and offer a way to append lines for name spaces etc...TASK DETAILhttps://phabricator.wikimedia.org/T195990EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Tarrow, Aklapper, Addshore, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T197667: Integrate visual editor
despens created this task.despens added a project: Wikibase-Containers.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTIONRun VisualEditor extension + parsoid serviceTASK DETAILhttps://phabricator.wikimedia.org/T197667WORKBOARDhttps://phabricator.wikimedia.org/project/board/3079/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T197666: Quickstatements login calling non-existing part in Mediawiki
despens created this task.despens added a project: Wikibase-Containers.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTIONClick on "Log in" on this pageTASK DETAILhttps://phabricator.wikimedia.org/T197666EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T197665: Redirecting issues Mediawiki
despens created this task.despens added a project: Wikibase-Containers.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTIONSee exampleTASK DETAILhttps://phabricator.wikimedia.org/T197665EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T197663: Occurrences of localhost in several places in Mediawiki
despens created this task.despens added a project: Wikibase-Containers.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTION entity URIs (see example) TASK DETAILhttps://phabricator.wikimedia.org/T197663EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T197660: Accept arbitrary lines to be appended to deployed LocalSettings.php
despens created this task.despens added a project: Wikibase-Containers.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTION @despens to provide list of config options derived from migration of catalog.rhizome.org In install/update process, provide way to input for arbitrary LocalSettings.php lines TASK DETAILhttps://phabricator.wikimedia.org/T197660EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T197658: Provide easy script to reset Blazegraph
despens created this task.despens added a project: Wikibase-Containers.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTIONOn migration/import of an existing Wikibase dataset, a method is required to reset the Query Service and re-import the complete RDF corpus.TASK DETAILhttps://phabricator.wikimedia.org/T197658EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: despens, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192795: Supporting a local file/image commons repository instead of Wikimedia commons
despens added a comment. Here are related discussions/issues: https://phabricator.wikimedia.org/T90492 https://www.mediawiki.org/wiki/Topic:Tcavf3pq7asuvp4k I think it would be great if a local Wikibase would respect settings for the local file repository to be used, or using a remote one if configued. Maybe as a later step, the used repository could be selected per Commons-type property, but I think the main benefit right now for a federated instance would be to work with images and other files that don't fit the mission of Wikimedia Commons. Simply using URLs is not great since that would remove all benefits the integration of a file repository would bring, such as resizing, thumbnail view during editing, etc.TASK DETAILhttps://phabricator.wikimedia.org/T192795EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Loz.ross, despensCc: despens, Daniel_Mietchen, LJ, RazShuty, Aklapper, Lahi, Gq86, Andrawaag, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T92669: PropertyPage object doesn't support acess to or modification of a property's claims
despens added a project: MediaWiki-extensions-WikibaseRepository. despens set Security to None. TASK DETAIL https://phabricator.wikimedia.org/T92669 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: pywikipedia-bugs, Aklapper, despens, Wikidata-bugs, jayvdb ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T91439: API returns 'no-external-page' for existing pages with titles that look like a domain name (e.g. "ubermorgen.com" or "delocator.net")
despens added a comment. Apparently, `normalizePageName` in `MediaWikiSite` doesn't follow redirects. `MediaWikiSite` writes this error log: 2015-03-03 23:42:47 catalog wiki: call to returned bad json: Security redirect Security redirect We can't serve non-HTML content from the URL you have requested, because Internet Explorer would interpret it as an incorrect and potentially dangerous content type. Instead, please use https://catalog.rhizome.org/api.php?action=query&prop=info&redirects=1&converttitles=1&format=json&titles=Delocator.net&*";>this URL, which is the same as the URL you have requested, except that "&*" is appended. This prevents Internet Explorer from seeing a bogus file extension. When appending `&:*` to the original API request in `includes/site/MediaWikiSite.php:136`, like this: $url = wfAppendQuery( $this->getFileUrl( 'api.php' ), $args ). '&*'; the request works and `normalizePageName` returns a valid page name. TASK DETAIL https://phabricator.wikimedia.org/T91439 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: despens Cc: pywikipedia-bugs, Aklapper, despens, Wikidata-bugs, jayvdb, Anomie, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T91439: API returns 'no-external-page' for existing pages with titles that look like a domain name (e.g. "ubermorgen.com" or "delocator.net")
despens added a comment.
BTW, the proof that 'Delocator.net' exists as a wiki page:
**GET REQUEST:**
https://catalog.rhizome.org/api.php?action=query&prop=info&redirects=true&converttitles=true&titles=Delocator.net
**RESPONSE:**
{
"warnings": {
"main": {
"*": "Unrecognized parameter: '*'"
},
"query": {
"*": "Formatting of continuation data will be changing soon. To
continue using the current formatting, use the 'rawcontinue' parameter. To
begin using the new format, pass an empty string for 'continue' in the initial
query."
}
},
"query": {
"pages": {
"5558": {
"pageid": 5558,
"ns": 0,
"title": "Delocator.net",
"contentmodel": "wikitext",
"pagelanguage": "en",
"touched": "2015-03-03T19:54:33Z",
"lastrevid": 8675,
"length": 13,
"new": ""
}
}
}
}
TASK DETAIL
https://phabricator.wikimedia.org/T91439
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: despens
Cc: Aklapper, despens, Wikidata-bugs, droid, Anomie, Legoktm
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
