OK I had the same issue. The config file was:

Wouldn't the best fix be to make the processes scalable? I'm amazed that 100 million rows here or there cause a problem

"Waiting to see if this becomes a widespread issue." Meanwhile data is being irretrievably lost,.

Thanks for fixing.

Not sure why this needs triage now. It's a long standing broken part of the system, which should have been fixed a long time ago. If the foundation can't fix it in 14 years, and with, I suppose, about $1bn to spent, I despair of having anythung useful done. Certainly lowering the priority won't help, and raising it seems unlikely to either.

I

ndex: SiteInfo.cs
===================================================================
@@ -252,7 +252,7 @@
             // web lookup if not in cache
             if (string.IsNullOrEmpty(catCollationInfo))
             {
-                catCollationInfo = Tools.GetHTML(@"https://noc.wikimedia.org/conf/InitialiseSettings.php.txt");
+                catCollationInfo = Tools.GetHTML(@"https://noc.wikimedia.org/conf/VariantSettings.php.txt");

There are a number of points worth making here, though they do not impact on the base idea behind the bug, indeed one is makes it more important.

Just a note that this impacts potential extensions that rely on this type of functionality.

We will be wanting to insert something like

To be consistent with the history view, the number should be displayed before the edit summary of the right hand edit. This may be misleading in that it appears to assign the change to the last edit.

Question: The diff view from history is a different use case to the diff view for "show changes". It is also different from a diff generated from two page version numbers which are not necessarily of the same page. Will this patch need to distinguish these cases? If the numerical value is stored in the database, then the history version may be simple, for adjacent versions. For non-adjacent versions it will still need calculating.

Is this total destruction of a historic set of documents?

There is also the possibility that it is something else loading from bits, perhaps. There seems to be a metric tonne of css, js and other stuff in there.

Simple way is to re-instate magic links.

I agree with SV above. This is a major (and somewhat foolish) change. It should not be imposed by a technocracy.

Great work everyone (especially Ryan!).
Simple is good.
I have changed hidden filter 12 on en:wiki so that it will work with either version of ccnorm, after the Mediawiki change it can have the code for old version removed.
This approach means that we get no gap where filters are inactive, and hence no narrow window for implementing the changes, nor any rush after the Mediawiki change.
It also means that if we have to revert the Mediawiki change within a short time, the rules should still work.

The correct solution for this problem is clear if we separate the concept of Wikipedia articles from Wikidata items.

Here is a plan:

And here is some MIT licensed glue to both POSIX and PCRE libraries. http://rrthomas.github.io/lrexlib/

This should be fixed. Of course breaking reg-exes exist, but we face the same problem as we did when we tried to deny template developers parser functions on the grounds that they were idiots and would break the whole wiki - namely that someone will write Module:RegEx.

There are privacy issues here. I have initiated a discussion at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28policy%29#Privacy_and_dark_traffic

As the latest person to get bitten by this bug, can I press for some progress. If the category suggested by Tim in six years ago, and Mr Stradivarius one year ago can be implemented, then we can at least get some idea of the magnitude of the misfeature use. Conversely if they can't let us find another way forward.

This is a real nightmare.

Ok thanks.

Thanks

@Aklapper - best to ping me via my en:wp talk page

There has to be concern that a recursive check like this could seriously degrade the privacy of users. For example suppose that I am a trusted user - something I am never sure about - and I come up as having shared an IP with a vandal. A manual checkuser would stop there, and perhaps confirm that the IP usage was widely disparate in time if it was an dynamic IP, or was a communal hotspot or something, but a recursive one would identify all the IPs I had edited from, and all the editors who had edited from those IPs, etc.. I know certain editors who do not want their attendance at meet-ups shared with non-attendees, and it would certainly not be a good thing to have these associations seen by some who have Checkuser power, and doubtless archived on the Checkuser wiki for all eternity.

I like the tag "Huggle" since it's a proper noun. WPCleaner does and AWB would also start with capitals. Keep lower case for things like "generic tool".

Confirm this is almost ubiquitous. And possibly linked to https://phabricator.wikimedia.org/T101224

There is a throttle setting that is overridden of WP:EN, specifically to allow the use of mass rollback/undo. Perhaps this same mechanism could be applied here.

We could drive this of edit-filters fairly easily,if that's what you mean. The existing solution should be blindingly fast, and is easy to understand Edit filters would have the benefit of simplifying the overall scenario, and of providing a warning log that could be useful in forestalling abuse.

Given there are some issues about the change-set proposed by Platonides (for which thanks), can we resolve this bug by utilising the fallback mechanism Krinkle mentions to "Restricted-use media list"?

I strongly disagree with this. There is no purpose to be served other than vindictiveness in denying locked users the ability to receive email.

It's worth noting that one often comes to Wikipedia with an unknown term, where there is uncertainty in both the language and meaning. This use case would not be helped very much by this solution, though other cases might.