I think we can rephrase this issue. In the particular example given the REST endpoint does return a valid response. It just happens that the page contains no text and the text snippet reported by the endpoint is an empty string because of this. But there is a thumbnail. This could be shown as a normal page preview popup – just with no text. Instead the code throws the thumbnail away and continues as if the REST query failed.

The issue appears to be related to collapsible descriptions. It does not only block double and tripple clicks, but also single clicks. A single click should put the focus in the input field. I found a float: left in the code that appears to be misplaced. Probably a now unused fragment from the old design. When I remove this it works as it should.

Not specific to Advanced-Search but a generic MediaWiki issue.

Working as intended. As discussed in story time this week.

This appears to be a bug in the Leaflet library. Specifically here: https://github.com/Leaflet/Leaflet/blob/main/src/map/Map.js#L343. For some reason this._mapPane is not yet set, or already deleted. We do have a few calls to Map.remove() in our code that might be related to this issue, but I can't see an obvious problem with that.

For future reference, @Andrew-WMDE wrote:

[…] chat about the Wikibase REST API […]. It along with other APIs are supposed to replace commonly used queries in order to reduce the load on the WDQS. However, it's still in an early experimental phase without any concrete timeline on when it will be production ready. This means we also don't yet know what SLO to expect when it is deployed. Additionally, for our GeoPoints use case, we would have to implement the appropriate routes ourselves.
Looking back at the notes from our meeting with [WMF]. I think we should be able to continue using WDQS, as long as we're happy with an SLO of 95% and we don't cause any cascading failures.

I had a look and the reason is indeed that the ApiQueryImageInfo module refuses to work with images that are reported to be 0 pixels wide. There is not much we can do about this from here, I'm afraid. FileImporter can't import images it doesn't know anything about. Just ignoring such an error and processing files that are known to be broken is something we decided FileImporter should not do.

@WMDE-Fisch, you created this ticket once. Can you check if the patch solves it sufficiently and close it?

As argued above this is a hard problem. A general solution that works with all Wikimedia languages would require an entirely new sub-system in the FileImporter codebase. More specialized community-maintained solutions exist.

Sorry, but this is all working as intended.

• The extra : is needed to disable the magic behavior of interlanguage links and such. Technically it might be possible to differentiate and skip the : sometimes. But that's not as easy as it might sound – for not much benefit. Still patch-welcome if somebody wants to work on this.
• For the same reason the "two-hop" w:de: is done. There is technically no guarantee that de: points to Wikipedia and not, for example, the German Wikisource. Keep in mind that FileImporter is designed to run on other wikis as well, not only on Commons.
• Manipulating the wikitext further by adding | is not necessary to make the link work. Doing so would also hide the fact that the link points to another wiki.

Wikidata is not owned by Search. Please try to be more careful.

Wikidata is not owned by Search. Please try to be more careful.

I can still reproduce this issue. patch-welcome is meant to invites volunteers, isn't it? I think this makes sense in this particular case.

Wikidata is not owned by Search. Please try to be more careful.

Wikidata is not owned by Search. Please try to be more careful.

To me this looks like a legitimate feature request that can as well be solved by people outside of WMF.

@MPhamWMF, please don't close tickets that haven't been created by your team just because they appear on one of your team's boards. This alone doesn't make them invalid. You can remove them from your board or move them to e.g. an "out of scope" column that reflects your team's current decision.

Strange. It seems to work for me.

Architecture diagrams are in https://phabricator.wikimedia.org/diffusion/MSKA/browse/master/docs/diagrams/output/ if you are curious.

Linking between Wikidata and OSM happens both ways: It's possibly to annotate relations (as well as other things, e.g. ways) on OSM with Wikidata ids. And it's possible to add an OSM property to the item on Wikidata. The later was missing. I just added it to https://www.wikidata.org/wiki/Q1789012. But this was probably not what fixed the issue. What we have here is more likely the same issue as described in T312913.

I can confirm that the last example is because of the same "random failure". When I add a dummy parameter to the end of https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q35333853 I sometimes get the data, sometimes empty GeoJSON as shown above, and sometimes a 404.

The object on OSM is not a relation but a way: https://www.openstreetmap.org/way/275631579. As far as I know these are not supported everywhere for a reason: The id of a way can change any time. The only half-stable identifiers that exist on OSM are relations.

I can fix the undefined error. But I'm afraid I don't understand what code change is responsible for blocking the buttons and how to fix this. Should we revert the OOUI update for now? The relevant code is probably https://phabricator.wikimedia.org/diffusion/EVED/browse/master/modules/ve-mw/ui/dialogs/ve.ui.MWTemplateDialog.js$40. This was written in 2014 and never touched by the WMDE team, as far as I can see.

I was playing around with this URL:

• https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q316012 currently returns the expected GeoJSON form me.
• https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q316012&foo=1 does the same.
• https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q316012&foo=4 returns a 404 and says "Cannot GET /geoline". This doesn't make sense.
• When I continue increasing the number I randomly get 404s for some. I don't see a pattern. Trying to reload a failing URL never fixes it. But increasing the number typically does.
• I also have seen empty results like {"type":"FeatureCollection","features":[]} but currently can't reproduce this any more.