We're going to revert this and try a different approach (add a new SQL field). It's causing too many bugs. A third bug was reported today.

Another regression caused by T412014: Special:NewPagesFeed NPP mode (not AFC mode) should show and sort by enqueued date, not creation date. We'll probably roll back that patch shortly.

I plan to update the timestamp when undeleting in a follow up patch. I've got a check box for it in the ticket above, [ ] undeleting an article. I am busy for a month or two though. Will have time to work on this end of March maybe. Feel free to remind me around then!

That's super neat. Bookmarking!

In T415653#11562108, @zeljkofilipin wrote:

In T415653#11562056, @Michael wrote:

The CI error is unexpected

Sorry, I was referring to MediaWiki-Quickstart (Docker) CI. It's a separate CI.

Here's my LocalSettings.php configuration for PageTriage, if this helps.

Quickstart uses SQLite by default

Recommendation from discord: ssh into the root directory and do du -l | sort -n

Twinkle uses the edit summary Adding [[xyz]]., so +1 to the idea of this.

I'm able to reproduce.

Judging by the patch, this is probably a regression caused by T412014. Mentioning here for cross-linking.

An editor has raised an objection to this change at https://en.wikipedia.org/wiki/Wikipedia_talk:New_pages_patrol/Reviewers#Recent_reordering_of_Special%3ANewPagesFeed_by_date_enqueued_rather_than_date_created and seems like they want it reverted. Feel free to join the discussion.

Unable to reproduce. Looks fixed now. I'd be OK with closing the ticket. Thanks to Sohom and Jason for fixing this.

I don't see krb: present in the patch, so looks like this was done as level 2 instead of the requested level 3. Is this correct?

I was able to reproduce on enwiki. The 2nd, 3rd, 4th etc. chunks are identical.

This deployed a week or two ago. Hasn't generated any negative feedback that I've seen. And the back of the queue now looks like this:

Would recommend reverting to no space everywhere. 1) It was fine that way for many decades. 2) Adding a space in some places (displayed page title) and not others (mw.config.get('wgPageName')) introduces unnecessary complexity / inconsistencies / technical debt. It's likely to result in people writing it both the old way and the new way forever, which is confusing. Right now everyone writes it (e.g. creating wikilinks on talk pages, creating wikilinks in projectspace, etc.) without a space and this is simple and elegant and consistent.

I don't necessarily have any objection to anyone else doing the same thing for ruwikinews; but I'm just holding off myself at the minute, given the length of time since https://gerrit.wikimedia.org/r/455232 was merged for T201265 in 2018 (ie., in case it'd be a surprise to [some editors on] the wiki for this config to be suddenly changed at this point).

Would it make sense to say that assignments of all permissions from the FlaggedRevs extension should be set in flaggedrevs.php, so that they're all in one place (and in case e.g. another user-group is given a FlaggedRevs permission default from that file in the future)?

Are you requesting deployment access?

Any tips for disabling this locally? I'm interested in keeping Gerrit patch notifications at a higher weight than things like subscribing to the ticket (i.e. how things used to be).

Sounds like you need analytics-privatedata-users level 1

Possibly relevant lines of the integration/config/layout.yaml file:

Sounds great. Thank you for the update.

Hello friends. Happy new year. I hope you enjoyed some time off. Was wondering if there were any updates/ETA on this one?

In core, I can't get PHP 8.5 CI to trigger using check experimental or check php. I think check experimental would be a good spot for it if I'm reading the documentation correctly.

What are the steps to reproduce? I was under the impression that the sidebar always has this link.

Good food for thought. But I still worry about it being an infinite queue (never reaches zero backlog) even with the 1 month dropoff.

This would be pretty hard for enwiki:

https://en.wikipedia.org/wiki/Special:Contributions/~2025-39990-81 was mentioned on Discord as a possible example of this.

This is still happening. Here's 2 examples from today:

If we're sure the bug is in https://commons.wikimedia.org/wiki/Module:Graph:Chart , and not in https://www.mediawiki.org/wiki/Extension:Chart or https://www.mediawiki.org/wiki/Extension:JsonConfig , then this ticket may be filed in the wrong place and we might want to close it as invalid.

Sounds like there isn't support for this. No worries. Will close it. Thanks for the feedback. Happy holidays :)

I agree with the sentiment that all code has a maintenance cost. Because of 1) complexity and 2) bitrot. It's very hard to say with certainty that a line of code will "require zero maintenance" ever again. I see maintenance done on code all the time. And if I'm reading other code in that file and stumble across this hook and I spend 5 minutes trying to figure out why a hook is there for an extension I've never heard of, that's complexity and it has a cost, even if I don't end up writing a patch that modifies that code.

Some folks make good arguments to not bring back ST47ProxyBot, although a bot to block VPNGate is mentioned as a good idea.

Patch that introduced the PatrolManager service: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1180672

Sure. Feel free to take over. I meant to write one but got sidetracked.

The Peast library, which is already installed in MediaWiki and has passed security review, supports generating abstract syntax trees for JavaScript. Perhaps a patch could use that to detect where JavaScript comments are.

Any thoughts yet on what version of PHP we should target next? 8.4 or 8.5? Picking this would let us create the next ticket in the series, since this one is close to wrapping up.

In T412824#11466490, @Bawolff wrote:

Could we keep parsing and disable PST?

Thanks for that info. This was the problem:

I think applying for logstash access is now done by visiting https://idm.wikimedia.org/permissions/ and filling out a short form. Hope that helps.

There's an official checklist for decommissioning an extension at: https://phabricator.wikimedia.org/maniphest/task/edit/form/33/. Might want to compare your list to that one to make sure nothing was forgotten.

Thanks for the update. Will check back in next month. Happy holidays :)

Hello friends. Thanks for your consideration. Any updates/ETA?

Ah, I see. Thanks for the explanation. I think I understand the bug you're reporting, but I couldn't reproduce it in localhost with the following steps. If you can help me get these steps correct, I'll write a patch for it:

the counter of pending-changes at Special:PendingChanges hasn't updated following the removal of these namespaces