Page MenuHomePhabricator

Provide clean interface to register content editing interfaces
Open, MediumPublic40 Estimated Story Points

Description

NOTE: This ticket used to be an RFC, but turned out to be too vague to be useful in that role. It continues to serve as a tracking ticket for now.

Problem

Current core has a basic textarea as its default editing interface. (With a classic toolbar, but being removed from core per T30856).

Extensions currently "add" editors to MediaWiki by using hooks based on adding arbitrary HTML and JS modules to a page. This does not scale and creates various usability problems that block feature development, which stems from the basic premise that MediaWiki doesn't recognise the concept of an editor. It's just arbitrary HTML that happens to be on the edit page between "page notices" and the textarea.

Technical requirements

  • Core must have a registry of content editing interfaces.
  • Extensions must be able to add their interface to this registry.
  • Core must allow registered interfaces to restrict themselves to certain content models.
  • The registry must have a way to decide what the default will be.
  • There must be a way to set the default via a site configuration variable.
Undecided

These are not yet requirements. They could be considered as "todo later" (not in the first version), or may be considered "not needed" (easy to do in extensions without core support), or may become requirements later based on feedback.

  • Automatically create preferences for deciding which editor should be the default for a given content-model (e.g. dropdown of registered editors).
  • Allow setting editor ID by URL (e.g. title=..&action=edit&editor=..). This would error if the editor is unknown or not valid for the page's content model. We may end up using query parameters internally as a way to switch between editors (although it could be done invisibly via POST.). But this bullet point is whether we need sharable permalinks to specific interfaces (and if so, why).

Outcome

One can install a wiki, add zero or more extensions to it (e.g. WikiEditor, VisualEditor, CodeEditor), and without doing anything else:

  • On the edit page (plain action=edit) an appropiate editor is displayed by default for the page's content model.
  • The edit page must have a way to switch between editing interfaces (if there is more than 1).

Current issues to address:

  • No competing editors should get loaded, overwritten or replaced at run-time.
  • No editors should load via urls other than an (extended form of) action=edit.

Proposal 0: Miscellaneous

There is not yet a single unified proposals, but here are some ideas to consider:

Method of registering
  • Configuration variable: wg available editors = array()
  • Extension attribute
  • Hook

Preferably only one method of registering, and I'd prefer not via hooks (for performance), unless we specifically want to encourage complex or conditional registration, which, if we have use cases for it, may lead to improving the registry instead.

Entity being registered

It seems conventional to register things in MediaWiki by a class or object that implements an abstract interface (with the option to provide a class name, or callback that returns an instance). Do we want that here? If not, why not?

Content model

Should we make content model a primitive by which the registry is fragmented? Or should instead the registered entity have a way to decide whether it is compatible? E.g. AvailableEditors[:contentModel][:editor] vs AvailableEditors[:editor] with IEditor::supports(ContentModel, TitleValue) or some such.

Setting the default
  • wg default editor?

Related:

Details

Reference
bz26918

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:22 PM
bzimport set Reference to bz26918.
bzimport added a subscriber: Unknown Object (MLST).

This now requires some additional consideration, in that content models and specialized editors for specific content exist.

He7d3r added a project: JavaScript.
He7d3r set Security to None.
He7d3r added a subscriber: brooke.
Krinkle renamed this task from Create a clean interface to plug in (other/any) editor frontends to RFC: Provide clean interface to register content editing interfaces.Apr 25 2018, 10:37 PM
Krinkle updated the task description. (Show Details)
Krinkle added a project: VisualEditor.
Krinkle set the point value for this task to 40.
Krinkle moved this task from Unsorted to Working on on the Contributors-Team board.
Krinkle moved this task from P1: Define to Under discussion on the TechCom-RFC board.
Krinkle edited subscribers, added: Krinkle; removed: wikibugs-l-list.
Krinkle removed a project: JavaScript.
Krinkle added a project: User-Daniel.
kchapman subscribed.

Closing as needs to be rethought with MCR and multiple content types.

Closing as needs to be rethought with MCR and multiple content types.

This is a crucial "future of MediaWiki" RfC. The fact that it needs re-working (as part of the discussion) and isn't currently resourced (like almost all of our RfCs) very much doesn't mean that this should be Declined. At most, you could de-tag it until it's been re-written.

This is a crucial "future of MediaWiki" RfC. The fact that it needs re-working (as part of the discussion) and isn't currently resourced (like almost all of our RfCs) very much doesn't mean that this should be Declined. At most, you could de-tag it until it's been re-written.

The intent is certainly still valid, but the RFC as written is so stale by now that it's not useful any more. I expect a new RFC to result from concrete product needs for multi-slot editing. I'm personally thinking along the lines of T209924: Specify PageTypeHandler. We don't just need a way to edit different kinds of content, we need a way to edit different combinations of slots.

This is a crucial "future of MediaWiki" RfC. The fact that it needs re-working (as part of the discussion) and isn't currently resourced (like almost all of our RfCs) very much doesn't mean that this should be Declined. At most, you could de-tag it until it's been re-written.

The intent is certainly still valid, but the RFC as written is so stale by now that it's not useful any more. I expect a new RFC to result from concrete product needs for multi-slot editing. I'm personally thinking along the lines of T209924: Specify PageTypeHandler. We don't just need a way to edit different kinds of content, we need a way to edit different combinations of slots.

Sure, but "I have a pet unfunded alternative RfC" isn't a great reason to Decline.

Sure, but "I have a pet unfunded alternative RfC" isn't a great reason to Decline.

That's true. But a stale and also unfunded RFC isn't much use either.

To me, it seems clear that we need "something like this", but the concrete requirements are not known, so no technical solution can be proposed.

If you have a concrete proposal in mind and want to drive it, please re-open this, or create a new RFC.

daniel edited projects, added TechCom; removed TechCom-RFC.

Looking at the tickets that depend on this, perhaps it would make sense to keep this as a tracking task. That would make sense, I suppose. It just doesn't work as an RFC.

I'll re-open and re-purpose.

daniel renamed this task from RFC: Provide clean interface to register content editing interfaces to Provide clean interface to register content editing interfaces.Jul 22 2019, 8:24 PM
daniel updated the task description. (Show Details)

Looking at the tickets that depend on this, perhaps it would make sense to keep this as a tracking task. That would make sense, I suppose. It just doesn't work as an RFC.

I'll re-open and re-purpose.

Thank you! Note that tasks closed as officially Declined by TechCom are not the kind of task you can expect people to "please re-open". :-)

Thank you! Note that tasks closed as officially Declined by TechCom are not the kind of task you can expect people to "please re-open". :-)

I suppose you are pointing out a flaw in the process here. This task was the victim of a cleanup session. We are going through outdated and inactive RFCs, trying to close out what was no longer useful. The intent was not to reject the the idea. The alternative would have been to close it as "stalled" or "invalid"... None of the options seem to be a great fit for "the idea has merrit, but the solution needs to be re-thought, and nobody is working on it right now"...

The "backlog" column on the RFC boards is overflowing with good ideas in need of a little love and attention. Closing the ones that have grown old and tired seems better than just letting them sit. But I see that we need to be more careful about marking things as "declined".