Thanks for the update, TheDJ. I might have structured the proposal a little differently if I'd known that doing things differently for new vs. current editors would be so difficult, but the way I did it probably made it easiest to achieve consensus. If ignoring inactive editors would make things easier, that probably would be fine, as they're unlikely to complain since they're, well, inactive.

Regarding WhatamIdoing's concerns, I think that's unlikely to apply if it's only new editors: they don't have prior expectations of the Wikipedia interface, so they're not going to have any attachment to a status quo or experience any disruption. We do want people to know how to turn it off, but that's what T174145 is for. Regarding the idea of a "tour" or pop-up box, I would be opposed to that, for the reasons I gave at the discussion. Copying here:

I would strongly oppose the pop-up box approach. When we think about the new editor experience, we need to be extremely selective about what information we present, as we want to get them to the point of having made a constructive edit before they give up. We're already asking them to read a lot of important things (e.g. copyright notice, plea to add references) and to decide between VE and source. Adding another box they have to click through builds the pile and introduces potential confusion (some people may think turning on syntax highlighting is activating the VE). I'd much rather use that valuable pre-edit moment to communicate core concepts like referencing than to explain this particular feature. We shouldn't force people to set up a whole comprehensive profile just to fix a typo.

In T288161#7292696, @Sdkb wrote:

Regarding WhatamIdoing's concerns, I think that's unlikely to apply if it's only new editors: they don't have prior expectations of the Wikipedia interface, so they're not going to have any attachment to a status quo or experience any disruption.

Many new editors were previously IP editors, and therefore do have some expectations about the interface. Some IP editors (for whom this ticket proposes enabling by default) have made thousands of edits over many years, and therefore also have some expectations about the interface.

We do want people to know how to turn it off, but that's what T174145 is for. Regarding the idea of a "tour" or pop-up box, I would be opposed to that, for the reasons I gave at the discussion.

Here's the problem that needs to be solved: People who use old (or otherwise underpowered) devices want to edit Wikipedia. Syntax highlighting makes the editing experience impossible or painful on some devices. A new editor opens a long/complex page with syntax highlighting enabled. Typing is very, very slow. How do you help that new editor?

Many new editors were previously IP editors, and therefore do have some expectations about the interface. Some IP editors (for whom this ticket proposes enabling by default) have made thousands of edits over many years, and therefore also have some expectations about the interface.

If IP editors care a ton about customizing their settings, they should register an account. We can't limit the rollout of features just so that IP editors will never experience any change; that would be complete folly.

Here's the problem that needs to be solved: People who use old (or otherwise underpowered) devices want to edit Wikipedia. Syntax highlighting makes the editing experience impossible or painful on some devices. A new editor opens a long/complex page with syntax highlighting enabled. Typing is very, very slow. How do you help that new editor?

I very much want to see the syntax highlighter code improved so that it doesn't slow down loading, and I hope that having this enabled by default will give the WMF some incentive to prioritize that. Loading times was an issue that you and others raised and discussed at the Village Pump discussion; the result was still consensus to proceed. Phabricator tickets are not the place for continuing or relitigating closed editorial discussions; they are for implementing the results of those discussions.

they are for implementing the results of those discussions.

That's an argument, but eventually any technical change is a developer decision. So if the developers who need to roll this out think that it would be a huge performance hit that is not tolerable to a significant part of the user base, they simply won't do it. Also CodeMirror is VERY complex optimizing is not easy. Google, Apple and others are literally paying a single developer to work on this, because they don't want to maintain that thing themselves. Do not underestimate.

I think that basically sets another requirement.. Someone needs to run a performance impact analysis.

@TheDJ, make sure to use the extension's code as it is after January 2021. We found and fixed a CPU leak that was able to block the browser for minutes when editing bigger pages. It was especially notable on pages with many very long lines. I suspect some of the performance-related concerns raised here are from users who experienced this before January 2021. That issue is fixed.

You can find flamegraphs that visualize the issue in T270317#6740027 and below.

Note that this issue was not in the upstream CodeMirror library, but in our custom wikitext highlighter.

That pair of flamegraphs show a significant improvement. Thank you for that work, @thiemowmde, and for linking it here.

