I can confirm that this fixes the problem for me as well. Many thanks again!!

It would be great if this could be tackled. MediaWiki 1.39.6 was released recently, and I am stuck with 1.39.2. I think it was unwise to change this extension for an LTE release mid-lifecycle.

Ah, sorry... I just found out that the problem with PluggableAuth and SimpleSAMLphp has nothing to do with these differences. I actually tried them against MW 1.39.3, and apparently, this version simply is not supported yet. But maybe the differences between an upgraded and a fresh wiki are of concern anyway.

Regarding "concerning lines": For reference, below is the complete update log. I guess the warning regarding logging_type_action is okay.

With this patch, the update script succeeds, my test wiki is now at version 1.39.2. Thanks a lot!

It is a pretty empty test wiki, I only edit the main page after an update. It might have been upgraded from 1.31. But even a lot of our production wikis don't use templates (i.e. the table "templatelinks" is empty).

Thanks for the clarification. I guess this already concludes this task :)

According to Skin Labs (see links in previous post): Yes. I can't test, I've switched from MetroLook to Vector.

Just for the record: Jon Robson's "Skins Lab" demonstrates the error as well:

Actually the problem is not in table "recentchanges", but in "revision". A quick and dirty fix is to change "2020" to "2020x". After changing the entry in "recentchanges", the upgrade still failed. I only then saw, that "revision" contained the same entries. After fixing that entry, the upgrade succeeded.

As I would like to continue updating my wikis: Maybe someone could tell me if my workaround is valid, or if I have to expect troubles in the future. From what I can see, the foreign key relation to "page" is still intact, but a second opinion would be great. And I am a little bit worried, that whatever was responsible for creating duplicate entries, might now throw an error when trying to do the same again.

Valid point. I checked if this could be an artifact from e.g. restoring an old database without dropping the content first. But as this was the only table where I could find duplicate entries, I blame an older version of MediaWiki. The Wikis in question started with 1.2x about two years ago and where updated to 1.31 and 1.34 a few months ago.

I am currently evaluating Timeless as a replacement for Metrolook, which is broken on MW 1.35. Why has there to be a background image at all??? I'd like to configure a plain background and not bother to find a suitable image I can put there.

But it does not affect the upload button, if one is present:

Maybe I should illustrate the problem. This is what the top bar in MediaWiki 1.35.0 looks like, both in rc1 and rc2:

Sorry, I missed following up on this. It's now merged and will be backported for 1.35. Thanks for the patch :)

I just checked in 1.35.0 rc0, and this bug is still present. Why????? Could someone please just commit this?

This might solve T30162, at least that's the only task I could find mentioning the same problem. But as that task has been dragging on for ages, I'm not sure if it hasn't moved on to different topics. Especially considering that the fix seems so obvious... That's why I opened a new task. Any help in getting this bug fixed is appreciated.

I tried the Gerrit patch uploader, but either I chose the wrong project ("mediawiki"), and/or the wrong prefix for the file to patch. The patch as shown above was rejected. As I am not a developer, I'd rather prefer someone else would submit this change if it is considered useful.