If I'm understanding it correctly, this is a natural consequence of the fix for T280226. If this is considered as a security issue, Special:Purge should be made consistent with the API by restricting both to non-blocked users. If it's understood just a way to handle malfunctioning bots, then it's probably fine to have variant behavior, as glitchy bots aren't going to be using Special:Purge.
Fri, Sep 17
Sun, Aug 29
Wed, Aug 25
Aug 14 2021
Huh, that's weird; it's started working for me as well. Maybe I just forgot to clear my cache after uploading a new version?
Aug 8 2021
Jul 3 2021
It's been two days and I'm getting the same error when trying to add dag:Finland to Q33 (and I am autoconfirmed; it's not the protection)
May 9 2021
Apr 22 2021
This sounds like list-defined references, which are an existing feature that are relatively close to LaTeX's format of having a short identifier followed by the full text at the end.
Apr 17 2021
I can reproduce all these with Zotero 5.0.96; likely a different version than Wikimedia has deployed, but probably an upstream issue.
Feb 4 2021
I think this may be primarily Google's problem, but I'll also note that this doesn't seem to be exclusive to the mobile site; see this enwiki VPT section for another instance of a page with NOINDEX and in robots.txt appearing in Google search results.
Jan 26 2021
Jan 22 2021
I just opened https://github.com/zotero/translators/pull/2326 upstream, which should take care of the problem.
Nov 10 2020
Aug 14 2020
Category:Past proposed deletion candidates has talk pages of articles that survived proposed deletion. For getting articles that were actually deleted, it should suffice to go through the deletion log looking for PROD or a link to Wikipedia:Proposed deletion.
Jul 29 2020
I have run into what seems to be the same problem. To reproduce with the first example on the ZoomViewer docs, when I open this image I get the exact error above ("No response from server iipsrv.fcgi"). This happens with every image I have tried. I'm using Firefox 78 on Fedora 31.
May 14 2020
Jan 9 2020
It's consistently working for me now. Thanks!
Dec 18 2019
After some experimentation, I found that this query fails while this query works. The only difference is the order of the URL parameters (in the first, the empty subject is at the beginning, while in the second, it's at the end). No idea what would cause that to matter, though.