Page MenuHomePhabricator

Explore ways to offer CodeMirror as a distinct alternative to other wikitext editors (tracking)
Open, LowPublic

Description

Background

MediaWiki-extensions-CodeMirror has evolved into a diverse editing environment with numerous preferences, features, and an extendable interface. Up until 2026, it was available only as an opt-in feature of WikiEditor (2010) and VisualEditor-MediaWiki-2017WikitextEditor. Since then it is also available as the so-called "standalone CodeMirror" — the 2003 editor (plain textarea) with CodeMirror on top.

The only thing keeping CodeMirror from being perceived as a different editor from a user perspective seems to boil down to a toolbar. This can be created, hopefully with backwards-compatibility with WikiEditor.

Where we are today (September 2026)

The Wikimedia cluster has two checkbox preferences allowing you to change the "editor":

  • Enable the editing toolbar (This is sometimes called the '2010 wikitext editor')
  • Use the VisualEditor toolbar—which includes the automatic citation tool—in the Source editor too (This is sometimes called the '2017 wikitext editor'.)

On top of that CodeMirror, is offered as the "Enable syntax highlighting" and "Enable syntax highlighting for code" preferences, even though it does a lot more than syntax highlighting.

Problem

CodeMirror is branded as the "syntax highlighting" feature, but yet it offers enough features that users are genuinely confused about how to turn it off or adjust its settings, even with a "Syntax" button glaring at them. After all, it's possible to use CodeMirror without syntax highlighting (T419339)! So to say the least, the nomenclature needs revisiting. Simply calling it "syntax highlighting" is insufficient. It is a full-on stream parser offering IDE-like functionality, and I think ideally we'd preset it to users as such.

Newbie birds-eye view back at the preferences, at first glance WikiEditor implies it's the only option with a toolbar, yet the 2017 editor offers one too. Secondly, the two preferences are mutually exclusive, yet presented as checkboxes as if both can be true.

In the case of the 2017 editor, not much more needs to be said for CodeMirror, because it is only used as a syntax highlighter. You get a toolbar, and an option to enable syntax highlighting. But for the 2010 editor, it radically changes the editing experience. Users get confused, stuck, and don't know how to or if it's possible to tweak the various settings (T425739, T434695). Meanwhile, some projects want to enable this for all new users by default (T288161).

Fortunately, the one thing that does seem intuitive is the concept of "visual" versus "source" editing. So the problem then just lies on giving users the ability to change which wikitext editor they normally want.

