Page MenuHomePhabricator

Add support for a "Multi-Part" content model for use with MediaInfo / structured meta-data
Closed, InvalidPublic


The multipart content model should support a "main" part containing wikitext, and several "attachments". The different parts would be bundled together in some kind of envelope structure, using something like JSON, XML, or mime/multipart.

Only the main/text part of the content should be exposed via EditPage and action=edit. Some other parts can be accessed/edited via EditPage and action=edit by requesting them specifically. Some parts, depending on their content model, may not be editable via the text based interfaces.

Note that exposing only the textual "main" part via action=edit breaks the assumption that it is possible to grab a revision's content, modify it, and save it. The revision's content would be the full blob containing all parts (unless requested otherwise).

Version: unspecified
Severity: enhancement
See Also:



Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:53 AM
bzimport set Reference to bz71781.
bzimport added a subscriber: Unknown Object (MLST).

I think we have something similar to this in MassMessage: a JSON content model that contains and displays displays wikitext, and a structured spamlist. (example:!).

It seems that we want a "multi-part" content model should be either completely visible & explicit, which would mean it can't be edited directly using the "normal" EditPage, and reading and editing via the API would require the client to understand and process the multi-part wrapper data structure.

Or it should be completely transparent, exposing only the "main" (typically wikitext) content even when editing using EditPage, or even when asked for revision content via the API. Any "extra" parts would need to be requested explicitly. This means core could has to know about this special kind of content model, and implement special handling for it in several places.

I think it would be good to have both: a basic multi-part model, as well as a "transparent" multi-part model, built on top of the "normal" one.

Superseded by MCR.