RFC: MediaWiki should provide a pluggable registry for editor interfaces
Open, Stalled, NormalPublic40 Story Points

Description

What

  • MediaWiki will provide a registry, PlugableEditor, for software to 'offer' to be "the editor" based on content type and other concerns.
  • The core editing interface ('Bob') will be separated from EditPage.php into a default-bundled extension.
  • Editor extensions will be able to register themselves as providing additional "editor" interfaces.
  • EditPage.php will become solely a code interface for editing.
  • Wiki sysadmins will be able to (?? how) configure additionally the availability of installed editors.

Why

Right now EditPage.php provides an editor, and then extensions either replace it (e.g. VisualEditor) or augment it (e.g. WikiEditor) and reach into it to disable other aspects. Some extensions extend other extensions (e.g. CodeEditor and Drafts over-ride WikiEditor). This is inefficient for the system, complex for developers, and results in poor user outcomes. For example, if you don't like WikiEditor's toolbar as 'noise' because you already know wikitext, you can't use CodeEditor when editing JS and so on (which you might want).

Registry options

  • What content type(s) does the editor support? (e.g. 'Bob' supports all textual content types; 'CodeEditor' supports CONTENT_MODEL_JAVASCRIPT, CONTENT_MODEL_JSON, CONTENT_MODEL_CSS; 'ScriptEditor' supports CONTENT_MODEL_LUA; 'ImageEditor' supports CONTENT_MODEL_IMAGEBINAR; …)
  • What user right(s) does the editor require? (e.g. 'UploadWizard' requires 'upload' right as well as 'create' and 'edit'; 'Flow' requires 'flow-board-create' for some operations; …)

Related Objects

Jdforrester-WMF updated the task description. (Show Details)
Jdforrester-WMF raised the priority of this task from to Normal.
Jdforrester-WMF added a subscriber: Jdforrester-WMF.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 4 2015, 8:42 PM

Another thing we might want to consider is making it easier to embed into non-page editing contexts. For example, the textarea on Special:MassMessage is a wikitext input, it would be nice if WikiEditor, VE, or a toolbar was available. Flow has specialized code to embed VE, and LQT has special code for WikiEditor.

I'd also like to see how spam filitering extensions integrate improved (this is a giant part of EditPage.php right now). The arbitrary hook and somehow output an error message (that the API may or may not get) is pretty terrible. Flow has a very primitive SpamFilter interface, which I think is a good direction to go in. This could be something that is potentially tackled beforehand, but I think will be necessary before we can have pluggable editors.

He7d3r rescinded a token.
He7d3r awarded a token.
Jdforrester-WMF edited a custom field.
Paladox added a subscriber: Paladox.Dec 9 2015, 6:30 PM
brion added a subscriber: brion.Dec 9 2015, 9:14 PM

Another thing we might want to consider is making it easier to embed into non-page editing contexts. For example, the textarea on Special:MassMessage is a wikitext input, it would be nice if WikiEditor, VE, or a toolbar was available. Flow has specialized code to embed VE, and LQT has special code for WikiEditor.

I think that would be a basic requirement. Every pluaggable editor (just in my thoughts) should allow (or at least mention if it could or could not) to get basic elements, such as the content input (which, in fact, maybe isn't an input field, but a content-editable) or the summary input.

I'd also like to see how spam filitering extensions integrate improved (this is a giant part of EditPage.php right now). The arbitrary hook and somehow output an error message (that the API may or may not get) is pretty terrible. Flow has a very primitive SpamFilter interface, which I think is a good direction to go in. This could be something that is potentially tackled beforehand, but I think will be necessary before we can have pluggable editors.

I'm not sure, if this is really a blocker for a pluggable editor. Shouldn't the editor be a simple frontend, data gather and provider? I think about something like a method to get input fields for a form and a method to get pre-processed data (e.g. to merge, add or remove submitted data of the request), or maybe "only" a definition of submitted data that belongs to the submitted data. The processing should be handled in EditPage (maybe a bad name for that) which gets this field definition, checks all inputs (maybe tgese, which has a "shouldSpamCheck" property set) against spam through a set of provided spam filters (e.g. through a SpamFilter interface) and passes tge data to a processor, which handles the save of the edit (maybe a pluggable processor, too).

For that, it wouldn't be a requirement to have something like a SpamFilter interface, even if it would make sense :)

I hope I explained, what I think, clear and understandable :]

I'd also like to see how spam filitering extensions integrate improved (this is a giant part of EditPage.php right now). The arbitrary hook and somehow output an error message (that the API may or may not get) is pretty terrible. Flow has a very primitive SpamFilter interface, which I think is a good direction to go in. This could be something that is potentially tackled beforehand, but I think will be necessary before we can have pluggable editors.

I'm not sure, if this is really a blocker for a pluggable editor. Shouldn't the editor be a simple frontend, data gather and provider?

It shouldn't be part of the pluggable editor, but I think the implementation of the pluggable editor is going to be very difficult if the two are not untangled first, as the current code is pretty conjoined. Also, it is the responsibility of the editor to display any warnings or errors to the user prior to or during the save process (edit notices, protection warnings, abusefilter/spamblacklist, etc.). But we should make sure the backend doesn't hand the editor a blob of HTML - it should be structured info.

