Oops. I guess I misremembered this part. I guess jsdoc does need to be installed alongside jsdoc-wmf-theme.

PS1 - Unable to reproduce in PS1 since the module example wasn't in there.

Can you please put what you're trying to do to EventLogging into a gerrit patch and link it here? I tried installing the EventLogging repo and pasting your config and doing npm update to reproduce, but there aren't any modules. Would appreciate an easy steps to reproduce :)

Sorting by name doesn’t seem to me particularly useful, particularly with the search capability. I would gladly give it up if it keeps other features from being implemented

Got some more today.

Very nice. Any interest in adding a third column that displays the special page name in an unhidden way? So for example, Special:ListDuplicatedFiles instead of "List of files with duplicates". I think this would make the page more useful to developers.

There's talk of people experiencing circuit breaking on commons and enwiki in this recent ticket. Related? T394503: Database circuit breaking on enwiki (2025-05-16)

Howdy ticket watchers. It's 2025, and this comes up frequently in other contexts, so I am just wondering what folk's thoughts are on the accuracy of LLM detectors nowadays? Are they better than when we first discussed this in 2023, or still pretty inaccurate?

Did this make it into Logstash via an explicit PHP error or an explicit JS error? If not then this should probably be changed to type "bug report" and the "Wikimedia production error" tag should probably be removed.

Another option is a message could be automatically prepended in the case of a redirect. "(This message was sent to User talk:ABC and is being posted here due to a redirect.)"

Got it. So the fix is probably to cherry pick 657c9cc4c50b3c1c8afdc573ca21fc714d6b8f07 into CentralNotice -> branch wmf/1.45.0-wmf.1.

I got a couple more of these today.

So this patch passed FlaggedRevs CI but broke CentralNotice CI? And only for branch wmf/1.45.0-wmf.1? Interesting.

Nice. I have a user script that puts a "log" link on every page, and opens a little panel with all the log entries for that page. Once this patch rides the train, I suspect I can click this, and reliably see if the page has ever been history merged (since the date of the patch anyway). 👍

Do we want to backport this to keep log spam down?

A magic word might be the way to go here.

Will leave this open in case anyone wants to fix the test.

Steps to reproduce

• make sure $wgFlaggedRevsProtection = false;
• be an admin
• go to the page protection screen
• at the top, there is text that says "This page does not have a stable version; page stability settings can be configured.". Click "Configured"
• this will take you to a page such as http://localhost:8080/w/index.php?title=Special:Stabilization&page=Test5, which has the deprecation warning.

Seems like a really minor bug to me. I don't think it needs to be a train blocker / don't think it needs a backport. Special:NewPagesFeed still works, it just doesn't auto fill the username text box when filtering by username, then closing and re-opening the filters panel.

Oh I think I see what you mean now. One starts with gadget- and the other starts with gadgets-.

It seemed OK to me. Do you have a suggestion of what we should change it to?

Looks like a global search for "stableid" turns up 820 hits. Will go ahead and modify my patch to support redirecting ?stableid= to ?oldid= so as not to break these.

May I ask what this ticket would entail on the technical side to implement? Is the limitation due to contenteditable and all the fun that comes with that? :)

My current work in progress patch deletes the feature, but I can be talked
into having stableid redirect to oldid if folks think it's a good idea.

The below grey box is the only thing that links to ?stableid=.

I assume this is the code in question?