I believe the other primary concerns have been about

• {{templates}} (specifically when you have typed the {{ but not closed it yet)
• extremely long pages (which are a problem for some editors even regardless of CodeMirror status).

@Sdkb, there is a gap between recognizing that have some expectations about the interface and never changing anything because of existing expectations. This would be a disruptive change. Some of the people affected by this change already have expecations about the interface; we can't change that. What we can change is how they experience the change. The most common way to manage that is to turn it on but make it easy for people to find a way to turn it off. (There are other options, like leaving it off and encouraging people to turn it on.)

In T288161#7311387, @thiemowmde wrote:

I suspect some of the performance-related concerns raised here are from users who experienced this before January 2021. That issue is fixed.

Actually I already knew about that improvement. My concerns for performance would be:

• Initial JS payload size
• reflows of content because of loading of late loading of CodeMirror (especially because the editor also changes font sizes for headings and applies bold etc). We've had years of reports where people were pointing out that when you start editing, before WikiEditor loads, that their cursor position would change and the part of the code that was visible in the wiki editor view. These issues were mostly solved, but for a long time were often experienced by users on slow connections. Adding CM adds an additional late loading stage to that 'simple' editor.

Can't we use the LocalUserCreated hook to enable the feature for new users going forward? DiscussionTools uses this for enabling email notifications (for new messages in subscribed sections) for new users. This would require adding a config option so that only interested projects enable it, so re-adding the project tag.

Change 754517 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/extensions/CodeMirror@master] Allow opting in to enable CodeMirror for new users by default

https://gerrit.wikimedia.org/r/754517

In T288161#7621912, @SD0001 wrote:

Can't we use the LocalUserCreated hook to enable the feature for new users going forward? DiscussionTools uses this for enabling email notifications (for new messages in subscribed sections) for new users. This would require adding a config option so that only interested projects enable it, so re-adding the project tag.

Two notes:

• This seems like an enwiki-specific workaround since for a missing feature (changing default preferences based on registration date) in core, not sure if extensions/CodeMirror is the best place for this or if it should be implemented somewhere else
• This has a potential to create a massive amount of rows to the enwiki settings table. Please ensure that DBA is fine with it before enabling it

This seems like an enwiki-specific workaround since for a missing feature (changing default preferences based on registration date) in core, not sure if extensions/CodeMirror is the best place for this or if it should be implemented somewhere else

LocalUserCreated hook is almost exclusively being used for setting user options, so it doesn't seem like a workaround to me. Echo does this for 5 preferences (!), DiscussionTools and Popups for 2 each; PageTriage, Thanks and Vector for one each.

Can't we use the LocalUserCreated hook to enable the feature for new users going forward?

…

• This has a potential to create a massive amount of rows to the enwiki settings table. Please ensure that DBA is fine with it before enabling it

That already happened: T286270: CodeMirror does not set a default for "usecodemirror" preference, causing user_properties bloat. Ideally we should not reintroduce what is effectively the same problem, but this went on for years before anyone noticed without any apparent performance impact. Not that that makes it okay :) Data redundancy should certainly be avoided.

In my opinion we should just enable it for everyone, and let those who don't like it simply turn it off. From the above discussion that implies T174145: Our standard highlight icon (used to enable/disable CodeMirror) cdxIconHighlight looks too much like our standard edit icon, cdxIconEdit is probably worth revisiting first.

What is the status of this task, WMF? I think it would make a real difference to editor retention and new editor engagement.

@Ganesha811: If there is anything specifically unclear with the previous comments, then please point out. The status is covered by the previous comments.

@Aklapper : to specify, is this actively being worked on by WMF staff? What timeline does the WMF see for implementation, for all IP users if not for logged-in users?

In T288161#8448595, @Ganesha811 wrote:

@Aklapper : to specify, is this actively being worked on by WMF staff? What timeline does the WMF see for implementation, for all IP users if not for logged-in users?

As can be seen from previous comments, the community asked for something , discussion ensued, a solution was not yet found.

WMF has no one allocated to figure out the details, implement it, fight with the community after it rolls out, and then refine it to the point that the community is happy ;)

