See also https://integration.wikimedia.org/ci/job/quibble-with-GrowthExperiments-extensions-browser-tests-only-vendor-php83/18451/artifact/log/GrowthExperiments/ReviseTone.cy.ts/

perhaps one of the existing rights in the page mover group on enwiki could be used as a hacky solution for signifying the right needed to move through the new protection level?

Had the intrusive thought of making supressredirects the requirement for moving move-protected pages... eugh. We /could/, but I really do not want to, and we can just put this user right into WikimediaCustomizations so I don't see why we should.

Some hanging questions:

1. When should we log? Should we log by default, or would it be togglable?
2. Where should the logging options be? Where the "mark this page as reviewed" checkmark is for the tag tab?

@Thilio can I close this? Seems to be fixed in my testing.

Also there does not seem to be any community discussion for this.

There is not, I'm working on a VPP draft right now.

Happening quite consistently now, search is unusable (no results show up, and after a couple of reloads there's a bot flag.)

Keeping this open since I still need to add the exclude username w/ the new UsernameLookup.

Might be useful, before the error occurred I was able to visit the homepage successfully; however when I searched for a paper the first time, some of the search elements were unstyled. After reloading the search CSS was not loaded at all, and after another reload it resulted in the bot flag.

I was able to reproduce this again just now.

I'm trying to make a tool that lets you view all TA contributions from an ASN's assigned ranges, and I really don't want to scrape Special:IPContributions to do this, which is why I'm looking for an API that lets users with TAIV access this data.

Claimin'.

Nope, can reproduce. Will submit a patch soon.

This should be fixed by the same patch that fixed T346399, though I'm not going to close until I get back home and verify.

This should be fixed by the same patch that fixed T346399, though I'm not going to close until I get back home and verify.

I'm going to claim all the wikicode tagging bugs since I recently "rewrote" (stole Novem's code) the toolbar tagging logic. I will hopefully be done with all of them in at most a week.

I'm going to claim all the wikicode tagging bugs since I recently "rewrote" (stole Novem's code) the toolbar tagging logic. I will hopefully be done with all of them in at most a week.

I'm going to claim all the wikicode tagging bugs since I recently "rewrote" (stole Novem's code) the toolbar tagging logic. I will hopefully be done with all of them in at most a week.

I'm going to claim all the wikicode tagging bugs since I recently "rewrote" (stole Novem's code) the toolbar tagging logic. I will hopefully be done with all of them in at most a week.

I'm going to claim all the wikicode tagging bugs since I recently "rewrote" (stole Novem's code) the toolbar tagging logic. I will hopefully be done with all of them in at most a week.

Whoops.

Asked Cursor to mock up a UI, thoughts on this?

Will try to patch tomorrow.

Oh! That'll be really useful. Thanks!

This has been open since... almost 3 years now. I'll try to submit a patch today. Note to self; en:Template:Hatnote templates has a list of hatnotes.

claimed, x2

It is working now, although the CAPTCHA is a bit slow.

Servis.006 is glock'd

Has only been happening with the quibble-vendor-mysql-php83 test; it affects all patches to extensions (and as such shouldn't be in extension-specific projects because they are not extension-specific)

Has been blocking merges for pretty much every extension on Gerrit for the past ~5 hours.

https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php83/

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/1330840

after trying again (and searching the codebase for 4 hours) i eventually decided to replicate the bug on testwiki.wiki to no avail. (which is weird since afaik this bug actually happened. maybe testwiki.wiki has a different config from this or smth? idk)

think i found the issue, it's with https://github.com/wikimedia/mediawiki/blob/master/includes/Content/ContentModelChange.php
will detail soon

oops, thanks for the clarification

@Pppery could you check to see if this isn't replication lag or something? Thanks in advance. (make a normal page that uses templatestyles to another page which is CSS content model, change the css's content model to sanitized, then clearing the cache of that original normal page(no null edit) 30 minutes later?)

Found the logic for checking content model, it's not a problem with templatestyles.
strike that for now, might actually be an issue with templatestyles but probably not