Page MenuHomePhabricator

Introduce UnknownContentHandler and UnknownContent
Closed, ResolvedPublic

Description

The purpose of UnknownContentHandler and UnknownContent is to allow content handlers to be undeployed from a wiki that still has content in the database that is declared to use the respective model. With the new MCR enabled storage layer, old "model oblivious" access methods no longer work.

In such a case, UnknownContentHandler could be register as the handler for the now unknown content model, to avoid hard failure modes while generating dumps and diffs.

UnknownContent would wrap the serialized blob, and return it unchanged for serialization. Rendering would produce empty output or output containing an error message. Diffing would similarly only produce a message.

UnknownContent would not allow direct editing. Pages containing UnknownContent in the latest revision would become immutable.

Event Timeline

If this gets done, stub dumps will go back to working for urwikibooks and dewikiversity. The other option at the moment is to do run the jobs manually with a hacked copy of XmlDumpWriter, which is not ideal. I'd like to not be doing that for more than a few more runs (say, a month).

Putting this into the cpt inbox for triage.

We should probably have rules for MediaWiki-ContentHandler to automatically put things into the CPT inbox. Same for MediaWiki-libs-Services.

If this gets done, stub dumps will go back to working for urwikibooks and dewikiversity.

See T207626: Disable unused Flow extension on de.wikiversity for reference.

Change 531688 had a related patch set uploaded (by Daniel Kinzler; owner: Daniel Kinzler):
[mediawiki/core@master] Add UnknownContentHandler.

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

Change 531688 merged by jenkins-bot:
[mediawiki/core@master] Add UnknownContentHandler.

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

@daniel can this be closed as resolved, or is there something left to do?