@TheDJ : I see. Frankly, I don't really understand that perspective, since my understanding is that one of the WMF's primary functions is to support the community with technology and tools like this. The WMF could and should be more proactive here. I understand the community (collectively) can be challenging to deal with, but in the end we're all volunteers, while WMF staff are paid to work on things like this. It's the WMF's job (collectively) to implement MediaWiki changes and then refine them to make the community happy!

@Ganesha811: See https://www.mediawiki.org/wiki/Bug_management/Development_prioritization

As can be seen from previous comments, the community asked for something , discussion ensued, a solution was not yet found.

@TheDJ, I trust that you know how consensus works? The community reached a very clear consensus, which is to enable the syntax highlighting. A dissenting participant raising the same performance-related concerns here that they did at the discussion does not in any way nullify the result. (They also appear outdated due to the recent improvements to Syntax Highlighting.) If the WMF's goal is to avoid a "fight with the community", then disrespecting the consensus process is a very poor tactic.

On the technical issue of how to avoid creating excessive database rows, we proposed a solution above that is unlikely to ruffle feathers (turning it on for inactive editors), and no issues were raised. If that is not workable in some way, then tell us how and we can discuss further.

@Sdkb, you are addressing the wrong person. @TheDJ is not part of WMF.

@Sdkb I'm just explaining how it works, not stating that it is a good thing. I 100% agree that there should be a dedicated and funded team at the foundation that deals with these slightly more complicated requests. But there isn't, so it all depends on whichever employee decides to ignore their taskload/job and put some volunteer time into this.

Change 754517 abandoned by SD0001:

[mediawiki/extensions/CodeMirror@master] Allow opting in to enable CodeMirror for new users by default

Reason:

exacerbates user_properties table bloat issues

https://gerrit.wikimedia.org/r/754517

