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, so it helps to have that guidance.

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 a local admin. 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 Wikibasea can't be done without upload. But many of those cases would want to use suite or source anyway.

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: https://github.com/wbstack/mediawiki/issues/47

$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).

This doesn't seem to be anything to do with Wikidata now, but rather third-party installations not using a suite install including Cirrus (which just came up in Telegram for the case-sensitive search issue).

Could be as simple as putting tinyurl\.com into the default MediaWiki:Spam-whitelist. That's what I did. (I don't know how simple this actually is.)

Perhaps related to T301249/T305785 and stuff like DataModel\Entity: Add __serialize/__unserialize for EntityIds? Looks like it landed after the branch split and involves changes in serialisation for PHP 7.4 that impact reference hashes (as noted in T167759 and @Lucas_Werkmeister_WMDE's review comments).

From a user perspective, I think this is the wrong way around. They are Wikibase extensions. I would see it as a bug in the respective extension if it was released for a given version that had Federated Properties v2 enabled but did not correctly handle that feature.

Even if you only get one spam email a day, it basically means you are quite likely to get two emails about it rather than one about it, which is not ideal. It might make more sense if it was possible to set it to a weekly or monthly timeout, because you might have missed a single mail in that period.

As much as mailing list administration is fun. :-)
Thanks a lot for the prompt assistance!

Thank you. My address is included in the original post at the end of the first paragraph. It's available elsewhere, and gets enough spam as it is, so I'm not that concerned about more. ^^

In T272500#8311593, @pfischer wrote:

@GreenReaper, I removed the restrictions.

In T272500#8306753, @pfischer wrote:

Hi! I managed to build the whole chain of images down to buster-php74-fpm using docker-pkg, see instructions.

My own view: it's a bad idea to use wd:, wdt: etc. for things that are not Wikidata. Yes, they are stated to be "internal to Wikidata", and therefore could be internal to your own wiki. But practically, it is likely to be a source of confusion, especially if people try to do federated queries or otherwise interact with Wikidata.

As noted in Telegram, I believe this may be linked to the use of CloudFlare's Rocket Loader. It would be helpful to know if the issue goes away if disabled by a page rule (or globally for a domain). It may be necessary to add data-cfasync="false" before the 'src' attribute of any impacted script tags including dependencies if they are causing issues.

As a user, I think it makes sense to turn it disabled while it is being submitted, so that I don't accidentally double-submit the form by double-clicking or input bounce. I don't know if doing so would result in a second email and if that would invalidate the first email sent, but if so that would be bad because if the user then opened the first email, the reset would then "not work". It also indicates to the user that the input has been accepted by the browser.

It's probably not worth it for a secondary feature, especially when it adds bytes to every page. IE 9 and 10 are roughly 0.07% of browser usage; on one of my own sites I see just 20 visits out of 986,000 using IE 9, while IE 10 does not show up (IE 11 was 1,182 - still just 0.1%).

Adding the whole of wikibase.cloud (as this task's title suggests) would be cool, and was discussed in the Telegram chat for Wikibase.cloud, but will require a wildcard, which I'm not sure is possible yet - there are none in the current list. But perhaps the intent is solely to add OpenDataSweden?

In T207705#8091791, @Jheald wrote:

I believe an exception should be made for a pair of functions to return as an xsd:dateTime the minimum and the maximum date that a given edtf:EDTF value could represent (similar to equivalent functionality found in edtf.js,and I think also a number of other edtf implementations). This would allow the results of a query outputting an edtf:EDTF value to be easily ORDERed, by the earliest possible date, or the latest possible date, or perhaps the midpoint of the two...

As for 502s, I'd be curious too (though I have not personally done enough edits since migration to experience them) but perhaps it was due to bot indexing and fixed by the response as mentioned in T308340? If it is a resource issue then quota issues mentioned in T305679 may need to be addressed if that has not already been done.

If you look at the URl you can see that this is a login page, which should not be accessed by indexing bots. The problem is you have no robots.txt file to prevent this. Without this significant resources will be wasted by such requests (of which a login page is one of the cheapest).

The HTTPS concept URI was covered in T299045 and T301141. T301258 was meant to cover pros and cons, but it was closed as invalid. I suspect they didn't want to get in a situation where they expanded the service using HTTP (which might feasibly result in more people accessing the site using HTTP, which exposes data to the network) and it took a while to fix like in T258590 for Commons or T226453 and T153563 for Wikidata itself (which in the end has not been switched) - or in T303777 for Wikimedia Enterprise where they have actually moved some stuff from HTTPS to HTTP.

sharedCacheKey* seem to be documented here, although there might be other appropriate locations, e.g. a hint on the MediaWiki wiki.