cscott added a subscriber: cscott.EditedDec 31 2015, 8:39 PM

We'd like to eventually allow extension authors to distribute PHP, Parsoid, and VisualEditor code in a single bundle (somehow) to allow authoring and editing new tag extensions. Ie, https://www.mediawiki.org/wiki/Extension:WikiHiero could include the code to register and render <hiero> in PHP, Parsoid hooks to parse <hiero> in wikitext (say) and client-side JavaScript to render and edit <hiero> in VisualEditor. (T133320)

This sounds similar to the "embeddable editor" discussed above; the idea that VE might simply embed a separate editor widget wherever <hiero> appears. But it would be even nicer to be able to hook VE (as well/instead of completely replacing it).

Krinkle renamed this task from MediaWiki should provide a pluggable registry for editor interfaces to RFC: MediaWiki should provide a pluggable registry for editor interfaces.Feb 3 2016, 9:28 PM
RobLa-WMF changed the task status from Open to Stalled.Mar 2 2016, 10:40 PM
RobLa-WMF assigned this task to daniel.
RobLa-WMF added a subscriber: RobLa-WMF.

Per E146. @daniel may be willing to take this on

daniel added a subscriber: Harej.Apr 1 2016, 12:16 PM
Zppix moved this task from Unsorted to Working on on the Contributors-Team board.Apr 26 2016, 2:30 PM
RobLa-WMF mentioned this in Unknown Object (Event).May 4 2016, 7:33 PM

Some quick thoughts:

The content handler should be responsible for defining (like in the format of an HTMLFormField array definition) what they need the edit interface to be:

  • wikitext: one textbox of content format text/x-wiki
  • MassMessage: one text/x-wiki textbox, and one text/plain textbox

MediaWiki maintains a registry of editors and content formats they can support. It will pick an editor based on the ones that are available for that format, and then a user preference option, and then the site default. We'd still let people override the editor for that request with a URL parameter or something.

Some quick thoughts:

The content handler should be responsible for defining (like in the format of an HTMLFormField array definition) what they need the edit interface to be:

  • wikitext: one textbox of content format text/x-wiki
  • MassMessage: one text/x-wiki textbox, and one text/plain textbox

    MediaWiki maintains a registry of editors and content formats they can support. It will pick an editor based on the ones that are available for that format, and then a user preference option, and then the site default. We'd still let people override the editor for that request with a URL parameter or something.

In a post-MCR world, would the control be on the page or the slot level? If a page is just a single text/x-wiki blob (like now), I guess a dumb/pre-MCR wikitext editor could edit it, but if it was a combined primary text/x-wiki and primary text/json or whatever I guess that would likely break things, so the control is at the page level?

In a post-MCR world, would the control be on the page or the slot level? If a page is just a single text/x-wiki blob (like now), I guess a dumb/pre-MCR wikitext editor could edit it, but if it was a combined primary text/x-wiki and primary text/json or whatever I guess that would likely break things, so the control is at the page level?

In my examples, I think textbox == slot basically. Which "control" are you referring to?

Basically, I slot, one editor (which is a text box for textual content). The slot name will have to be associated with the field names somehow, e.g. as a prefix.

On the page level, you would have controls for the edit summary, watching, minor edits, and hidden fields for the base revision, edit token, etc.

This requires the current EditPage code to be completely refactored, to allow a separation of actual editing from form handling logic.

Note that this will also have to work with the conflict resolution diff view. That's going to be fun to design :)

Another thought:

In some cases, we want integrated editing of multiple slots. I'm not yet sure how that would be controlled. Perhaps like this: all editors have access to all slots, and can "consume" slots they cover, so the standard editor for that slot would not be shown. This however depends on some kind of order in which the slots of processed, which is currently undefined.

Maybe only the editor of the main slot should have the ability to "consume" editors for other slots. Or this could be controlled via hooks, per namespace, whatever...

Theoretical example:

On a post-MCR wiki, you click edit on a File page.

The slots are four-fold: the binary file blob (in reality, a pointer to one), the description (wikitext), the page metadata (metadata, a validated JSON blob), and the structured media info data (mediainfo, a validated JSON blob).

The system has the following editors installed:

  1. MediaWiki's core (non-JS) text editor, which supports wikitext slots and frankly anything text-based, which gives a different edit box (?) for each primary text slot.
  2. The upload tool, which supports all four slots but only for creation.
  3. The image editing tool, which supports all four slots, but let's say only lets you edit the wikitext slot as wikitext, not visually.
  4. The 2010 wikitext editor (WikiEditor), which supports wikitext slots.
  5. The extension to the 2010 wikitext editor to edit non-wikitext 'code'-like things (CodeEditor), which supports json slots (amongst others).
  6. The integrated visual / 2017 wikitext editor, which supports wikitext slots and a structured editor for metadata slots.

When you click edit, we give you… option 3, because it's the one that lets you change all the slots? Option 5 because you like it more? Help.

