Can this tool please be configured to not import under 10 bytes file description page revisions, or at least to pad the ones under 10 bytes with spaces or the 10 byte string "Padded4AF4"? Alternatively, can it be configured to back off importation of revisions which fail any AF and import the rest (unless the latest revision fails)?

In T192744#4153059, @Gilles wrote:

As for non-WMF MediaWiki deployments, applying sharpening to PNG thumbnails is easily achieved by a one-liner modification to the MediaWiki code. Someone who needs this could go the extra mile and make it based on a config variable and it would get merged into MediaWiki itself. Just like someone recently made JPG quality configurable.

In T190988#4873910, @Nemo_bis wrote:

In T190988#4755722, @SJu wrote:

The problem is still continuing... I propose to switch cross-wiki uploads off

That's certainly the most sensible thing to do. We don't need this unmaintained piece of software to cause havoc on our projects.

Sometimes, the rotation sought is not around the center point, but around the central vertical or horizontal axis (sometimes called mirroring, flipping, or flopping). This should be doable losslessly. See also c:MediaWiki talk:Gadget-RotateLink.js#Mirroring as Rotation.

More examples: https://commons.wikimedia.org/wiki/File:East_Huntington_Bridge_Looking_Downstream.jpg and https://commons.wikimedia.org/wiki/File:East_Huntington_Looking_Downstream.jpg

In T195515#4370949, @Jeff_G wrote:

This problem also appears to be affecting StalkToy and CrossActivity at https://tools.wmflabs.org/meta/stalktoy/ and https://tools.wmflabs.org/meta/crossactivity/ .

Finding and fixing the problem would be great; automating the restart would be a close second.

In T195515#4306205, @Bstorm wrote:

For page queries, we ended up removing one of the joins (revision, since that was the problematic table due to its size).

Can you try putting it back as a test? How big was it?

This problem also appears to be affecting StalkToy and CrossActivity at https://tools.wmflabs.org/meta/stalktoy/ and https://tools.wmflabs.org/meta/crossactivity/ .

This has been happening on Commons, too. This edit by Bsadowski 1, who has Local user-groups Image reviewers, File movers, Rollbackers and Autoconfirmed users and Global user-group Stewards, appears unpatrolled in my watchlist. As a member of Image reviewers, that user should inherit the Autopatrolled group rights. https://commons.wikimedia.org/wiki/Special:ListGroupRights confirms that five groups have the right "Have one's own edits automatically marked as patrolled (autopatrol)": Image reviewers, Autopatrollers; Bots; Patrollers; and Administrators. See also https://commons.wikimedia.org/wiki/COM:VP#Unpatrolled rollbacks.

I suggest merge with T198449.

In T64920#649300, @Aklapper wrote:

What is guc and where to find it?

To be clear, by "same query", I meant https://tools.wmflabs.org/guc/?user=Krinkle&debug=true, currently "+38.09s: Quering wikis on s7.labsdb for matching revisions" out of "Total: 91.17s." with "Current time: Thu, 31 May 2018 04:00:09 +0000".

I just did the same query and got "+110.24s: Quering wikis on s7.labsdb for matching revisions" out of "Total: 157.62s." with "Current time: Mon, 28 May 2018 13:14:28 +0000".

Suggestions for the future:

• Don't use temporary names for tables which may become permanent.
• Name and describe tables appropriately, especially including those that have temporary names.
• Use invisible indexes for a while before actually dropping.

No, this problem is not the same as in those other tickets. In this case, the image of Margaret Thatcher at https://upload.wikimedia.org/wikipedia/commons/thumb/9/92/Margaret_Thatcher_at_White_House.png/240px-Margaret_Thatcher_at_White_House.png looks significantly blurrier or more out of focus than the image of her at https://upload.wikimedia.org/wikipedia/commons/thumb/1/15/Margaret_Thatcher_at_White_House.jpg/240px-Margaret_Thatcher_at_White_House.jpg .

I am getting "Error: MySQL login data not found at", in addition to the originally reported warning.

I mentioned this task at c:COM:VP#Files with too big wikitext. We need sanity checking on both Flickr2Commons and whatever it uses to upload.

