The "page type" mechanism is intended to provide a compact way for extensions to control the behavior (display, editing, move, delete, etc) of certain wiki pages. The concept of page types is already present in MediaWiki, but not explicitly modeled or specified. Rather, the behavior is hard coded into special cases.
Examples of existing "page types" in MediaWiki core:
- article (the default)
- talk page (talk namespaces)
- category page (the Category namespace)
- file description page (the File namespace)
- script page (Js or CSS, user or global, active content to be interpreted by the browser) (.js and .css suffix in the MediaWiki and the User namespace)
- system message (MediaWiki namespace)
- conversion table (MediaWiki namespace with Conversiontable/ prefix)
All of these trigger special behavior during display, editing, purging, moving, etc.
PageTypeHandler would model this concept, allowing extensions to easily define their own page types. It should control at least:
- layout for the view action. The PageTypeHandler may be aware of certain content slots, and may show their content as appropriate. It may or may not show additional slots using a generic layout mechanism.
- editing mechanism. The PageTypeHandler may be aware of certain slots, and may provide an integrated editing experience for their content. It should provide a some way to access editing interfaces for any additional slots.
- which slots are allowed, required, and desired on pages of this type.
- Generic action overrides (to replace ContentHandler::getActionOverrides)
- behavior to be triggered upon creation, modification, and deletion, as currently encoded in WikiPage::doEditUpdates and WikiPage::doDeletionUpdates
- Constraints on page moves. Since page moves change the title, the may change the page type. In such a case, the old and the new page type handler have to both agree that the move is possible. This replaces ContentHandler::canBeUsedOn.
Ideally, a page's "type" is determined solely by it's title, regardless of database state. It would typically be based by the namespace, but in some cases, a title suffix or prefix may also trigger a certain page type.
However, several extensions exist that cause special behavior to be triggered based on the content model (of the main slot). it may be necessary to retain this behavior, at least for a transition period. Whether it may be unavoidable in principle or even desirable remains under discussion as of this writing.