To take this forward, I think we need an RfC with consensus to enable this by default for all users (not just for new users – that's not happening).

I've filed T373710: Metrics instrumentation for CodeMirror 6 to get better metrics of various CodeMirror features in the upcoming CodeMirror 6 upgrade. This should help us decide what should be on by default. We will have data for both logged-out users, as well as registered users grouped by experience level (i.e. 0-50 edits, 50+ edits, 1000+ edits, etc.).

In T288161#9154585, @SD0001 wrote:

To take this forward, I think we need an RfC with consensus to enable this by default for all users (not just for new users – that's not happening).

@SD0001 This RfC opposed implementing another syntax highlighter shortly after in 2010: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_117#c-PaleAqua-2014-12-20T23:39:00.000Z-PaleAqua-2014-12-10T18:43:00.000Z

However, @MusikAnimal any luck on the T373710: Metrics instrumentation for CodeMirror 6? Maybe some fresh data, and that will convince the community. I can raise this up again mentioning T54777: user_properties table bloat, just to mention however I would have little knowledge but I haven't read the ticket really.

In the meantime, T321527: Support conditional defaults for user properties has been resolved and can be used to change the default for new users only. Since that's exactly what the ticket is asking, we can do that for now.

In T288161#11055481, @Waddie96 wrote:

However, @MusikAnimal any luck on the T373710: Metrics instrumentation for CodeMirror 6? Maybe some fresh data, and that will convince the community. I can raise this up again mentioning T54777: user_properties table bloat, just to mention however I would have little knowledge but I haven't read the ticket really.

There's a bug (T373710#10759352), but assuming most users have default preferences still enabled (older data suggests they very likely do), I think the data should otherwise be useful. Here's the numbers for August 6:

This is out of ~3.55K total uses of CodeMirror in the 2010 editor, across all wikis. (These features aren't available in the 2017 editor, so I'm not comparing against CodeMirror usage there).

Note also this refers only to users of the "Improved Syntax Highlighting" beta feature. We hope to be out of beta soon-ish, perhaps next month. That will then give us more data representative of the full editing community.

This task could proceed with CodeMirror 5 if we really want to, but I would advise against it. Imposing syntax highlighting on that many more users will bring more feedback to a product that will soon be permanently retired, so I say we should try to hold out for another month or two.

! In T288161#11069714, @MusikAnimal wrote:

This task could proceed with CodeMirror 5 if we really want to, but I would advise against it. Imposing syntax highlighting on that many more users will bring more feedback to a product that will soon be permanently retired, so I say we should try to hold out for another month or two.

Right, that makes sense.

Now that CodeMirror6 has fully replaced CM5 and we have conditional user options, this task is only waiting on T373710: Metrics instrumentation for CodeMirror 6 to refine which options are default-on, right? Or is there something else too, or can we move forward right now?

[ Edit: Also maybe T286623? ]

The metrics instrumentation needs some work to be more accurate, but I imagine English Wikipedia would be able to decide for themselves what should be the default preferences without any metrics. The metrics only account for users who deliberately changed their CodeMirror preferences, so they still don't speak for the majority of users who don't change anything.

T286623 is unrelated and not a blocker.

In talking with @Sdkb and others, we are ready to try this again now that CodeMirror 6 is fully rolled out. The 2017 editor integration will also see great improvements in the near future (T432558).

In T288161#7287663, @TheDJ wrote:

by default for new editors

Just to clarify this is a very tricky part of this request (as @Majavah was implying as well). The only way to realise this, is to create a database migration, take ALL registered users WITHOUT this preference, SET the existing default for them, and then switch the default for all editors.

We tend not to do this, because it creates a ton of unnecessary rows in the database, esp considering that most 'current editors' are actually non-active users..... While this has been done in the past a few times, I can't remember the last time (maybe something VE related?).

So there are two parts to this ticket really:

• switching for anonymous editors is easy and a config change.
• switching for new editors requires custom code (migration script) that has to be run, followed by a config change (probably approval by DBA too actually)

I believe this issue still stands. Temporary accounts don't get preferences, so I think the behaviour will be the same as it would be for IPs. We do however support clientside preferences, so temp accounts can still turn off CM in a session.

As for new accounts, I say we avoid the hassle mentioned above and just set the default preference to enabled, and let users who don't want it simply disable it.

And then there is the potential confusion, pointed out by @Whatamidoing-WMF, which possibly could be solved by an editor tour or something, pointing out to first time users where the button is and what it does... (more custom code)

This also still stands. Sdkb suggested a guided tour-like thingy. It can be done, but I worry it could get annoying if we go with the conventional cookie-based route used by Extension:GuidedTour (users would need to dismiss the tour on every new device or after cookies are cleared). Maybe we should use a hidden preference instead? If that's only effecting named accounts, I think that's OK. We'd keep the guided tour around only for about a month or so, mainly for the benefit of existing users who are suddenly presented with CodeMirror when they weren't before.

Next, it's important to remember while WikEditor is the default experience for new accounts on enwiki, existing users may be using the 2017 editor or vanilla CodeMirror (2003 editor), and the guided tour would need to be different for those. But, since WikiEditor is the default, maybe we can forego the guided tour for the other editors. If VE has something built-in for it, then sure, we can use that, but otherwise it's asking for too much I think.

How does the above sound?

In T288161#12173278, @MusikAnimal wrote:

In T288161#7287663, @TheDJ wrote:

by default for new editors

Just to clarify this is a very tricky part of this request (as @Majavah was implying as well). The only way to realise this, is to create a database migration, take ALL registered users WITHOUT this preference, SET the existing default for them, and then switch the default for all editors.

We tend not to do this, because it creates a ton of unnecessary rows in the database, esp considering that most 'current editors' are actually non-active users..... While this has been done in the past a few times, I can't remember the last time (maybe something VE related?).

So there are two parts to this ticket really:

• switching for anonymous editors is easy and a config change.
• switching for new editors requires custom code (migration script) that has to be run, followed by a config change (probably approval by DBA too actually)

I believe this issue still stands.

Actually, T321527: Support conditional defaults for user properties allows us to make preference defaults conditional on user registration date, so it would be fairly trivial to achieve this effect (as I understand it).

I say we avoid the hassle mentioned above and just set the default preference to enabled, and let users who don't want it simply disable it.

Personally, I agree; but if enwiki still wants it only for new users, that's now technically feasible and thus a wish we could easily grant.

Wee! T321527 is news to me. With that as a possibility, there's little reason to not apply it to new users only, as that would the path of least resistance. It would also mean we have a new generation of editors who are born with CodeMirror, which will surely blossom into something special. (We all like how we started, that's just how it goes… software change bias is real!)

Thanks for pointing this out, @Mr._Starfleet_Command :)

