@saper Sorry, I don't have backups from the time before I upgraded all Wikis to 1.39, that was 2023. At the moment my test environment has only the latest version and I am upgrading my test Wikis before the productive ones. I am considering installing the old releases in my test environment so that I can actually test these upgrade chains. If e.g. these older releases are compatible with a recent PostgreSQL database, though.

I'm not sure this is related to T330382 ... after all I seem to have reported that problem...

I finally managed to test the patch from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1175232. Updating a wiki from 1.39.13 to 1.43.3 with the patch applied succeeds without errors. These are the remaining indices starting with "site(s)":

public | site_global_key                  | index | mwtephemeral01 | sites
public | site_identifiers_pkey            | index | mwtephemeral01 | site_identifiers
public | site_stats_pkey                  | index | mwtephemeral01 | site_stats
public | sites_pkey                       | index | mwtephemeral01 | sites

I guess the internal error was caused by the PHP cache and is not really related to this problem. I'm not sure if I manage to check the patches, my plan was to wait for the next proper release :) I see what I can do.

I can confirm that an update of a fresh 1.39.13 install to 1.43.3 now succeeds. I'll need some more time to check a "used" Wiki :)

Can I award an Eagle Eye scout badge to @A_smart_kitten ? I looked at that code (I simply removed it with the patch above) but that part eluded me!

To continue this quest: These are the indices of a fairly recent 1.39 Wiki, that was deployed earlier this year with 1.39.11 and later updated to 1.39.12:

What I don't understand yet: The update of both wikis above fails with exactly the same error (essential what the OP already presented). I can fix the update of the second Wiki (the one freshly installed from 1.39.13) with the attached patch. The update of the first wiki, with the site/sites mix, still fails.

One puzzle piece is probably a bug that lies somewhere in the past. A Wiki under 1.39.13, that has been updated over several versions since 1.35, has these indices:

I tried looking into the code where these renamings are happening, but I can't find anything, where site(s)_group is an outlier compared to the other indexes. Maybe someone with more knowledge of this code can take a look? At the moment I consider this a showstopper to migrate from one LTS version to the next.

Quick correction: For me the error occurs on site_group, not site_type. But I see the same command (ALTER INDEX, DROP) for both indexes.

I wrote some debug logs before starting the upgrade, and during upgrade this is logged:

I get the same error when upgrading from 1.39(.13) to 1.43(.3). At the moment rerunning the script results in a broken wiki (internal error 500).

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.