Understandable. Some of the minified code in question seems to come directly from Vega based on the presence of copyright strings and declatations in a similar order.

I don't quite understand this bit - isn't it just a variable that you can set regardless of the amount Graph extension being installed (i.e. they just reused the variable for something else):
I could not try the $wgGraphAllowedDomainssetting as this require the Graphextension and we recently had it removed

Another is using the following regex to replace "regex1" to avoid the _need_ to use EXTRA in schemas used for form generation:
<([^/<>]+)>(?:\s+EXTRA\s+.*?)?\s*\w*\s*\{(.+?)

One idea floated is to remove "wd" from this line so that any prefix ending t: may be used in a schema to identify a direct property reference, not just wdt:. This would reduce the need for a "Cradle-compatible" schema (vs. original prefixes which plays into e.g. T335448 for custom prefixes (e.g. sdct: for Structured Data on Commons).

Is there a test that should have caught this? "Making and querying an item/property/lexeme on the attached WDQS instance" sounds like something that should be a thing (and could be expanded to other things like federated queries, possibly).

T244847 has background on why there is a desire to do this. For Wikidata there is an endpoint setup but there is nothing similar for Wikibase.cloud, users have to set up their own container and configure it appropriately for their Cloud instance (a level of complexity similar to that of using Suite rather than Cloud). There are semi-regular requests for assistance doing so in the Wikibase Telegram channels.

Well, that aspect is more a matter of work for the user; it looks like most of the parameters could just be entity IDs that are passed through - are they all actually required for core functionality or does it just not do those left unspecified?

In fairness the contact page links to cloud resources, while the other two are about Wikibase as a software project.

The latest patch set seems to resolve the above issue.

The proposed change restores the examples, but not the section headers. I've marked the section in question in Gerrit, but here's screenshots to illustrate.

I think this broke the WDQS example list, which has gnarly JS to extract titles from headers as linked in the above issue. (A patch now exists for this.)

I believe this may have broken due to T365736, in relation to the code to find the previous header. The code will need to be adapted to accommodate the new header markup.

Yes, they can be, but the issue was left open on the WBStack repo because there were unresolved questions related to the limitations caused by the lack of certain rights. I've retitled it and updated outdated links from the imported comments.

WikiScholar Query Service (WSQS)? 🐙
WikiCite Query Service (WCQS)? 📖
Scholarly Query Service (SQS)? 📘

Sorry, I didn't see this - here is an updated query. The base URL had changed, and Wikibase.cloud also uses HTTPS rather than HTTP for its concept URIs.

For what it's worth, when I was setting up the São Paulo cache with Oracle Cloud for Inkbunny, I found some ISPs used undersea cables along the western seaboard to NA rather than running through the jungle to SP; the catchment I came up by pinging addresses in IPs listed as being in certain towns from different ISPs was (2,-27),(-90,-75) lat/long, i.e. (2,-75) as the top-left coordinate.

It may be a good idea to test a brief federated query for an endpoint from each domain after doing this, to ensure that they haven't specifically whitelisted Wikidata.

Opened #305 in pupa/readme_renderer for this issue. If that doesn't work out, maybe a separate <link> in postorius, somewhat like RealMe is able to do for MW?

It actually looks like it is upstream of that. The commit adding markdown support shows that markdown_value list.settings.info is called, which in turn calls markdown.render from the readme_renderer module.

Wikibase Community UG proposed something rather like this for the recent Open Call: Integrating form-based entity creation using Shape Expressions into the Wikibase UI.

Thanks for the quick fix for federation; one of the users reporting the issue says it is all good now, if anyone else still has issues I'll suggest they file a separate issue. 👍

FWIW, in Telegram we have had a report that federated queries to Wikidata are no longer working.

Thanks for the clarification. We're still at the stage of figuring out exactly what to propose, though we have some ideas - it helps to have that guidance, so that if we find e.g. wbparsevalue is needed to validate data type values but has no REST equivalent yet, we can still use it

Is there a rough timeline for when v2 is to launch? There's an open call for development against the REST API (at least, such projects seem to be favoured) and the Wikibase Community User Group (along with others) are considering applying for development grants, but we don't want to commit to implementing a tool before Christmas if the API won't even be available by then.

Per commit for T114098:

* $wgUseInstantCommons now hotlinks Commons images by default instead of downloading originals and thumbnailing them locally. This allows wikis to save on CPU and bandwidth while reducing time to first byte for pages, even without a thumbnail handler. See $wgForeignFileRepos documentation for tweaks.

I guess you mean XSS? You can't load JS since you don't have access to edit site or user JS, even as local admin. You do have the power to edit CSS, but regular users don't. There is no Content Security Policy set that I can see (perhaps if there were, it wouldn't be such a big deal to enable JS), or at least if it does it is not using an img-src or default-src that would prevent image loading. It's up to the editor to warrant that the linked image will always be the right one.

I had a feeling that might be the case. As noted, some existing Wikibases can't be done without upload. But many of those cases would want to use suite or source.

So technically it should be a goal to make the containers independent of each other. Still, I would not officially support or advertise this in order to keep it simple for us now. Is this a requirement our users have?

From a user perspective, I may wish to use low-cost (or free-tier) hosting for peripheral elements like QS, Cradle, WDQS UI and perhaps even WDQS and its updater, as these are likely to be used only intermittently, and with an anticipated low volume of edits. Think Cloud Run, App Service, etc. This also lowers the attack surface on our dedicated servers. As such it'd be a "nice to have" for these to [continue to] be minimally linked and usable between datacenters, without a commitment to fully support with examples, etc.

Desires related to T312131.

We've been getting reports of Wikibase community WDQS end-users having trouble using whitelist.txt - might the changes in T343856 have broken use of this file if they had it incorporated into a Wikibase docker/suite setup? It looks like wmde.16 version of wikibase-release-pipeline is still using whitelist.txt.

Fair enough. I appreciate how frustrating such reports can be, and even if core unofficially works on 7.x for a time, extensions may not. Conversely, it seems most extension compatibility issues are fixed now, for 8.1 at least.

From an external user perspective, it'd be nice to have a config flag to override that check, or a stiff warning rather than an outright error, though I can understand why not.

Due to historical spam, many cloud instances are likely to require confirmation to create an account, presenting a greater-than-usual barrier to dismissing the notice if $wgDismissableSiteNoticeForAnons is not true.

are we happy with it going into every person's wiki? bit intrusive but also we're hosting the wiki for them

As with T285291, it seems like this might be resolved, unless there are further subtasks or testing to perform.

Is this resolved now, since all subtasks are resolved, or is it lacking defined subtasks for some of the proposed features? The owning account is disabled.

The front page still has issues on mobile vertically as when you are logged in the top right text links are inaccessible. You can actually still get to the dashboard via the "try it out" button but this is non-obvious. Once in, dashboard/options appears much improved from when the issue was filed, although the screenshots are not shown here.

Perhaps this would also show image thumbnails for Wikimedia Commons file references in entities, like Wikidata? (If not, that would be a good feature to import, as it has been requested.)

I think this is resolved as https://furry.wikibase.cloud/wiki/Special:Statistics correctly shows one active user. If that info is stale it could perhaps be addressed in a separate task. The information might actually be useful for the Discovery feature as an additional sort criteria.

Related to T356397 (add Gadgets extension, discussion of user scripts/CSS).

See also the somewhat-related T343686. Site JS/CSS is covered in T310787 and (more generally) T356397.

This is essentially the same as T312908 which was created later than the GitHub issue this comes from.

For the record, I've seen several users coming from Wikidata interested in this over the past year.

I think WDQS is wrong here. Per RFC3986, section 3.4:

query       = *( pchar / "/" / "?" )

Perhaps you need the PHP intl extension to be installed in the QS container, as that function seems to require it.

What I was getting at is that it might be fairly easy to write our own script to turn an image URL in a statement into an image tag with JS. In fact I think this might be how Kartographer handles embedded map previews, though I could be misremembering.

According to its extension page, Wikibase Local Media has been in the "suite" bundled releases since 1.35. There would be no real benefit to an off button since you could just turn off uploads instead.

Bullseye (released August 2021) was "a LTS version" of Debian upon the release of MW 1.39 in the same sense as Ubuntu LTS (released every two years), i.e. it has a long lifetime of security updates; it is just not usually called LTS until it moves into "LTS" support status.

The ingest rate appears to be very fast. I wonder if it could be adding items so fast that the WDQS updater can't read them before they scroll off recent changes (which, last I heard, is still the way it figured out what new items it needs to review for its own processing)?

Specifically T111231 exists for the purpose of adding popups summaries for Wikibase and in an ideal world would have been implemented, but without it items and properties will at least show a label and description which is better than now. (Lexemes and EntitySchema lack this.)

Regarding "why the behaviour stopped", we discovered that Special:CreateAccount was not being disabled which was fixed in January.

reCAPTCHA Enterprise purports to offer more, but I get a sneaking feeling it might also be a way to track users now Google's been told it can't do it through other means, especially if you add it to other pages like they want.

The desire to create lexemes via QuickStatements was raised by a FactGrid user in the Wikibase Community User Group mailing list.

If it says greenreaper under that first black box then I don't recall marking any mail as spam from Wikibase.cloud, though it's possible I did, and if so that might explain things.

Was this specifically with a hotmail.com or outlook.com email address? I was later able to reconfirm via changing my address to Gmail, at which point I got an email to that account, "Wikibase World email address confirmation".

It appears so. There are ~50 spam requests in the last day. Many of them are marked as having confirmed email addresses. In total there were 1751 in the last month (showing as open requests), which suggests the rate has not changed recently.

wd: and wdt: default to Wikidata on Wikibase Cloud, as far as WDQS backend is concerned. You can override it by manually setting endpoints, but that is what it is set to. The autocomplete used to be Wikidata too, but was changed, making it easier for those who override those prefixes, but compounding the problem for those who don't.

Related GitHub issue.

FWIW, I have previously started using the dashboard and I think it looked like I was logged in, showing a list of wikis, but when I clicked the settings cog for the desired wikibase I suddenly found I was not.

If Wikibase.cloud does not wish to host images itself, some users might be served by being able to reference images from a foreign file repo via API, which could perhaps reduce licencing concerns. Others will desire local hosting, though.

A related ticket for WBStack regarding Gadgets to which I added some comments about the need for user scripts: T356397

$wgJobRunRate = 2 due to a previous instance of this issue (now seemingly lost due to repo change), but as noted there that is probably not a sufficient approach to handle mass import in a timely manner as the expectation is that data is available immediately, and an unlisted wikibase may not be accessed "regularly" at all (not sure API counts, and even if it does it may never catch up if n+1 jobs are queued per request).

Most or all requests of this kind seem to (so far) have wanted to enable sitelinks specifically for the local site.

Looks like it's a bit late (the end of January was rather busy) but if memory is the most important thing, n2d (AMD Rome/Milan) instances appear to be ~13% cheaper and might be worth considering in the future, depending on whether you're CPU-bound and how well ES performs.

Might there be any benefit from cloning (ES 7.4+, so maybe MW 1.39+) a default index per MediaWiki release used by Wikibase.cloud, rather than generate a new one for each instance, which might presumably create a lot of duplicate content if default messages are indexed?

This issue appears to have been resolved in that the account creation has been prohibited and no new accounts have been created since the afternoon of December 12.

Even if it is not enabled in general, importing from an XML file to start with could be good as there's less risk of conflict.

Not directly linked but potentially also an issue to bear in mind: per T168783, the captcha used on Special:RequestAccount may not be verified until 1.40+ (unless you use the updated version in master, which the extension page suggests is not compatible).

It seems Special:CreateAccount is still enabled even though the link at the top right is to Special:RequestAccount. Obviously, bots don't click the link, they just go to the relevant page (or use the createaccount API).

One thing seemingly missing without Cirrus support is case-insensitive autocomplete (T242644), which can be an issue for usability, judging by how it has started to come up on Telegram (as it has for standalone Wikibase installs).

The readme just says:

A local whitelist can be maintained by creating a [[MediaWiki:Spam-whitelist]] page and listing hostnames in it, using the same format as the blacklists. URLs matching the whitelist will be ignored locally.

There doesn't seem to be the concept of using a file/URI in the same way as the blacklist. The whitelist regexes are stored with a particular cache key, so maybe it would be possible to hackily poke it into the cache? It might overwrite or be overwritten by the regexes in the message, though (even if they're nothing).