You're welcome!

Change #1338308 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[operations/mediawiki-config@master] [CodeMirror] enable for new users (enwiki), new VE integration (global)

https://gerrit.wikimedia.org/r/1338308

In T288161#12305756, @MusikAnimal wrote:

I'm planning to deploy this tomorrow (Thursday, September 10) around 21:00 UTC, along with the new "Highlight" version of the VE integration (T432558).

CSS custom highlight is a very recent browser feature, especially for Firefox.

I should have made it clear that new users on English Wikipedia, specifically, are forced into WikiEditor, not the VE 2017 editor. You'd need to create a new account in order for preferences to stick, and even then you'd need to know the 2017 editor preference exists (related: T436607). Apples to apples, I still think the new VE Highlight version is probably less error-prone overall.

We can still wait and do the T432558 deployment separately, if there is dispute.

Change #1338308 merged by jenkins-bot:

[operations/mediawiki-config@master] [CodeMirror] enable for new and logged-out users by default on enwiki

https://gerrit.wikimedia.org/r/1338308

Mentioned in SAL (#wikimedia-operations) [2026-09-10T22:01:00Z] <musikanimal@deploy1003> Started scap sync-world: Backport for [[gerrit:1322175|CodeMirror: turn on the new 2017 editor integration (T432558)]], [[gerrit:1338308|[CodeMirror] enable for new and logged-out users by default on enwiki (T288161)]]

Mentioned in SAL (#wikimedia-operations) [2026-09-10T22:05:46Z] <musikanimal@deploy1003> kemayo, musikanimal: Backport for [[gerrit:1322175|CodeMirror: turn on the new 2017 editor integration (T432558)]], [[gerrit:1338308|[CodeMirror] enable for new and logged-out users by default on enwiki (T288161)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-09-10T22:12:00Z] <musikanimal@deploy1003> Finished scap sync-world: Backport for [[gerrit:1322175|CodeMirror: turn on the new 2017 editor integration (T432558)]], [[gerrit:1338308|[CodeMirror] enable for new and logged-out users by default on enwiki (T288161)]] (duration: 10m 59s)

Deploy didn't go so well… I got something wrong in the logic and users who previously had CM enabled would suddenly have it disabled. No good! I was going to get a fixed version out before 00:00 UTC, but the day job hijacked my time.

This will have to wait until Monday. I had advocated for Thursdays before given that's when enwiki is used to changes (WP:THURSDAY), but I don't care to wait that long, and it's arguably better to do it off-schedule as it helps users distinguish config changes from the train.

Change #1341273 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[operations/mediawiki-config@master] [CodeMirror] enable for new users (enwiki), new VE integration (global)

https://gerrit.wikimedia.org/r/1341273

Change #1341273 merged by jenkins-bot:

[operations/mediawiki-config@master] [CodeMirror] enable for new users (enwiki), new VE integration (global)

https://gerrit.wikimedia.org/r/1341273

Mentioned in SAL (#wikimedia-operations) [2026-09-14T19:04:34Z] <musikanimal@deploy1003> Started scap sync-world: Backport for [[gerrit:1341273|[CodeMirror] enable for new users (enwiki), new VE integration (global) (T288161 T432558)]]

Mentioned in SAL (#wikimedia-operations) [2026-09-14T19:22:15Z] <musikanimal@deploy1003> musikanimal: Backport for [[gerrit:1341273|[CodeMirror] enable for new users (enwiki), new VE integration (global) (T288161 T432558)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-09-14T19:38:25Z] <musikanimal@deploy1003> Finished scap sync-world: Backport for [[gerrit:1341273|[CodeMirror] enable for new users (enwiki), new VE integration (global) (T288161 T432558)]] (duration: 33m 51s)