Above, I specifically said "content format" instead of "content model".

So if we only had a plain text editor available, we would serialize the metadata/mediainfo into a plain text representation, and then server-side validate and re-serialize it into the canonical format for saving to the database. MassMessage kind of uses this currently for a batch edit interface (think raw Watchlist editor). I know CollaborationKit uses it as well.

With that in mind, let's revisit your scenario:

Theoretical example:

On a post-MCR wiki, you click edit on a File page.

The slots are four-fold: the binary file blob (in reality, a pointer to one), the description (wikitext), the page metadata (metadata, a validated JSON blob), and the structured media info data (mediainfo, a validated JSON blob).

The system has the following editors installed:

  1. MediaWiki's core (non-JS) text editor, which supports wikitext slots and frankly anything text-based, which gives a different edit box (?) for each primary text slot.
  2. The upload tool, which supports all four slots but only for creation.

I would keep editing separate because the upload process is still separate from editing.

  1. The image editing tool, which supports all four slots, but let's say only lets you edit the wikitext slot as wikitext, not visually.
  2. The 2010 wikitext editor (WikiEditor), which supports wikitext slots.
  3. The extension to the 2010 wikitext editor to edit non-wikitext 'code'-like things (CodeEditor), which supports json slots (amongst others).
  4. The integrated visual / 2017 wikitext editor, which supports wikitext slots and a structured editor for metadata slots.

Also, MediaWiki core will ship with at least a text/plain editor aka <textarea>.

When you click edit, we give you… option 3, because it's the one that lets you change all the slots? Option 5 because you like it more? Help.

Yes, probably #3 will be the default for the file namespace. We could probably have that be a registry setting. If your preferences are set to prefer CodeEditor for metadata/mediainfo, then you'd get it for those fields, and whatever your wikitext preference is.

Ah, sorry, I missed the format bit.

Some non-text content can be edited as text via sieralization, some (like wikibase entities) can't. This is controlled by ContentHandler::supportsDirectEditing(). I believe EditPage does the Right Thing for this.

But I guess all that is off-topic to the discussion at hand.

@Jdforrester-WMF If you have a mediainfo slot, you also have wikibase installed, and you would use the api based editing widgets for editing that bit. The eidgets for editing mediainfo would be available in the normal view - integrating them with the edit page would be nice, but tricky. Extracted metadata would be a derived slot (support for which is undecided and pushed back for now), and not editable at all. The slot containing the reference to the blob would also not be editable. That could actually share a slot with the extracted meta-data. Storing a pointer to the image blob in a slot is also not decided on. I like the idea, but it has it's own challenges.

So, clicking edit on an image page would give you a wikitext editor, like you would get for any wikitext page (plain, wikieditor, or VE, whatever is enabled). At least in VE mode, you would also want to see the mediainfo stuff with the wikibase edit widgets... but that would be a bit odd: editing mediainfo via a gadget on the edit page would immediately save an edit, even if you never hit "save" for the edit page.

daniel removed daniel as the assignee of this task.Sep 28 2016, 8:38 PM

Unassigning myself, since we now have the TechCom-Has-shepherd board now for tracking shepherds.

I certainly think it would be good to have this. Is anyone interested in actually working on it?

I certainly think it would be good to have this. Is anyone interested in actually working on it?

Interested, yes! Willing to lead it, nope. I'm not sure we're ready for that yet - I think we still need more planning and specific steps broken down first. I suggested above a good place to start would be ripping out the spam filtering stuff from EditPage.


Also, https://gerrit.wikimedia.org/r/#/c/314070 reminded me that editors somehow also need to add custom URL parameters and get their values.

daniel moved this task from Inbox to Project on the User-Daniel board.Jan 5 2017, 7:02 PM

I'd also like to see how spam filitering extensions integrate improved (this is a giant part of EditPage.php right now). The arbitrary hook and somehow output an error message (that the API may or may not get) is pretty terrible. Flow has a very primitive SpamFilter interface, which I think is a good direction to go in. This could be something that is potentially tackled beforehand, but I think will be necessary before we can have pluggable editors.

I filed this as T170184: Refactor anti-spam/vandalism checks out of EditPage.php and plan on working on it.

Anomie added a subscriber: Anomie.Jul 16 2017, 3:50 AM

The core editing interface ('Bob') will be separated from EditPage.php into a default-bundled extension.

I really don't like using extensions for basic functionality. If someone doesn't have this extension (or one that completely replaces it), suddenly no one can edit pages at all? That's bad. Just include the "extension" in core instead of trying to require installation of an extension.

From the discussion it seems like we're looking at tying the editor to the ContentHandler content models somehow or other, which is probably a good idea. MediaWiki core should include editors that can handle the concrete content models provided by core. It can probably get away with having just one editor for editing the serialized representation of a TextContent as a plain <textarea> without much if any fancy JS, and a simple file-upload 'editor' if/when we get to the point of making File-page files into an MCR slot. Extensions like WikiEditor and CodeEditor and VE could, of course, provide nicer editors for existing content models.