It works for me, but the publish button was greyed out until I clicked on the rosette(?) icon to the right of the title and added a badge for "sitelink to redirect".

On enwp, and perhaps all wikis, Preferences→Search→Show thumbnails in Special:Search can now be unticked. I don't know whether this prevents transmission of images or simply hides them.

One problem is that "vector" is already the key of another skin, the one currently used by most desktop readers and editors and which will continue in widespread use. Giving a different skin the user-facing name "Vector" is bound to lead to confusion.

I don't find the images helpful either, and have added CSS to avoid displaying them, but I expect they still get downloaded, tying up Wikipedia's bandwidth and mine. The clinching argument may be that, because some of the images are non-free and lack fair-use rationales for their appearance in search results, showing them to me risks putting the WMF in breach of copyright law. (I am not a lawyer, this is not legal advice, laws vary by jurisdiction, etc., etc.)

Please change the wording of the link. "Donate to Wikipedia" incorrectly implies that a significant portion of the money donated goes to Wikipedia.

T314417 doesn't seem to solve this issue. For example, try editing Wikidata's [[Q15665435]] to link enwp's [[Orconectes bisectus]] redirect. "Publish" is greyed out, because the enwp page is a redirect. Please, all you have to do is follow consensus by not disabling the publish button.

In T311350#8029110, @LucasWerkmeister wrote:

Ich finde den Vorschlag, die englischsprachige Wikipedia zur Standard-Wikipedia in Quarry zu erheben, deutlich irritierender. Die spanischsprachige Wikipedia z.B. hat die fünftgrößte Anzahl an aktiven Benutzer*innen – wohl kaum eine „unwahrscheinliche Option“, wenn man e eingibt.

Please don't worry about disabling Enter. On the rare occasions I press it, it's accidental (attempting to insert a newline into wikitext) and I have to revisit the edit. I expect others have similar experiences, and we want to encourage previewing or at least viewing a diff.

"Production" doesn't mean "for readers rather than editors". Readers come first, but editing tools help us to serve them well. One action by an editor may help thousands of readers.

I came here to request this and am amazed that it's been open for seven years. It's not sophisticated; it's debatably a bug fix.

Please don't remove the Stop feature. It sometimes works, and is better than nothing, both for users who (sometimes) get their query unlocked for fixing and for the servers which can cease wasting resources on pointless tasks. The feature really needs mending rather than removing.

I may have a workaround:

• tick the "Don't allow site to prompt you again" box on the 500 box (text varies by browser and language), or ad-block that box and its modal background
• replace the query by a trivial one such as SELECT 123 /* keep old query here for reference */
• click Stop and quickly click Submit Query

The query will complete, show the answer 123 and display the "Submit Query" button ready for re-use.
That's not ideal or intuitive; a proper fix would be much better!

Yes, my trivial query 61115 claims to have be running for nearly four months now, and the Stop button gives error 500. Can we at least do a one-off task to stop all queries which have been in running or queued state for more than, say, a week?

Please fix. If you can really only handle one protocol by default, it should probably be https://

Please consider showing the edit summary box by default, so no one has to discover a method to reveal it. This matches the UX when replying in the traditional way, and is a good use of space.

I've reproduced this misbehaviour in a sandbox, which may be invalid as both edits were by the same editor. I've also seen it in the wild with different editors. It's intermittent, but here are two scenarios which may make it more likely.
1: User:A starts editing page X; user:B moves page X to a new title Y, leaving a redirect X→Y; user:A publishes the change. This overwrites redirect X with a copy-paste move of a modified copy of Y.
2: User:A starts editing page X; user:B makes a quick section edit to X#Foo; user:A publishes the whole-page change. User:B's section changes are lost.

Bdijkstra: Have you tried installing riched20 in winetricks? That fixed it for me.

I reproduced the problem on enwiki_p, including https://quarry.wmcloud.org/query/61115 which should complete in milliseconds but claims to have run for more than a day.

I've now installed winetricks riched20, and neither Naypta nor I have seen the problem since. Here's hoping this is now Resolved.

That may be a bug. <includeonly>...</includeonly> affects text between the opening and closing tags. <includeonly /> affects no text, and is not useful.

The Monza page has now changed and no longer shows the problem. I can reproduce it on enwiki [[1984 Monaco Grand Prix]], where it adds a blank line 351 even with default settings and unticking everything (no find and replace, no general fixes etc., no regex). I have .NET 4.5 (dotnet45) installed (and just updated Winetricks from 20190912 to 20200412).

VE appears to simplify piped links in a way incompatible with transclusion, specifically to replace [[Foo bar|Foo<noinclude> bar</noinclude>]] by [[Foo bar]], This is helpful and harmless on the page being edited, but makes a transcluding page behave as if noinclude had not been used.