I see that three other tickets were merged into this one as duplicates:

There were a few wikis where, on upgrade from MW 1.31 to MW 1.35, the maintenance/upgrade.php script failed with a mess of errors like

User name "RandmGrbage6661313" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

In most cases, these users turned out to be spambots, "Maintenance script" or other entries where there's a name but a user_id of 0 or no corresponding user in the user table. This tends to happen if an incomplete attempt is made to get rid of a spam "user" (such as by running maintenance/removeUnusedAccounts.php) with remnants left behind in the archive or log table; it also happens if a wiki contains imported revisions and the corresponding users don't exist locally, as well as for pseudo usernames for things (such as maintenance scripts) which aren't users and therefore lack a non-zero user_id or a user table entry.

Apparently, yes, two records with [[Special:Contributions/...]] (namespace -1) did make it into Ansaikuropedia's page table. They look to have been lurking since 2008:

When retrieving pages manually from the database, the names may contain Unicode. A string literal may therefore need the _latin1, _binary or _utf8mb4 modifiers, ie:

I'm seeing similar issues on an "upgrade" from an existing MW1.31 installation to MW1.35; the migrateActors operation fails when invoked from maintenance/update.sh - but usually on non-user entities like "MediaWiki default" which the script will attempt to add to the actors table, only to die on a duplicate record error.

The index which SQL is expecting to be UNIQUE is on the revision table, as
usertext_timestamp (BTREE, unique) on fields: (rev_user_text, rev_timestamp, rev_page)

OK, so what happened?

This is specific to Pywikibot-interwikidata.py, which requires your 'bot run on a "home" wiki with access to a Wikidata-style (Wikibase) repository. You can't do this on cs:uncyc but it should be possible on pt:uncyc (as one example). OK, here goes:

WikiID is useful internally, within that one MediaWiki instance, as it's unique within one database server. It's not useful to an external process (such as interwikidata.py) which has no direct connection to the SQL database.

T221550 says that there is no GlobalID available from API because there is no support for GlobalID in the core code.

Yes. Pywikibot blindly trusts that whatever wikiID is supplied by the remote wiki's API is indeed going to exactly match the GlobalID.

The GlobalID is the name of the wiki, as it appears in Wikidata. For instance, "enwiki" is the English-language Wikipedia. A Wikidata entry with the individual GlobalID for each wiki looks like https://www.wikidata.org/wiki/Q2736

I've also mentioned this here https://gitlab.com/hydrawiki/extensions/DynamicPageList/issues/88 as one of the DPL versions affected is on 'github'.

This so-called "feature" has now been permanently removed on Cloudflare's side. That should stop this issue from arising again.

Perhaps the easiest solution would be to create one more LocalSettings.php variable, maybe $wgGlobalID = 'xymyproject' or something similar, and return that in the 'WikiID' field from the API if it's been set instead of reporting the internal WikiID() ?

OK, thanks. I've tested this by setting $wgInterwikiCentralInterlanguageDB = 'uncyc_commons'; on one of the inactive projects (which would benefit from your shared table, as there's no one local to update/maintain the data) but not setting $wgInterwikiCentralInterlanguageDB on whichever active projects wanted to retain independent local control. Your solution appears to make sense.

How would this handle the various cases where one local wiki wants to handle an interwiki prefix in some different or non-standard way, for instance to point wikipedia: to the local-language Wikipedia instead of the American-language version? How would it handle the case where each local project wants to decide which fork of the same wiki to link to?

This is just an untested idea, but perhaps a more general solution would be to str_replace the group name and (in the lone case where $group=='wikipedia') also str_replace out the 'wiki' suffix. Something like:

What happens if the group name doesn't start with "wiki* or "wiktionary". That's pretty much an inevitability on a third-party wiki.

[[Special:Statistics]] includes both live and deleted revisions in the "revisions since wiki inception" count; an XML dump will be missing every deleted revision, which pretty much ensures the numbers will not match.

I see that RelatedSites links are being removed from some articles even though a replacement link of whatever form (templates, Wikidata...) is not present and is not being added, for example: https://en.wikivoyage.org/w/index.php?title=Wikivoyage%3AKeep_Wikivoyage_fun&type=revision&diff=3639962&oldid=2852033 removes a link to [[w:Project:Civility]] without replacing it with an equivalent link in some other form.

There is still a need in Wikivoyage to allow the voyager to download GPX traces for use on a handheld device (such as Garmin's GPS units - where the format originated). That allows the user to carry the data offline with them during their travels.

Basically, the issue with taking redlinks on talk or project pages into account on Special:Wantedpages is that those red links may well be from discussions of why a specific page should not exist or even a deletion debate. For instance, a comment like:

And no, the text formatting of that PHP code stub for the kludge {{#logotipo:}} tag (which also is broken by MW1.31) should have been:

<?php

No idea why this was marked as a duplicate of T221:Booklet Design - Design a Language Engineering Booklet for Wikimania.

From https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#We_need_to_remove_all_the_RelatedSites_links :

One thing to watch before claiming that "this extension provides no functionality whatsoever that isn't already covered by Wikidata's other project links": there is a Wikidata limitation which requires a 1:1 correspondence between Wikivoyage articles and the corresponding sibling project pages. Any attempt to link to the same page from more than one Wikidata record will throw an error. That's an issue if Wikivoyage divides entities (such as cities) differently from Wikipedia - which happens because Wikivoyage wants divisions which produce reasonably-sized articles while Wikipedia aligns onto incorporated municipality boundaries.

Admittedly, I'm hesitant about relying on Commons and even more reticent to rely on something being present on a non-WMF project like OpenStreetMap. If https://en.wikivoyage.org/wiki/Bavaria is "the largest state of the Federal Republic of Germany", odds are it's a legally-defined entity and its borders are consistent and known; OSM has them tucked away somewhere. Some of our lower-level regions, though, are arbitrary: where does "southeastern Ontario" end and "eastern Ontario" begin? Each language Wikivoyage divides things differently; an imported {{mapmask}} needs the local wiki's version of these subprovincial regions as some languages have more articles and therefore divide the same territory more finely. A few novelty itineraries like the https://en.wikivoyage.org/wiki/Breaking_Bad_Tour or Radiator Springs might not be marked on any OpenStreetMap. It's anyone's guess if OSM would keep https://en.wikivoyage.org/wiki/Route_66 on the map if it legally hasn't existed since 1985.

Interesting, but that does still leave a few questions:

There is some documentation at https://www.mediawiki.org/wiki/Manual:CloudFlare but basically there are two options:

• Install mod_cloudflare into Apache, or
• Install https://www.mediawiki.org/wiki/Extension:TrustedXFF with a configured list of CloudFlare servers

This is called "SmartErrors" (however ironically) and is an optional 'feature' which can be disabled from CloudFlare's user interface. See https://www.mediawiki.org/wiki/Manual:CloudFlare#Error_404_handling

Would it make sense to hook [[mw:Manual:Hooks/TitleSquidURLs]] to get the list of URLs to purge?

Jdforrester-WMF, this is not rare (it happens routinely in Wikivoyage, where /* Get in */ and /* Get around */ have individual modes of transportation as the subheadings... in every article) and does not require the duplicate heading to be generated in a transclusion.

Agreed, if one has many pages watchlisted, this generates so much e-mail (in its current form) that one soon turns the e-mail notification "feature" off completely just to stop the spew of mail for relatively unimportant edits to minor topics.