If there is no other section, why do we even need this section header at all?

This would be especially helpful for IP Addresses.

I get "Error:
An error occurred preparing to query file-information. # API request failed".

In T180012#3759983, @Aklapper wrote:

@Jeff_G: Could you provide those response headers by looking at the network tab of your browser's developer tools?

@Aklapper: I have asked the affected user to do so at https://commons.wikimedia.org/wiki/User_talk:Seth_Whales#Help

Seems to be working now.

Sorry, I was confused. I meant that page creation logs would be helpful for the reasons detailed above.

In T155290#3682605, @Yurik wrote:

@Pnorman actually we already use Wiki markup in these pages - the .map pages treat title and description fields as wiki markup. I haven't heard of any problems -- the values are being sanitized by the regular MW parser, and gets consumed by mapframe/maplink/lua code. Adding this field wouldn't be much of a challenge from the tech perspective.

It appears at present that there is no way to add wikitext to that file that will cause it to be tagged for deletion, or as a copyvio, or anything really. We need at least one work-around.

In T173472#3531968, @Marostegui wrote:

I remember that last week when troubleshooting it, I did mention the amount of writes as the first possible explanation after checking the graphs but both @cwdent and @Jeff_G mentioned that not all the servers lagged at the same time. Which is what I would expect if they have the same configuration and HW, which apparently they do.

@Marostegui Sorry, that was not me. Perhaps you mean someone else.

Now, the opposite is happening, we are seeing comments for all the old versions of a file, but no comments for the current version. Please see https://commons.wikimedia.org/w/index.php?title=User_talk:Jeff_G.&diff=258558508&oldid=258188936 and https://commons.wikimedia.org/wiki/Commons:Village_pump#Disappearing_comment_in_.22File_history.22_section_for_the_current_version_of_a_file for details.

Thank you all!

In T175444#3593744, @Umherirrender wrote:

It is not about the normal history[1], about the filehistory on the file page[2]

[1] https://commons.wikimedia.org/wiki/File:Example.jpg?action=history

[2] https://commons.wikimedia.org/wiki/File:Example.jpg#filehistory

In T171421#3469152, @fgiunchedi wrote:

@Aklapper _usually_ traffic since this indicates varnish failure to fetch and most likely a network or varnish problem. See also https://grafana.wikimedia.org/dashboard/db/varnish-failed-fetches

Another new URL with the same symptoms above using the same browsers as in the original description: https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/Mile_High_Stadium_on_July_13%2C_1995.jpg/290px-Mile_High_Stadium_on_July_13%2C_1995.jpg as displayed by https://en.wikipedia.org/wiki/Mile_High_Stadium
In Puffin Browser Pro, I see "Error 349 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION) when loading URL
https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/Mile_High_Stadium_on_July_13%2C_1995.jpg/290px-Mile_High_Stadium_on_July_13%2C_1995.jpg" at the first URL

New symptoms: https://upload.wikimedia.org/wikipedia/commons/thumb/2/23/Ortega%2C_Juan_de_%E2%80%93_Tratado_subtilissimo_de_aritmetica_y_de_geometria%2C_1515_%E2%80%93_BEIC_104004.jpg/180px-Ortega%2C_Juan_de_%E2%80%93_Tratado_subtilissimo_de_aritmetica_y_de_geometria%2C_1515_%E2%80%93_BEIC_104004.jpg and https://upload.wikimedia.org/wikipedia/commons/thumb/e/ef/Bundesarchiv_Bild_183-E1012-0024-001%2C_Dresden%2C_Pirnaischer_Platz%2C_Hochhaus_%28cropped%29.jpg/180px-Bundesarchiv_Bild_183-E1012-0024-001%2C_Dresden%2C_Pirnaischer_Platz%2C_Hochhaus_%28cropped%29.jpg
UPDATE: I meant URLs with the same symptoms. These two URLs no longer display the symptoms above.

I can no longer reproduce this error, so thanks to whoever or whatever fixed it!

In T168949#3434184, @Gilles wrote:

@Jeff_G please create a separate task for this issue with more details (which browser, browser version, a screenshot of the error, etc.). It's unrelated to this task.