This doesn't seem to be limited to quarry. Queries (such as https://quarry.wmflabs.org/query/36665) that had been running in about 15 minutes both on quarry and through a bot running https://wikitech.wikimedia.org/wiki/User:Legoktm/toolforge_library (using the toolforge DB replica) are now timing out on both. The issue appears to be with the database servers themselves.

I would agree that the intended behavior of the "Article" button, when on a talk/history page of a redirect, should be to link to the redirect itself. The number of times an editor wants to go directly from the redirect talk page to the redirect target is small compared to the number of times the editor wants to go to the redirect itself.

Only using 40% of the page width for the actual article text seems quite low, and makes the page look cluttered (despite all the whitespace). Vector, by comparison, uses around 80%.

In T192462#4627547, @Lydia_Pintscher wrote:

Is there anything left to do here or can it be closed?

Since potentially tens of thousands differrnt sized thumbnails were affected by this bug, will the server eventually regenerate all of these, or will they need to be purged manually?

Oops, I don't know how those projects got removed...

Once this is resolved, is there any way to programmatically regenerate all PNG thumbnails created since the change to python-thumbor-wikimedia 2.0?

We're still cleaning up the mess caused by switching from Tidy to RemexHTML, and on larger wikis such as enwiki tech-savvy editors will still be needed to working on the hundreds of thousands of pages with broken rendering for the forseeable future. Breaking all the old scripts and gadgets "soon" (as specified in the Tech News blurb) would be a disaster. This is only compounded by the roll out of the Interface Administrator group later this month, which means that gadgets and scripts in the mediawiki namespace or in the namespace of inactive users will only be able to be fixed by the very small number of editors granted this permission.

@Reedy Is 20 queries a problem? Wasn't that the status quo when the limit was 50/500?

Per https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Self-links_not_bolded_in_certain_viewing_configurations this is still affecting Minerva.

See https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Pinging_over_50

Seeing this on enwiki as well (see https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#PNG_transparency_issues_with_new_images).

I can't do a performance trace on the machine where I was seeing performance issues due to the way the group policy is set up, but I can say that the performance is much improved.

In T195625#4252415, @Legoktm wrote:

Does it not work for you on Android Chrome? What device / Android version are you using?

If you want to opt-out, you can use your mobile browser's "Request desktop site" option

While I agree with @Andrew_Davidson that there is no real harm in perminantly granting confirmed status, the 10-day limit was the main difference between this successful RfC and the previous failed one. From what I understand, even "confirmed" users will get "autoconfirmed" status after 4days/10 edits, so "confirmed" dropping off will be transparent to them.

@Urbanecm the task description says "Administrators should be able to grant and revoke this permission". Line 10967 in InitialiseSettings.php needs to be updated accordingly.

@TBolliger @Framawiki The RfC has been closed as "ADOPTED", so implementation can proceed: https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_comment/Event_coordinator_proposal&diff=840216728&oldid=840205201

mw.wikibase.entityExists('Q404') returns false

The easiest solution which wouldn't have to be hardcoded for certain images would be to have the app's dark mode invert any image whose alt parameter begins with a "\". There should be almost no non-symbol images whose alt text would begin with a backslash.

I have updated the tool. It will now display a disclaimer unless consent is given by appending a variable to the URL.

This tool is only supposed to be linked to from https://en.wikipedia.org/wiki/Wikipedia:IRC_help_disclaimer which has a warning. I will add code that detects whether a disclaimer has already been presented.

One nice side effect of removing !important is that it would allow users who want to see navboxes, despite the performance hit and glitches, to do so by adding a line to their custom.css.

While we're waiting for someone else to take this up, a workaround on a per-image basis is to download the image, convert it to grayscale using a more recent version of Imagemagick on your local computer (using "convert {input_image} -type GrayScale -depth 8 gray.png", and re-uploading it. It would be nice, however, if this were fixed on the server somehow.

This seems to be related to the ImageMagick bug documented at http://www.bennadel.com/blog/2825-fixing-grayscale-png-thumbnail-images-that-come-out-too-dark-in-imagemagick-6-7-7.htm , in which case the solution was to force ImageMagick to render thumbnails as 24-bit PNGS (adding "-define png:format=png24").

Jahn1234567890's example can be seen at https://en.wikipedia.org/wiki/User:Ahecht/Dave_Marcis

I still don't see what problem MZMcBride and their friend were trying to solve. There was no real problem with the way tables had been displayed for years on Wikipedia, and while some tables might be improved by this change, a large number have become difficult to view for readers with smaller or lower-resolution screens. For most font sizes, a padding of 0.2em is already larger than the 1px HTML default.