In T218921#5055949, @Jdforrester-WMF wrote:

Update: I tried disabling "old style" federation, and it immediately and totally broke (PHP fatal, "No entity source provides properties!").

I believe this would mean "backporting" to the production branch in a SWAT deployment window. Given it's Friday today, this would need to wait until Monday?
@Addshore @Tarrow @Lucas_Werkmeister_WMDE as deployers, could you please assist with this?

In T218825#5041708, @zeljkofilipin wrote:

Caused by 493096?

In T217157#5040396, @Cparle wrote:

When given Q-id or P-id as a search term to beta commons' wbsearchentities API, the API returns search results matching the item/property from beta Wikidata

This won't work, as the local search index doesn't contain wikidata items. We think this is ok, because we can (and do) call wbsearchentities on wikidata directly from commons

For the time being, hard dependency on ULS is fine from Product side. This decision is going to be revisited before using the new termbox on Desktop.

Wikibase might be affected too https://integration.wikimedia.org/ci/job/mwselenium-quibble-docker/10022/console

The ones @Cparle has added to the task description looks pretty good, and for the file page it might be it.
A list of possible further things to check, admittedly often not that end-user-facing ones. I'll let @Cparle and @Ramsey-WMF decide which of these deserve to be promoted to "acceptance criteria", and which are just things to test the verify that all works (tm).

@Reedy: I understand the concern. The extension is under active development of team of four developers, hence the significant commit count. The major part of the extension's functionality is there, and its general structure is considered set, so (arguably of course) ,the extension is ready for the security readiness review.

Final question and just for verification, this ain't going to be exposed directly to the internet after all, right? Rather this will be called by mediawiki, per the architectural diagrams attached to this task.

@Jdforrester-WMF yup.
Those config changes would be rather straightforward, and I am sure you'd be able to cook them yourselves. I've drafted https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/490586 and https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/490587 a while back. I wouldn't object if those were SWAT'ed. If helpful WMDE would try to help with deployment these (verification etc), although as you already know, we're generally only available in those crazy European times

In T218135#5019845, @Bawolff wrote:

Jeroen De Dauw already has 2 failed requests for +2 in mediawiki/core 1 2. Admittedly this was a long time ago, but the last time he did anything non-trivial in MW core was in 2013. I feel like this is sort of a backdoor around previous community consensus.

In T212189#5011311, @akosiaris wrote:

I have to say I am wondering a bit about the latency as the low end seems to be quite high (500ms?). It's your service of course and I am fine with it.

Rock'n'roll!

No, RDF is not working for MediaInfo in general, and hence we (WMDE) suggested to disable it until the RDF mapping is done, and Structured Data on Commons team decides to enable RDF output back.

@akosiaris thanks for listing up information needed by SRE. This is very helpful.
Before I add those to the task description, we'd appreciated you having a look at these (especially SLOs) and advice in case we are somehow off. In particular, given the service is going to be accessed via MediaWiki, its availability is depending on availability of MW. As we don't know what is the uptime of Wikipedia, so please tell us if we're going over board here.

I _guess_ this might be a different manifestation of T214544 ?

Understood, thanks @hashar. We'll be able to ask more precise questions next time.

thanks!

Thanks @Reedy. https://github.com/wikimedia/wikibase-termbox seems empty though.

Shamelessly pinging @Reedy as was recently seen doing similar thing in T216692

This indeed sounds like a good idea @hashar. Filed T217335.

Implementation details (and also complexity) of this story will become more clear once investigation T216720 is done.

Looks it is fixed https://travis-ci.org/wikimedia/mediawiki-extensions-Wikibase/builds/498678262

@Lydia_Pintscher: asking for clarification. The "child ticket" the task description refers to is T216728?

Unstalling as the RFC requested above is now approved! (see: T213318)

