Here is a concrete example of people gaming the system using extra spaces.

My screen is 2560px, its just I like a big font sometimes! The rendering
engine's judgement of space works for me, so I'd b wary of hard-coding
limits

Screenshots at high zoom, before and after clicking search icon. Expected behaviour, search box visible before, text entry available under mouse after

It needs to have an entry box for high zoom levels. Zoomed out, It seems sized for the dropdown+box combination from the start, with a much bigger search box than before. Either it should always show the dropdown, or it should start smaller. I found it a distraction that I'd clicked in the box, it magically redrew with the actual input box jumping 2 inches to the right. Could the dropdown be positioned after the entry box to avoid this?

Not sure Phabricator is the best place for a WD usability discussion. I'm not keen on having to click on the search icon for the entry box to appear. I'd rather have both visible. No problem having the dropdown appear rather Special:Search when the icon is clicked. How does this meet accessibility standards?

Displaytitle not appearing in search has forced my wiki, where the page names are wikidata Qnumbers, to have vast numbers of REDIRECT pages. I'm frustrated that changing this is such low priority

I think the relevant line is skins/Foreground/includes/ForegroundTemplate.php line 141

Rather than just use P31, could we create a description template property that could be used to create the description. If missing the P31 value would be used, if present, then the template of Q5 might be of the form "P27/P1549 P106 (P589 - P569)" and would generate "Indian cricketer (1935-1984)"

Hopefully the answer to https://www.wikidata.org/wiki/Wikidata:Request_a_query#clarifying_mul_usage can be used to write documentation

Neither https://www.wikidata.org/wiki/Wikidata:SPARQL_tutorial nor https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/A_gentle_introduction_to_the_Wikidata_Query_Service mention mul, and I can't where its made clear that

You also need to address the issues raised at https://www.wikidata.org/wiki/Help_talk:Default_values_for_labels_and_aliases#SPARQL_querying, and especially the 3 line FILTER problem

https://www.mediawiki.org/wiki/Special:ExtensionDistributor?extdistname=HitCounters&extdistversion=REL1_39 and this time the patch is applied. No idea why it didn't 20 minutes ago when I did the same thing. And the Popular page now works, its just that running the composer lines must have triggered a problem elsewhere. I don't understand or like composer, perhaps I'll try installing this extension first and layer the other stuff using composer on to it.

Thanks for helping out. I can confirm it was e759c39, I chose the autodownload option from wikimedia, and chose 1.39, and got HitCounters-REL1_39-e759c39.tar.gz with a filesize of 96858 and md5sum of fd407935fa0aa25401b831faa3060314

I found the wikimedia SPARQL service, and came up with

Looking into this more, it looks like Date is a wooly free format text that is only accessible by the hugely verbose https://commons.wikimedia.org/w/api.php?action=query&format=json&formatversion=2&generator=categorymembers&gcmtitle=Category:Deal_Castle&gcmnamespace=6&gcmlimit=500&prop=cirrusdoc

On further investigation, it turned out to be a problem with FULLPATH. As https://www.mediawiki.org/wiki/Help:Magic_words says

Tried mediawiki-extensions-ExternalData-3.0, same problem

I found the maintenance script importImages.php more suitable for my needs, as it handled old and new wiki metadata better, so I've not returned to the pywikibot script which feels more clumsy

When I ran software ticket systems, I found it best to let the problem reporter to update the ticket before marking it closed.

python -V
Python 2.7.17
oldwiki and newwiki are 1.35.0