In T189989#9137913, Krinkle wrote:

Given that the social convention around MediaWiki, as originated on Wikipedia, is to use /doc pages I would generally suggest going along with that. It is not sustainable for the entire ecosystem to support multiple ways to do the same thing. In some cases we need to due to mutually exclusive requirements between important use cases, but I don't see that being the case here. I believe you could transition slowly/gradually, so there's no big barrier there either.

For the original request, I would suggest declining this request.

An additional benefit, in contrast to what WMF does to serve WebP instead of PNG/JPG on the CDN layer, is that files will be served with the correct file extension. Currently on WMF, some thumbnails are served as WebP with .png extension, confusing users when downloading those thumbnails to their devices for later viewing/editing or uploading them somewhere else.

In T18691#9034663, @Prototyperspective wrote:

This would be especially useful needed on mobile where one doesn't have a TOC.

When fixing this, debugging the resulting SQL query, I noticed something strange. The default value as defined in extension.json is [ 0 ]. If I set $wgNamespacesForEditPoints = [ 0, 6, 10, 14 ], the resulting query results in [ 0, 0, 6, 10, 14 ] (notice how the value 0 is repeated)

No, it doesn't fix the issue...

I'm trying to change LinkSuggest to the textSelection API, but this alone doesn't solve the problem of LinkSuggest not working with CodeMirror.

Someone else posted the same error here: Topic:Xgzx1hu3sdlxsyg1

Such a configuration exists on MediaWiki 1.39, added to solve T217307

Note that, if you follow a link to Special:MyLanguage but the page hasn't been translated in your language, it currently redirects you to the base page.

In T326859#8738554, @Jdlrobson wrote:

I don't think it's unreasonable to expect reconfiguration with a new release. This happens quite frequently from my experience with MediaWiki and I do not see any guidance in https://www.mediawiki.org/wiki/Stable_interface_policy prohibiting it.

I'm going to be bold and reopening this task, for multiple reasons.

I've uploaded a fix. If you can test it and run the script again against the namespaces that failed, it should fix the problem. Existing revisions should be skipped

Fixed by Func in https://gerrit.wikimedia.org/r/c/mediawiki/tools/grabbers/+/881378

In any case, the fix would be to only skip the setParentId, not the revision insertion (if that doesn't cause any other issue when inserting the revision).

That's strange. The scripts haven't changed much since it was tested on 1.37. And in fact I have successfully imported a wiki very recently to 1.39

While I can see a potential security problem by allowing defining variables, using the var keyword doesn't have any potential impact that I'm aware of, and can be very useful for wikis that may define variables in each skin CSS file, or even core skins can define variables for themes, dark mode, etc.

In T328610#8587808, @Tacsipacsi wrote:

What should be done with gadgets whose usability/usefulness really depends on desktop vs mobile, not on Vector vs Minerva (e.g. Navigation-Popups-Gadget, which doesn’t work without a mouse)?

I'd prefer a maintenance script to trigger those notifications. Per T58028#3097853, the next edit congratulory notification may be difficult to reach when it's reaching large numbers. This would give site owners a lot of control of when those messages should be sent (once a week, a month, etc).

I think this request is invalid because it already supports those parameters (they existed before the task was created, as they are mentioned in rPWBCac834c998a from 2014)

I'm experiencing the same problem very occasionally on wikis using redis as the cache backend, and also on wikis with memcached backend. Both redis and memcached are fully functional and I don't see any error in redis logs.

The #content element has this rule applied:

This recent commit may fix the issue rMW62763e5d52d519a8b08b8b178e0da34822367a08

At mediawiki.org there are lots of anons confirming fuzzied translations in bad faith, every day, and there's no easy way to revert them. I have to manually copy part of the text that was unwrapped from the span tags, and search it in the translation page to manually add the !!FUZZY!! text. This is very time consuming.

Note that the revision table was a 2-step migration.

In T282453#8469290, @adrelanos wrote:

In any case (no need to nginx or above config) MediaWiki's core could generate a different HTML based on the browsers accept: HTTP request header. Two different HTML document versions in the cache however might be OK for a small wiki but too much for Wikipedia.

I hacked the cleanupUsersWithNoId.php script for MediaWiki 1.35 to fix other problems that weren't addressed by the original script: https://gist.github.com/ciencia/7cbe63b8520d4816ec36733454a2cb9a

Ooops! Yes, my mistake. I didn't notice it was the page display title.

Weirdly enough, you can use spaces as the search string and it will replace them correctly.

This happened today again, although it was a single revert and not multiple ones.

Since the page image is only visible at ?action=info this kind of vandalism could go undetected for some time, during which it would be shown to a variety of people inside apps and search.

The revert was done on master, but this extension has been already branched for REL1_39. I think it should be reverted on REL1_39 too (see submitted patch), to avoid landing a feature that's not present on master.

I note there's no Cache-Control: response header, which means the browser has freedom to cache the images. This looks like a duplicate of T19577: Thumbnail urls should be versioned and sent with Expires headers

@Novem_Linguae Devs will probably appreciate if you can post here the HTTP response headers from the image, which will give more details like which server is serving the stale image.

Duplicate entries can be removed running those statements:

Not surprising, since tables.sql for MediaWiki 1.31 has:

For some reason, I didn't set the maxmemory-policy setting of the redis instance of the main cache, which defaults to no-eviction.

In T229092#8195592, @Kghbln wrote:

Thanks for your info and pointers!

After falling flat on my face a couple of times by going from 1.31 to 1.35 directly I switched to upgrading 1.31 to 1.32 to 1.33 to 1.34 to 1.35. For this reason, I was asking about when this script is kicking in, i.e. when this patch will be needed initially. From your answer, I get that the patch is, given my upgrade path, already needed for the upgrade from 1.31 to 1.32 and not just for 1.35 onwards.

I do not think we will get backports to unsupported branches of MediaWiki. Actually, I do not even expect this. Thus we will have to do it locally to help overcome MediaWiki's by far darkest hours which were introduced with the schema changes between 1.31 and 1.35. I have to note that even upgrading in steps like 1.31 to 1.32 to 1.33 to 1.34 to 1.35 will to my regret not be clean in all cases.

I've fixed one of the links to be more meaningful, since further edits were done to translations, resulting in the propagation of the revert.

I've brought @Legoktm attention to this task, and he said it will look into importing them

There's an space at the end of HotCat.js in MediaWiki:Gadgets-definition

Today a user got a JobQueue error. And starting from yesterday, a lot of JobQueueError are being logged in the MediaWiki error logs,

According to T311170: [regression] Communities and extensions should be able to mark up elements so they don't overlap the header https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features/Sticky_Header#My_templates_use_sticky_elements._How_do_I_get_them_to_work_with_the_sticky_header?, a CSS class should be added to the sticky header of the table to prevent the overlap.

Last time something similar happened, the disk was full T302856, although the error message was more informative.

I've enabled the ratelimit log and I'm surprised to see it flooded with entries: P30866

This has happened again. And I can confirm it's unrelated to <includeonly> tags.

Nope, no errors (not related to those edits at least).

I've tried to reproduce the issue with MediaWiki-vagrant (master and 1.37), but I wasn't able to. Very strange indeed. Will keep an eye if this happens again.

This is not a community gadget or community CSS/template, but a WMF extension (StructuredDiscussions)

Not surprising when you find the lang attribute is present in the mustache template :-)