Wed, May 12
Mon, May 10
Okay, there is now documentation at https://www.mediawiki.org/wiki/Manual:Revision.php/Migration#Hooks for all of the hook replacements except for ParserFetchTemplate -> BeforeParserFetchTemplateRevisionRecord which I don't understand how to update
Forgot to close this earlier - now uses WVUI for everything possible, will continue to update as WVUI gets more features
@Aklapper you marked this as having been fixed upstream with a patch merged there - is there a timeline for when that will be deployed to the WMF phabricator instance?
Sun, May 9
I'm happy to take a look at patches if you want. A basic migration guide to just fix the Revision uses is dumped below (and I'll probably write this better and post it somewhere easier once the class is fully removed). Doesn't cover all of the hooks, just those that translatewiki uses in extensions as far as I can tell (including those that appear used in semantic mediawiki).
Thu, May 6
Was about to file a ticket for this, but found this task. Added some notes
Selecting the user ids for users that have a given mentor, where the user is not a bot, the user is not indefinitely blocked, and the user either registered recently or has an edit. Formatting and order below is kind of ugly
$tables = [ 'growthexperiments_mentor_mentee' ]; $fields = [ 'gemm_mentee_id' ]; $conds = ; $joins = ;
Can I suggest not just mass replacing with UserFactory if the uses are eventually going to be replaced with UserIdentityLookup or similar and migrated to UserIdentity/Authority?
@Vlad.shapik for future reference for these tasks and patches, they are for *replacing uses of the methods* in the different extensions, so the methods can be hard deprecated in core, and should be named accordingly - its confusing to see tasks and patches saying hard deprecate the methods in a bunch of extensions
Wed, May 5
From gerrit. reformatted a bit, but its a bit messy
I left a bunch of notes, but in general I don't think this is an improvement to the UI either with or without action blocks being enabled. I created 3 patchdemos for testing (the relevant fourth, no action blocks and without this patch, is just production)  and tried them out - based on my own experience with blocks as a sysop, the old interface was more intuitive. But, that might just be me - can I suggest soliciting feedback from other sysops?
The standard "read only" banned is misleading in this case - the window will not be preventing edits, just a couple of other actions (see task description) - is it too late to clarify this?
Tue, May 4
Something I noticed testing a different patch on patchdemo (without this redesign, but with action blocks enabled):
- Risky Patch! 🚂🔥
We can use some of the logic in AssertCountSniff to skip past the first parameter - will try to work on this soon
Mon, May 3
Sun, May 2
Okay, we're getting close! Current status:
First couple patches, removing the hooks that use Revision objects and starting to remove deprecated support for Revision in other places, has already merged and will go out with the train.
Next batch is ready to go, but I'm waiting until after the train to split them up a bit. Once https://gerrit.wikimedia.org/r/c/mediawiki/core/+/683964 merges, the only remaining use of Revision in core will be in the Revision class itself, and in its tests. At that point
- update extensions that, like core, supported deprecated Revision object parameters: Wikibase (repo), EntitySchema, and Parsoid
- Wait for a new version of Parsoid to be tagged and deployed to vendor
- Wait at least a week since the rest of the changes to remove the uses of the Revision class in core
Then we can merge the actual removal (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/684071)
- Risky Patch! 🚂🔥
Sat, May 1
Fri, Apr 30
The original issue for the signpost was resolved after a few hours
Thu, Apr 29
(this is a configuration change, not a change to the extension itself)
Wed, Apr 28
Not sure what the root cause is, but sent a hotfix to replace the php error with a nicer PermissionsError
+1 from me, active developer and trusted on production wikis
Mon, Apr 26
Sun, Apr 25
Might qualify for UBN, not sure
Sat, Apr 24
I've marked Rename Phabricator project as done, @Aklapper took care of that https://phabricator.wikimedia.org/project/manage/210/#77240
Fri, Apr 23
Thu, Apr 22
There is a pending patch (https://gerrit.wikimedia.org/r/c/mediawiki/libs/ObjectFactory/+/676348) to move the code to a new namespace Wikimedia\\ObjectFactory\\ instead of just in Wikimedia\\, suggest including that within the next release (and that would probably warrant making it 3.1.0 instead of 3.0.1)
Wed, Apr 21
Nothing more to remove before 1.36 is tagged, new work is at T262707: Remove core fallbacks to global $wgUser [1.37]
Tue, Apr 20
@Daimona the patch I sent fixes this for the code that implements these hooks, do we also want to suppress the warning on the interfaces themselves? Or should we leave it to make sure that new hooks being introduced don't have underscores in them?
renaming to "permission checker" would be changing the meaning and scope, and should not be bundled with fixing the actual name - instead of "otrs-member" it should be "vrt-member" or whatever the migration group decides
Sat, Apr 17
Fri, Apr 16
It might have been a duplicate, but that other task should probably be merged here since this is where everything is. Plus, there are open patches for this task
Should be easier to do once T157658: Factor out a backend from EditPage merges