+1

Another problem here is going to be that for instrumentation details, the url of suggestions is https://www.wikidata.org/w/index.php?search=Universe+%28Q1%29

Just wanted to check in on this one given my target deployment date has passed. No urgency from my side, but I'd like to have a clearer idea on when I can expect to schedule this work.

@alexhollender practically all we need here is the incubator logo is here:

500px is the minimum we support right now

The WikimediaEvents extension now hosts this code.

The WikimediaEvents extension now hosts this code.

The WikimediaEvents extension now hosts this code.

I will note there seem to be a lot of issues relating to jquery plugins not being defined that can't easily be explained.
These errors include TypeError: $(...).updateTooltipAccessKeys is not a function , TypeError: $tabContainer.on(...).on(...).collapsibleTabs is not a function, Uncaught TypeError: $.Deferred is not a function as well as this one. In some cases $ is undefined.

In T276368#6884163, @matmarex wrote:

The VisualEditor error is defnitely not "third most frequent", unless the situation with errors has drastically improved since I last looked, because there is a total of 29 hits logged in the last 30 days: "TypeError: $.cookie is not a function" AND setupEditLinks

@ovasileva please note that although web are implied as maintainers, that's never been made explicit and because nobody in the team is familiar with the library, the HTMLFormatter is in the Code-Stewardship-Reviews process: T258964

@Tchanders the mock mediawiki should have that - https://github.com/wikimedia/mw-node-qunit/blob/master/src/mockMediaWiki.js#L87 but it will always return undefined. The components should be agnostic to mw.config. It helps make them reuable (we're planning to move these to wvui eventually where there is no mw object.)

(no instances of the bug today! hurrah!)

LGTM

I can confirm the fix with the current deploy:

@Volker_E @alexhollender please review [[ https://patchdemo.wmflabs.org/wikis/2775c329329f4f769bf679e9576a5efc/wiki/Puerto_Rico

We no longer log errors with an empty stack trace as of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/664306

Not fixed yet. Patch was reverted.

On second thoughts, given we can filter out undefined, I suggest explicitly rewriting any empty strings to undefined and declining this task.

The fix looks like it's working to me, but I was seeing odd behaviour.

I documented alerts here: https://wikitech.wikimedia.org/wiki/Client_errors - perhaps that be expanded with additionals?

Centralnotice admins and interface editors don't have access to Logstash sadly, and the grafana board does not seem all that useful to them - you can't filter by wiki, so errors caused on smallers sites will hardly register.

The remainign subtasks that are open concern the API and I think should be considered separately. I think this ticket should be resolved.

The local description is now being served in https://en.wikipedia.org/w/rest.php/v1/search/title?q=media&limit=1 ("Disambiguation page providing links to topics that could be referred to by the same search term")

All subtasks are resolved.

Can this be resolved @alexhollender and @ovasileva ? It has no open sub tasks.

@alexhollender any views on this one? Can you assign a priority?

Needs priority. If doing this we should do this prior to the language deploy.

Thank you @Sakretsu