Just a note this has not been forgotten about! Higher priorities are in the way right now but I hope to have this fixed by the end of the week.

I'm told there was an outage that has now been fixed, and Data Engineering is working to backfill the data.

See also T394707: Do something about misconceptions of the wikipage.content hook

I would think we should allow it to be resizable both horizontally and vertically everywhere, except wherever there's a conflicting layout, like ProofreadPage (where we want vertical-only).

Possibly should be UBN.

FYI https://wikiwho.wmcloud.org is currently errorig out because zh is not a known language code to Django. I'll work on this tomorrow. There are no service disruptions to the APIs (except for the newly added Chinese APIs).

I saw we were getting close to being full again. Since we're adding so many more languages right now (T372340), we're logging a lot more things, too! The main WikiWho API handler was printing the API params to stdout, which got logged. I don't think we need to log this information, and even if we do, it should just be the page ID or something, and not all the other API parameters that are always the same.

I was pondering about this today… It might be difficult to devise any meaningful shortcuts unique to AbuseFilter, but we could still give editor-related buttons just like you see in non-wikitext?

In T399673#11832007, @Escargot_rouge wrote:

As a user without abusefilter status, I still have the CodeEditor view of AbuseFilter. Is it the expected behavior?

Announcement added to the upcoming Tech News: https://meta.wikimedia.org?diff=30417424

Announcement added to the upcoming Tech News: https://meta.wikimedia.org?diff=30417424

My previous comment (now deleted) was inaccurate. There's a legit issue here. Looks like we need to update some queries following the removal of the il_to field of the imagelinks table.

I see value in the JS interface regardless, so yes, let's do it :)

In T386436#11817485, @Mr._Starfleet_Command wrote:

Adding CodeMirror tag since auto-linking could likely be applied to it too, similar to the suggestion for SyntaxHighlight (see T419335: Add CodeMirror auto-linking where missing).

Thanks for the help! :)

I don't know who to ping here. UploadWizard has no code steward, and the author of the tests is @MarkTraceur who appears to be inactive.

In T259059#11826743, @Jdforrester-WMF wrote:

CodeMirror isn't yet in the tarball, so unless you're adding it really swiftly this is just dropping the functionality for third parties, right?

Okay! Done. I'm hoping CodeEditor will be all but completely replaced by MW 1.47, but either way yes, we will at least be able to change the default values in favour of CodeMirror.

In T259059#11822761, @Bhsd wrote:

I just wonder what will happen if a third-party wiki installs both CodeEditor and CodeMirror without manually changing the extension configurations?

The conundrum so to speak is that in order to promote CodeMirror 6 from a beta feature, it would also come with replacing CodeEditor. Or at least, doing it in one fell swoop makes it much simpler.

r1271263 is the change to the WMF configuration. All other relevant patches may be found at https://gerrit.wikimedia.org/r/q/topic:%22codemirror6%22+status:open . Any help with code review is appreciated.

See also discussion over at T419332#11821789. It sounds like we're still good to at least change the default config settings in MW 1.46. For this task (retiring CM5), I would also like to remove the old modules. At any rate, there will be nothing backported to MW 1.46 that hasn't already been battle-tested in WMF production.

Sorry, I guess I didn't understand when was the appropriate time to remove the tag. Frankly I'm still confused, but whatever, so long as I can get these config changes into MW 1.46, I'm happy :)

The task description is a bit misleading; We're not removing CodeEditor just yet (it's still being used in some places like WikiLambda, as you know).

In T419332#11821789, @Jdforrester-WMF wrote:

@MusikAnimal: The last production alpha branch of 1.46 was cut last night, I'm afraid. Should we re-target this to 1.47?

Following T184857, CM + 2017 editor is limited to pages no larger than 250K bytes in size. That should be enough, since we really only see the misalignment with large pages.

I'm going to declare this as resolved. A nice follow-up would be to measure the time CM takes, and if that exceeds some reasonable threshold, then we auto-disable CM. However this doesn't appear to be very straightforward to do.

Add tabular dataset field that allows users to choose the .tab page that contains the dataset.

we just need to adjust the code to work with the new MediaWiki Content File Exports format.

QA notes in addition to the task description:

I got the official start on this tonight only to run into two new problems:

Alright! After a lot of tedious work, I managed to get our benchmark article [[Barack Obama]] back in production (gzip'd and in the new directory structure). I've re-deployed PR #22 and #23 to production, and things seem to be running swimmingly!

In T413459#11806084, @1234qwer1234qwer4 wrote:

It should be possible to add the closing bracket (and I would suggest adding the closing tag as well) yet leave the cursor before the closing bracket (or in between the opening and closing tags... a lot of common tags from MediaWiki are used without attributes).

Alright, [[Barack Obama]]'s pickle is back, hehe :) In my testing, it takes about the same amount of time to load as before T414075, maybe slightly faster, but certainly not slower.

Updates: I think I discovered a related bug or two and have some fixes I will submit soon. As for [[Barack Obama]], specifically, I realized using Special:Export both adds the unwanted <origin> tag, and also it is limited to a maximum of 1,000 revisions. Instead, I tediously went through the raw dumps to find the one containing [[Barack Obama]], and edited the ~17GB XML file to include only the desired page (which is still 5GB by itself!). Now I'm trying to import that, but keep running into timeouts. I've increased the timeout threshold and am trying again. This could take hours, it seems!!

With r1269544, I have changed the shortcut to Ctrl-e, which was another suggestion made at T420524#11725874. This is the keyboard shortcut for 'Edit this page' in some browsers, but that shouldn't be conflict when the user is already editing the page.

please change keyboard shortcut for inserting math tag as it conflicts with ULS - T421333: Math formula (inline) button uses Ctrl-m shortcut already in use for ULS preferred alternative keyboard

T233652 and T420558 don't really involve much on the frontend, and we don't use Python at all.

Okay, closing!

I guess this could use a shoutout in Tech News ahead of time, in the event there are other user scripts and gadgets like T399673#11693805. I've added an entry to the next issue and will wait until Thursday, April 16 to deploy r1268652.