@Bhsd Allowing configuring the behaviour of mw.addWikiEditor sounds good. Please do.

By the way, I have another question regarding this note in the change message:

@Bhsd I have a script that makes use of the CodeMirror extension's API. it might add more than one editor to the same document. That's beside the point, however. The problem is that there must not be any two elements with the same ID. That is, IDs must be unique.

The new jquery.wikiEditor.resizingdragbar module added in this change has a small problem: It assigns an ID for the resize bar, but it isn't necessarily true that there can only be one such bar in the entire document. Pinging @Bhsd as the owner of the change.

I read that task and it seems to me that only one of the concerns applies to this new group: it won't be possible to override the automatic assignment. I don't really understand why that would be desirable, can you explain?

What permissions, exactly, will this group contain? I assume "higher rate limits" means apihighlimits and not noratelimit. If it's just the former, then wouldn't apihighlimits-requestor suffice? Several bots have been granted that group already.

The "history" links now look a little bit out of touch with "diff", "cur", "prev", "contribs", as Krinkle has noted above. I think it would have been better to change enhancedrc-history to "hist" and not hist to "history".

The repository is probably this one on Wikimedia's GitLab instance.

Monkeypatchable with:

@matmarex @MusikAnimal The bug doesn't appear to be fixed. I can still reproduce it. I'm using Chrome 143, if that makes a difference.

I went ahead and created a user script. There are a few rough edges, but it is generally usable.

For the record, this change affects several user scripts, in addition to the aforementioned gadgets.

@Nirmos I don't see how T91169 has anything to do with this. Templates and links don't work at all on JSON pages, yet people can still request for their deletion, via either their talk pages or the (interface) administrators' noticeboard.

Appears to have been caused by ad4d59c, which fixes T330941. In particular, the logic here is wrong:

@Ladsgroup Now it's running at just 18 pages per minute. Did something happen?

@Ladsgroup Thanks a lot for your help on this. Might I ask that the bot be sped up? The consensus is that we want the task to be done as soon as possible.

@Tacsipacsi Good point. That's one new thing I learn today.

@Nikerabbit I'm aware of {{#tag}}. The problem is not that I don't know how to include <translate> tags in a syntax-highlighted block, but that the <nowiki>-like-ness of <syntaxhighlight> is not recognized correctly.

See also m:User:NguoiDungKhongDinhDanh/IPAutoReveal.js.

(Please ignore 1193529, which was superseded by 1193530.)

Are you looking for action=paraminfo?

So if I were to write the following some time ago I would also get a broken result?

Table syntax has higher precedence than the file link, in the legacy parser.

This seems to be half-resolved as wikitext was recently added to Pygments in T29828. As for regex, it has many flavors and syntaxhighlighting depends heavily on that. For example, \z means the end of the string in PCRE (a special token), but a literal z in ECMAScript (plain text).

Yep, done that. Thanks for the suggestion.

To whoever monitoring this: I guess that an userscript of mine (and I, who wrote and installed it) caused this error by calling mw.loader.using(['ext.codeEditor']) on pages without an editor, such as Special:Contribs. I must say, however, that it acts as a script instead of a module, unlike most others that can be loaded via mw.loader, is not really a good thing.

If I understand correctly, you are trying to remove leading and trailing whitespaces by using a Lua pattern (not a RegExp, mind you) and the string.match/mw.ustring.match functions:

line = '    foo bar    '
print(line:match('^%s*(.+)%s*$')) -- 'foo bar    '

The + quantifier is greedy; it captures everything it can. Since . matches all characters, including whitespaces, nothing is given back to %s*$. The only non-greedy quantifier in Lua is -, and in this case it works well:

greedy = '^%s*(.+)%s*$'
lazy   = '^%s*(.-)%s*$'

In T309992, @MarcoAurelio wrote:

Partially off-topic question: what do we do if we need to revoke an user access to IPInfo globally, across several or all Wikimedia projects? CentralAuth's global user rights, as far as I know, do not support a function such as $wgRevokePermissions, and adding the no-ipinfo group on 700+ wikis, manually, does not scale.

Doesn't Special:GlobalGroupPermissions support creating global groups with arbitrary (revoked) permissions? If not, then that is also a problem...

@Ilovemydoodle2 50 is the limit of Echo itself; see en:Template:Ping#More than 50 names specified. We definitely don't want vandals go around spamming these things and flood hundred people's notifications.

For example this link on Wikipedia: https://en.wikipedia.org/w/index.php?title=Fatih&action=edit&section=History edits the appropriate section

It leads me to the whole page (VE, source mode).

As far as I know, this is not really a "bug". Server timing out is precisely the way to deal with expensive requests. @Mike_Peel Here's a handy link to your raw watchlist: c:Special:EditWatchlist/raw.

@matmarex Thanks for looking into this. Is there a list of such pages, or will I have to go through every single special page again?

@TheresNoTime So... should this task be updated to reflect that, or have there been any related tasks already?

@TheresNoTime I'm pretty sure because we're talking about their wgCanonicalSpecialPageNames and not URLs.

@TheresNoTime Because, as I said, that's how most other special pages' are written: Allpages, Allcategories, Listgrouprights, etc.

@Krinkle Thanks for your information. That being said, this task is declined as WONTFIX?

Thanks @Stang!

@Pginer-WMF For your information, the abuse filter mentioned in the description (111) and another one that prevents publishing CT drafts into user space (114) were enabled during that time.

@Juan90264 Sorry for bugging you (again). It appear that sysops are not granted by default. Please fix it. Thanks a lot in advance.

Thanks!

In T307320#7896338, @Func wrote:

Weird, I am able to "add" it without removing it first.

Note that the page was edited to change the zooming ratio.

This probably need a small fix: eliminators should be able to upload_by_url as well.