Yup, I'm seeing very slow times too, and I have a fiber optic 500 Mbps connection.

Making it clear here as well to any readers that T440077#12438425 was a bad deploy on my part, and was nothing intentional. See T441308 for details. I deeply apologize and am well aware how sensitive and costly it is to force changes to existing editor workflows, being a long-term editor myself. This is why most everything under umbrella of CodeMirror has a means to turn it off. It's supposed to be kind of like an IDE, where we offer the power to do the otherwise impossible, but opt for configuration over forced convention.

CodeMirror does not cancel an existing auto-completion search request

In T408729#12440172, @Bhsd wrote:

Could you explain what you mean by "two linters potentially disagree"?

Thanks @Mr._Starfleet_Command! That indeed looks more correct and elegant. mw:Manual:$wgConditionalUserOptions has been around for 2.5 years but I somehow missed it… I've been deducing the functionality through reading the source code. In a panic to get a fix out today I went with what I tested to work.

I was asked to create a task for making the slugs localizable, but I'm hoping it will be easy enough to squeeze that into this task. There is already a convention in MW extensions to have a myextension.i18n.alias.php for Special page aliases and magic word aliases (they can both be in the same file and often are), so we could potentially utilize the same paradigm. I am time boxing this effort and if it turns out to be too much work or is otherwise complicated in any way, I will file a separate task instead.

Okay I think we're good! Confirmed by first querying the production DB to ensure my alt account, MusikPuppet, in fact had no row in user_preferences on enwiki for usecodemirror, meaning it will resort to the default. Before the config change, CM was on (because it fell back to the default set in extension.json), and after deployment, it was off (now that we have the [ 0, [ CUDCOND_NAMED ] ] condition).

In T441308#12438726, @MusikAnimal wrote:

We could just patch master to have usecodemirror off by default in the extension. That will fix it, but it can't stay that way because it's supposed to ship in MediaWiki with it on by default.

I guess I'll do the above until support for CUDCOND_BEFORE is added.

We could just patch master to have usecodemirror off by default in the extension. That will fix it, but it can't stay that way because it's supposed to ship in MediaWiki with it on by default.

I'm not sure there's a way to even fix this, unless we add support for a CUDCOND_BEFORE to ConditionalDefaultsLookup.php.

In T441308#12438676, @MusikAnimal wrote:

I think what we need is a [ 0, [ CUDCOND_BEFORE, '20260910000000' ] ] added to the enwiki config. I'll get that prepared now.

I think the above will fix the primary issue, but the Core/global preferences bug will still be present.

I can say my WMF account had CodeMirror off on enwiki, and it stayed off when I tested r1352288 during deployment. But today (not yesterday!), indeed it suddenly got turned back on.

Possibly related to the issue that was brought up at https://www.mediawiki.org/wiki/Help_talk:Extension:CodeMirror#Enabling_CodeMirror_by_default_on_all_WMF_wikis_for_newbies

Not testable, but PR is very straightforward. Just going to declare resolved.

All that needed to be done was done. Thanks to everyone who helped! T440077 remains open while we wait for feedback from the Wikimedia community, by MW 1.47 will ship with CodeMirror on by default.

There was some discussion about this at T404198. It was a while ago so things may have changed.

In T404198#11603085, @Samwalton9-WMF wrote:

… Do we have any insight on whether CodexHTMLForm has the features we require yet?

I noticed at https://en.wikipedia.org/wiki/Special:Nuke?nukeUI=codex the <form> element is still mw-htmlform-ooui. That's why the form looks so wide in Codex.

The WikiNav API is currently down (I've reported this). When it's back up, I'll get this implemented.

Deployed! Sorry for the delay.

I spoke with Movement Comms about this. The plan is to announce this change is upcoming via Tech News, give communities a few weeks' time to give feedback, and then if all sounds OK we'll make the switch. I've gone ahead and made an entry in Tech News for the initial announcement: https://meta.wikimedia.org/w/index.php?diff=31140921

Reworded to reflect reality. See discussion at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CodeMirror/+/1340535/comments/d5cca3b8_96805fcb

I suppose this is now redundant to T400015. Re-open if you disagree.

Replied there; I don't think adding a redirect/alias will be a problem.

Just to be clear, can you confirm this only happens while CodeMirror is enabled? Also, does disabling Realtime Preview help at all?

QA'd on testwiki. With personalization turned off, only recent changes are returned by the feed API.

QA'd on testwiki. Looks good, thanks!

QA'd on testwiki. Looks good!

For redirecting, I would suggesting using the normal special page aliases. So just rename the key the Home and add Homepage as the first alias, and same for each translation. Maybe leave a comment to the effect of "All aliases listed here should also include historical aliases for Homepage."

CodeMirror should install just fine with the web installer, given it has no additional installation steps. What is odd though is that no one gets syntax highlighting at all unless it is manually turned on individually by each user – that, and all the integrations (JsonConfig, TemplateStyles, etc) still force users into CodeEditor unless a sysadmin configures it otherwise.

I've filed T440077: Enable CodeMirror for wikitext by default on all wikis which I think should supersede this. Closing as declined. Please re-open if you disagree.

I don't think T400014 will get done in time, and that's OK.

action=edit feels more right to me… akin to how Special:LintErrors works. As a module maintainer, I would want to fix the error. It could be annoying to have to first load the action=view, then have to re-find it when I go to edit. For users who can't edit the module, they'd still get a readonly editor.

In T373710#10759352, @MusikAnimal wrote:

I spoke to soon. It seems there's now no reporting of a preference if it matches the default. I.e. I don't see prefs-lineWrapping or prefs-lineNumbering in the chart

Thanks for reporting. I've disabled the click-and-drag zoom for touch devices.

I have made the auto-logarithmic switch less eager, and changed the label for values that can't be plotted to "N/A".

It's because the logarithmic scale is automatically being shown due to the spike on September 13. With a logarithmic scale, it is impossible to have a value of zero. This should still be fixed, but the NaN is technically an accurate representation of the data. I suppose "N/A" (for not applicable) is better messaging.

This should go through QA first I suppose.