A collection of ideas
  • Rename the "Syntax highlighting" preference to something more distinctive, perhaps "CodeMirror" by itself is fine (?)
    • CodeMirror does a lot more than just syntax highlighting, after all
    • There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. – Phil Karlton / Leon Bambrick
  • Add a CodeMirror toolbar (T95148)
    • This is what can be shown in the 2003 editor when CodeMirror is enabled, as well as other contexts where we don't use WikiEditor such as Special pages (i.e. T418811, T384148)
    • Ultimately, perhaps the 2003 editor (which is just a plain textarea), combined with CodeMirror, is what the "new" CodeMirror editor will be
    • We should try to maintain backwards compatibility with WikiEditor integrations for the mediawiki mode (T436607#12278442).
  • Change the dual checkbox preferences for the wikitext editor to a dropdown, something like:
    • Wikitext editor:
      • Plain textarea (This is sometimes called the '2003 wikitext editor')
      • WikiEditor (This is sometimes called the '2010 wikitext editor')
      • VisualEditor toolbar (This is sometimes called the '2017 wikitext editor'.)
      • CodeMirror (This is sometimes called the '2026 wikitext editor'.)
  • …

Event Timeline

MusikAnimal added a subscriber: DLynch.
MusikAnimal updated the task description. (Show Details)
MusikAnimal updated the task description. (Show Details)

Secondly, the two preferences are mutually exclusive, yet presented as checkboxes as if both can be true.

They are not exactly exclusive. If both are ticked, you see the 2017 editor with action=edit and the 2010 editor with action=submit. I personally have both checked and use the 2017 by default and manually add action=submit to the url when I want to perform linting.

Some users use gadget-made editors and a "no editor" option may be needed if the preferences change to a dropdown. On frwiki, I know that some users use https://fr.wikipedia.org/wiki/MediaWiki:Gadget-MonobookToolbar.js to define their own buttons in their common.js and have no editor activated.

MusikAnimal renamed this task from Consider offering CodeMirror as a distinct alternative to other wikitext editors (2026 editor) to Consider offering CodeMirror as a distinct alternative to other wikitext editors.Sep 1 2026, 5:28 PM
MusikAnimal triaged this task as Low priority.

"Bad idea" is a perfectly good response to this task. It's nothing pressing anyway, just meant to be food for thought. CodeMirror does a lot more than "syntax highlighting", with more features on the way, so it's mainly the nomenclature that I guess I am trying to change, and also put into question: What defines an editor? The answer seems to be a toolbar.

Building a new toolbar for CodeMirror would be a lot of work, but would give opportunity for a modern UI refresh, Codex adoption (T209059), and in the case of non-wikitext we can do away with the hacks that currently exist (same issue with CodeEditor, T47850). The idea for a CM toolbar is not new, either (T95148).

"Bad idea" is a perfectly good response to this task. It's nothing pressing anyway, just meant to be food for thought. CodeMirror does a lot more than "syntax highlighting", with more features on the way, so it's mainly the nomenclature that I guess I am trying to change, and also put into question: What defines an editor? The answer seems to be a toolbar.

Building a new toolbar for CodeMirror would be a lot of work, but would give opportunity for a modern UI refresh, Codex adoption (T209059), and in the case of non-wikitext we can do away with the hacks that currently exist (same issue with CodeEditor, T47850). The idea for a CM toolbar is not new, either (T95148).

Currently we have too many modes of wikitext editors (2003, 2010, 2017) so adding another editor (2026 CodeMirror wikitext editor) definitely does not help. For me, perhaps the CodeMirror editor should absorb both plain text area editor (2003) and the traditional wikitext toolbar (2010 wikitext editor) with refreshed design (utilizing Wikimedia Codex design language), while maintaining all functionalities of pre-existing 2010 wikitext editor toolbar.

What I mean by "maintaining all functionalities" is: if possible, the user scripts/gadgets that utilized the tabs/space/editing areas in 2010 wikitext editor (like the ones I circled in the picture below) should be easily integrated into the CodeMirror-based editor (unlike the 2017 wikitext editor). So that the freedom to add any useful/customized gadgets or even syntax highlighter (if some users prefer their in-house syntax highlighter instead of CodeMirror) could continue to do so like how the 2010 wikitext editor works currently.

image.png (1,363×958 px, 291 KB)

Therefore it would be great if the current task leaning towards an epic with something like "Rewrite the WikiEditor toolbar into CodeMirror and modernize the toolbar using Wikimedia Codex design language". I feel like ultimately, presenting only two wikitext editor modes (traditional manual wikitext editor & VE-based wikitext editor) would be inclusive to all users.

Just my two cents of thought, feel free to disagree with my opinion.

+1 to @Hakimi97 with T436607#12278442! That's pretty much exactly what I am envisioning now. There is already a "standalone CodeMirror" (i.e. plaintext area, or "2003 editor"), and the complaint we see there is the lack of a toolbar. In addition, WikiEditor isn't well-equipped for read-only and non-wikitext contexts. Hence I have revived T95148: Add toolbar to CodeMirror which I think is worthwhile regardless of everything mentioned in this task.

Attaching years to editors is also bad as it implies one might be superior to another. It's fine as an internal name, but not user-facing.

I'm going to take a stab at revising this task to be more open-ended and problem-oriented, and I'll relevant subtasks.

MusikAnimal renamed this task from Consider offering CodeMirror as a distinct alternative to other wikitext editors to Explore ways to offer CodeMirror as a distinct alternative to other wikitext editors (tracking).Sep 4 2026, 7:16 PM
MusikAnimal edited projects, added: Epic; removed: Proposal.
MusikAnimal updated the task description. (Show Details)

I like the brainstorming going on here!

There's a lot that's complicated about this, and I'm not going to comment on most of it at the moment, but here are some of my thoughts:

  • IMO a hypothetical 3rd-party MediaWiki install should be able to install CodeMirror and immediately get toolbars everywhere that syntax highlighting is available without having to add WikiEditor.
  • In that scenario, users should be able to toggle the toolbar and syntax highlighting independently of each other so you could easily have neither, just the toolbar, just syntax highlighting, or both, but all provided by a single extension.
  • To achieve that, syntax highlighting and the toolbar would be controlled by two separate preferences (technically three preferences, since highlighting is handled separately in wikitext vs. non-wikitext).

These ideas have probably been said already, but I wanted to lay them out here just to cover my bases! I'm not sure how these would interact with WikiEditor when they're both installed (like on WMF projects), but I imagine a drop-down approach as suggested in the task description would likely come into play. Or, if feature parity was eventually reached, we could even discuss phasing out WikiEditor entirely (of course that doesn't need to be a goal, though).

UPDATE: September 6th 2026

The current situation related to the Wikimedia code editors is like this:

For wikitext code editing:

  1. 2017 VisualEditor-based wikitext editor: using VE-based document-model editing surface + VE toolbar
  2. Plain textarea-based wikitext editor
    • Toolbar: (1) If no > 2003 wikitext editor (some users would prefer this mode for their userscript/gadget-based customized toolbar); (2) If yes > 2010 wikitext editor (using WikiEditor extension).
    • Edit mode syntax highlighting (not to be confused with read view syntax highlighting powered by Extension:SyntaxHighlight): (1) Disabling "Syntax" button in wikitext toolbar > No syntax highlighting (some users would prefer this mode for their userscript/gadget-based customized syntax highlighting); (2) Enabling "Syntax" button in wikitext toolbar > CodeMirror syntax highlighting, with 3 editor themes (containing default, color-blind friendly, and "no highlighting" which seems to overlap with the mentioned "disabling syntax button").

For non-wikitext code editing:

  1. Use plain textarea for editing area (unlike 2017NWE).
  2. Toolbar: Modified WikiEditor toolbar for the usage of non-wikitext code (it is believed that the toolbar is currently from CodeMirror extension, perhaps can deprecate CodeEditor extension?)
  3. Edit mode syntax highlighting: Can be enabled/disabled by clicking the "Syntax" button. CodeMirror offers much more editor themes (up to 9 themes) when enabled ("no highlighting" was not offered among the themes unlike wikitext's one)

Another thing that should be taken note is that on Special:Preferences#mw-prefsection-editing there are separate checkboxes of "Enable syntax highlighting for wikitext/code", which act the same as clicking the "Syntax" button.

If there is a standalone CodeMirror toolbar, at the same time WikiEditor and CodeEditor extensions successfully integrated into CodeMirror extension, perhaps the things that I listed could be organized better into something like:

Wikitext editing surface:

  1. VE-based wikitext editing surface (presumably the editing surface bundled with toolbar for now)
  2. Plain textarea-based wikitext editing surface

Editor toolbar:

  1. Enable/disable wikitext toolbar
  2. Enable/disable non-wikitext toolbar (is there any demand? if no, the non-wikitext toolbar should be enable it by default, and no option for this one should be displayed)

CodeMirror editor highlighting:

  1. Enable/disable wikitext editor highlighting
  2. Enable/disable non-wikitext editor highlighting

For non-wikitext code editing:

  1. [...]
  2. Toolbar: Modified WikiEditor toolbar for the usage of non-wikitext code (currently displayed through CodeEditor extension?)
  3. [...]

Actually I believe CodeMirror is now responsible for extending WikiEditor's toolbar here, at least on WMF projects.

If there is a standalone CodeMirror toolbar, at the same time WikiEditor and CodeEditor extensions successfully integrated into CodeMirror extension, perhaps the things that I listed could be organized better into something like:

[...]

Editor toolbar:

  1. Enable/disable wikitext toolbar
  2. Enable/disable non-wikitext toolbar

Unlike for syntax highlighting, I don't think there's a valid use case for having the toolbar preference differ by wikitext/non-wikitext (not that I'd oppose it, but it seems like overkill). There are people who want syntax highlighting just for non-wikitext, but does anyone want a *toolbar* just for non-wikitext? Of course if there are such people, I stand corrected, but it seems unlikely to me.

Unlike for syntax highlighting, I don't think there's a valid use case for having the toolbar preference differ by wikitext/non-wikitext (not that I'd oppose it, but it seems like overkill). There are people who want syntax highlighting just for non-wikitext, but does anyone want a *toolbar* just for non-wikitext? Of course if there are such people, I stand corrected, but it seems unlikely to me.

I do not remember if there was anyone would like to disable the toolbar for non-wikitext (as far as I remember more people would like to have a toolbar by default for modules, JS, CSS etc). I could remember clearly that there is a demand for enabling/disabling wikitext toolbar.