I've done some investigating and taking File:A Warm Shade of Ivory - Henry Mancini album cover.jpg it has 3 old versions that all have return errors, however if you change the name part of the filename to the new name they are valid. So it appears that the files were renamed but presumably the update to the database was not updated. So

Another popped up https://en.wikipedia.org/wiki/File:Evening_with_Belafone_Mouskouri_album_cover.jpg - Again it was a move on 22 May 2026 by Liandrei

I noticed these are all files that were moved and all moved my the same editor, but it may be moved in a certain time period rather than just that editor. I have been unable to find any other file moves with old versions moved in the same time period by other editors to clarify.

A similar problem happened not long ago in T423065

Sorry your correct. It appears that accessing the collection thought the library page (https://wikipedialibrary.wmflabs.org/partners/93/) must set a cookie or something that works cross domains (oup.com and oclc.org). After going to that login I can then access the non wikipedialibrary link https://academic.oup.com/edited-volume/28133/chapter/212357184 on the same browser, but on another browser where I still get no access.

That resource is open access that you do not need a login for (https://academic.oup.com/edited-volume/28133/chapter/212357184)

I believe this is related to T423065

Sorry I did not notice the "Click preview" in the original report above. No I 'm getting this just trying to save/publish. Also the original report on Discord does not say preview either.

Sorry I have not been well so I'm not very sure how long this has been going on, but definitely this weekend (last 3 days I think) as I was processing issues reported on some pages and fixing one by one then after completing ten issues saving after 5-15minutes and getting this loss of session error message. I've only got this when I've been editing both one article for multiple minutes and also doing multiple other edits/admin actions on other pages in the mean time.

I have also just noticed that files where I deleted old revisions, such as https://en.wikipedia.org/wiki/File:SuccessKid.jpg, the old versions do not show "No thumbnail" but links with alt text. In this case it shows "Thumbnail for version as of 04:23, 26 April 2015" and a link to https://upload.wikimedia.org/wikipedia/en/archive/f/ff/20260405164800%21SuccessKid.jpg but for that link I get "File not found: /v1/AUTH_mw/wikipedia-en-local-public.ff/archive/f/ff/20260405164800%21SuccessKid.jpg"

I have just had the same thing happen at https://en.wikipedia.org/wiki/File:Genie_immediately_after_rescue.jpg

In T419426#11689939, @Alien333 wrote:

Fixed.

Ah I guess I've always been a NPP when I did it!. Doh! just realised as you do it though the Curation Toolbar the non NPPers would not have - Sorry ignore me, brain not working today. Not sure how has this not been noticed before, as un-patrolling or not has come up several times at WT:AFC.

"and there is no way to revert this, even if you want a second opinion" - really has something changed recently as I have unpatrolled a few in the past, the last being https://en.wikipedia.org/wiki/O%27Bajan which I accepted and un-reviewed.

on en.wiki typical edit summaries would include "copyvio", "copy-vio", "copy vio", "copyright violation", "cv" (but "cv" is ambiguous as also could be referring to "Curriculum Vitae" - but "cv" and a url is probably a hit), also all can be pluralised (+s) and G12

This has also been happening on enwiki for the last few weeks affecting about the top 120+ high count editors.

I was replying to the comment made before that was someone saying they were having issues opening the dev tools on a Mac.... they deleted the comment.. Not sure how I managed to respond to the wrong one. sorry for the confusion

It wasn't intermittent for me and it started earlier than the ticket (can't remember when). I had no success for days.

I am truly hoping this is not because of an exploitable bug in the Newspapers.com backend because that would concern me an awful lot.

The cookie just identifies your user and the token keep you logged in for a while. It's normal for many websites and why you should keep your cookies secret and always use https. Basically this work-around is copying the access your account legitimately has, you are just using your front door key on the Wikipedia side door.

I can search and can view some results but others show a page with "We're having technical difficulties"

In T322916#9895850, @Oona_Wikiwalker wrote:

@KylieTastic , are you trying to log in to Newspapers.com through Ancestry.com?

@Oona_Wikiwalker, I'm not currently having any issues viewing and clipping via the integration so see this clip. Oddly, when I try to view the oclc integrated version of the clip i.e. this one I get "This page is not available This page is pending publication, has been removed or moved to a new location". (While I was there... clip 2 clip 3)

In T365374#9886036, @Liz wrote:

Some of my queries are running okay now, others are just spinning their wheels, like they are running but they never conclude or take an unusual length of time to do so. So, a partial fix. And with one query, I get an error message

"Unknown column 'pl_title' in 'field list'"

which might mean that there is suddenly a code problem for some reason.

I've always thought it was reFill.

I just tested my Quarry queries that were failing or taking hours when I last tested 3 hours ago and now all complete sub minute as expected. Also https://xtools.wmcloud.org/ec is now back working.

Note that those are just on the reFill results - if you preview/save they are not added.

Closing as not the issue

Thanks @Umherirrender I just did a test run using api.php and forcelinkupdate and yes it appears to work fine. So something else wrong with the bots or rate limits. So happy for this to be closed as a non issue.

I had also noticed over the last few days and mentioned here on EN WP - Examples: here, this and this.

Not sure if this is related or a new separate issue but I'm now noticing edits that remove all the white-space including newlines that makes determining what has been changed very difficult. This makes editing after with the source editor awful, but more importantly makes vandalism detection much harder.

Hi Ozzie10aaaa, I just looked at https://xtools.wmflabs.org/articleinfo/en.wikipedia.org/Dyslexia and I see you as rank 2 by number of edits, and 5th by bytes added, so I assume you just mean the "Top 10 by added text" pie-chart that does appear to be showing differnt data. The pie chart appears to be showing the edits without the caveat 2 on the table, so editors like the anon 67.68.57.35 who do 1 edit of 242,636 bytes is top of that one. It would seam reasonable it should show the same as the table.

Yup, I was just about to comment it was the same. I know wit says "Namespace Main" but maybe to stop confusion it should be show on the big title i..e "Automated Edits (Main Only)" or "Automated Edits (Main Namespace)" as the other selection criteria (Name and language) are show in the header lines. Just a thought.

Hmm, I would not think to go to "Automated Edits" to see the "Non-automated edits" as it seam s counter intuitive. I guess it depends what tool your considering, but I would most want to look at peoples automated edits to check out concerns or interests with those edits. If your looking at tool use by a new user, or a new user to that tool, or a user going for RfA you want to know how they use those tools. Maybe to be efficient as most times people probably do not want to see the edits have links to show latest automated and non-automated and thus only generate when required?

Ah OK sorry I missed that, I guess I expect those links at the top to be the same as the options you are currently on.

@Paracel63 - The fix is still in the state 'Pending Deployment' (see 'Tags' right hand info bar) so you wont see the fix live just yet.

@MusikAnimal I'm not sure this fix is correct - isn't the figure for with edit summaries only for live edits?. With this 'fix' it would suggest I have 10.4% without summaries rather than 0.7% which I think is more likely, and what the old xtools shows.