With the Last-Call period ended on Feb, 20th 1:00 PM PST, and Technical Comittee having approved the RFC on the same day (per https://lists.wikimedia.org/pipermail/wikitech-l/2019-February/091589.html), I guess this RFC ticket should be marked resolved, or maybe moved to TechCom-RFC (TechCom-Approved) ? I don't know what is the process, please advise. Thanks!

Caused by sloppy work of mine under umbrella of T214557. Not related to the recent beta outage/beta being in read only state.

I don't claim to understand all details on how MediaInfo is implemented, but if I understood the problem, and I were to "fix" it, I would see three steps:

1. Make Special:SetDescriptions and relevant API actions really only work with items and properties (unless already done in all places, description of this task suggests it might not be the case yet).
2. Adjust the code turning the PHP object into JSON object for storage, and the opposite when loading JSON object from the database, so it ignores anything which claims to be a description. E.g. skip "descriptions" key etc. This would prevent storing any "description" data even if it somehow made up to the storage layer, and also unexpected leaking of incorrect data should it be already stored in historical revisions etc.
3. Adjust the code turning the loaded the PHP object for JSON output, e.g. in API results. This code should be able to control what data is used for presentation, e.g. what "elements" of the MediaInfo object to display. This would prevent exposing any "descriptions" even if they for whatever reason ended up to be stored in the database.

I take this one on. Per the internal discussion with @Addshore and @Lydia_Pintscher the other day, it seems reasonable to actually turn off RDF output for MediaInfo entities for now, as it is not really defined. Doing it from the start has apparently slipped our attention, so I am going to do it now.

We do not intend to maintain the "proper" UI logic in PHP. SSR service will render the page on the server side which will (via MediaWiki etc) make it to reader's browser. We do want Wikidata readers and editors have an access to data even if they decide to disable JS in their browser, hence the request for this service.

Can we make it an explicit requirement?

Much appreciated @JAllemandou !

Apologies @Smalyshev for super late reply. We've got snowed under with some urgent Structured Data on Commons work.

I had a quick chat with @Addshore, and I'll try to point to WMF teams we believe are the best suited to provide information on those topics, the particular team member who is to our knowledge the best suited/approachable (e.g. based in Europe) in the particular topic area, and also IRC channels where teams in questions are generally present. This if of course does not mean IRC is the only way to get answers, and the mentioned individuals are the ones you must be in contact with.
Email addresses of WMF staff can be found through the staff page https://wikimediafoundation.org/role/staff-contractors/

back on green https://travis-ci.org/wikimedia/mediawiki-extensions-Wikibase/builds/492233987 thanks!

@Smalyshev I believe the approach we are suggesting really makes a difference when thinking beyond just rendering a template for a particular part of an Item page. I can definitely be blamed for not making it clear enough in the description of this task that we are NOT intending to build the template renderer, but the UI application which determines what data to load (from what APIs), what actions (APIs) to call etc, and also what to render. Also, it should be noted the ultimate goal of ours is not to just change the way this particular element of the item page (i.e. the "termbox") is handled in the Wikibase front end code, but it is about the Wikibase front end as a whole, with termbox being the first step only.

Regarding the Structured Data on Commons topic: as per what's been stated in the last point of the "Solution proposal", we intend to move the whole of Wikibase entity page UI towards the new architecture. So that would include statement part of the item and property pages.
We want to stop using the old front end code and infrastructure, and finally, stop maintaining it/delete it. With how the current SDC UI is built, as @Cparle states, using the some "components" from the old Wikibase UI code this would indeed mean changes required to the SDC part as well.
There is no intention to drop the old UI "framework" over night of course. It will only happen once all relevant uses are moved to the new architecture, starting with the complete item and property page. This is definitely not going to happen in 2019.
We are quite convinced that once item pages have switched fully to the Single Patch Application approach, transition for other users should be easier. The server side renderer service would be there, handling what is required by non-item-page cases (e.g. statements).

@Lea_WMDE closing this one. Please re-open if it was not expected to be closed.