Page MenuHomePhabricator

Implement a user interface to change a page's content model when $wgContentHandlerUseDB = true;
Closed, ResolvedPublic

Description

Currently the only way to change a page's content model is to use the API, which isn't really a good UX. We need some user interface (possibly a special page similar to Special:PageLanguage) that lets a user change the page's content model.

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:44 AM
bzimport set Reference to bz70592.
bzimport added a subscriber: Unknown Object (MLST).
RobLa-WMF renamed this task from Add a special page to change a page's content model when $wgContentHandlerUseDB = true; to Implement a user interface to change a page's content model when $wgContentHandlerUseDB = true;.Mar 16 2015, 4:10 AM
RobLa-WMF updated the task description. (Show Details)
RobLa-WMF set Security to None.

Part of me thinks of content model as just another page property (similar to default category sort key).

Another part of me thinks of content model as similar-ish to moving a page. Currently Special:MovePage modifies page_namespace and/or page_title and/or page_is_redirect. What we want here is to modify page_content_model, as I understand it. In that sense, Special:MovePage doesn't seem like the worst place in the world, aside from the somewhat awkward name.

I'm wondering whether we can build upon something pre-existing. A separate Special page feels potentially clunky and too narrow in scope.

Okay, so I think this task should be fairly easy to resolve once there's a clear plan. Here's where I am at the moment.

We should decide whether we want a new Special page or new action for this (e.g., Special:ChangePageContentModel or action=changepagecontentmodel).

(Alternately, we could do something more generic like Special:PageProperties, but meh.)

Then we should decide how this will be logged. Probably a single log_type and log_action (e.g., log_type = "contentmodel" and log_action = "change")?

Once this is decided, we already have all of the infrastructure in place to just do this in core.

Does this seem reasonable? Any thoughts?

Similar to page protection and page moves, we'll probably want an entry in the revision table as well, I guess? And recentchanges for patrolling and watchlists. Hmm.

Okay, so I think this task should be fairly easy to resolve once there's a clear plan. Here's where I am at the moment.

We should decide whether we want a new Special page or new action for this (e.g., Special:ChangePageContentModel or action=changepagecontentmodel).

I'd go with a special page.

Then we should decide how this will be logged. Probably a single log_type and log_action (e.g., log_type = "contentmodel" and log_action = "change")?

We'll already be adding an entry to the revision table, so do we need a separate log?

I don't think a general interface for freely changing the content model of a page is a good idea. It's like changing the type of an object in a program - that operation doesn't really make sense, and may break things if forced. For instance, some content models may make assumptions about the namespace they can be in, or similar.

Also, how content can sensibly be converted depends a lot on the context. So I would suggest to implement context specific conversion interfaces, e.g. convert wikitext to flow board.

An exception could be converting between text-based content models, e.g. wikitext to javascript, or plain text to css.

Side note: the content model for such pages only dictates rendering (syntax highlight, etc), not special powers. A JavaScript page in the talk namespace would not be executable, while a JavaScript page in the MediaWiki-namespace would be if it had a title ending in .js. Only then special permissions should be required.

Also, how content can sensibly be converted depends a lot on the context. So I would suggest to implement context specific conversion interfaces, e.g. convert wikitext to flow board.

So each extension (e.g., MassMessage or Flow) would do what? Establish a separate user right for one-time content model conversions? Would there be a consistent mechanism for logging this type of conversion?

An exception could be converting between text-based content models, e.g. wikitext to javascript, or plain text to css.

This seems to point to a more general interface.

Side note: the content model for such pages only dictates rendering (syntax highlight, etc), not special powers. A JavaScript page in the talk namespace would not be executable, while a JavaScript page in the MediaWiki-namespace would be if it had a title ending in .js. Only then special permissions should be required.

I'm not totally sure what you mean here regarding JavaScript execution. I think you can theoretically load/execute JavaScript from nearly any page? The auto-magic page protection from MediaWiki applies to editing pages ending in ".js" (and a separate layer of protection covers pages in the MediaWiki namespace), as I understand it, but you can do this...

$ curl -Is "https://en.wikipedia.org/w/index.php?title=Talk:Barack_Obama&ctype=text/javascript&action=raw" | grep Content-Type:
Content-Type: text/javascript; charset=UTF-8

After discussing this with @Legoktm and others, I'm supportive of the approach being taken in https://gerrit.wikimedia.org/r/207353. My view is that we should treat changing a page's content model similar to how we currently treat moving a page. This means having a dedicated Special page and separate user right. Just as moving a page can be disruptive (and there's no rollback for it), so can changing a page's content model. It's roughly a similar level of pain for gain, which I think makes a present-day, feasible solution acceptable.

Expanding on the implementation details here, content model changes will have their own log entries in the logging table (Special:Log/changecontentmodel or whatever). And similar to page protection and page moves, there will be an entry in the revision table as well. This entry will help ensure that the latest revision of the page matches the new page content model, as I understand it.

We'll also probably need some kind of configurable array of allowed content model transitions? It's unclear how much this will need to be restricted.

Protecting against content model changes will be tied to the edit permission, so no changes to the page protection form or infrastructure should be necessary. By default, I imagine we'll grant the editcontentmodel user right in the same way we currently grant the move user right in MediaWiki core.

Change 207353 had a related patch set uploaded (by Legoktm):
[WIP] Add Special:ChangeContentModel

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

Patch should now be feature complete and ready for review!

Change 221783 had a related patch set uploaded (by Reedy):
[WIP] Add a script to change the content model of a page

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

Change 207353 merged by jenkins-bot:
Add Special:ChangeContentModel

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

Change 221783 abandoned by Legoktm:
[WIP] Add a script to change the content model of a page

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