Change Details

Semantically, a page no longer has a content model with MCR -- each stream has one. We could keep this field around and use it as the default for the main slot, but the exact semantics of the interaction between page_content_model and rev_content_model have been causing confusion before. Also, this usually NULL. So, when converting to the MCR-only schema, we should also stop reading and writing the page_content_model field. Current use cases can be covered as follows: * the content model of the main slot of the current revision, `$page->getRevisionRecord()->getSlot(SlotRecord::MAIN)->getModel()` * the page's default content model, `$slotRoleRegistry->getRoleHandler(SlotRecord::MAIN)->getDefaultModel($title)` * the "kind" of page, depending on the namespace (mostly): introduce the concept of a "page type". For now, this could just be something like `PageTypeInfo::getPageType(LinkTarget): string`, with no special logic intrinsically attached. Page types would initially be configured per namespace, plus regular expressions for titles, so we can cover stuff like file page, category page, user script page, site css page, translation table, Lua module, system message, etc - anything that needs special behavior should have a different type. And the type determines the default model of the main slot, not the other way around.

Semantically, a page no longer has a content model with MCR -- each stream has one. We could keep this field around and use it as the default for the main slot, but the exact semantics of the interaction between page_content_model and rev_content_model have been causing confusion before. Also, this usually NULL. So, when converting to the MCR-only schema, we should also stop reading and writing the page_content_model field. Current use cases can be covered as follows: * the content model of the main slot of the current revision, `$page->getRevisionRecord()->getSlot(SlotRecord::MAIN)->getModel()` * the page's default content model, `$slotRoleRegistry->getRoleHandler(SlotRecord::MAIN)->getDefaultModel($title)` This should cover all existing use cases. As a note for later, we may want to stop using the page's content model to determine what "kind" of page a given page is. Instead, we should introduce the concept of a "page type". For now, this could just be something like `PageTypeInfo::getPageType(LinkTarget): string`, with no special logic intrinsically attached. Page types would initially be configured per namespace, plus regular expressions for titles, so we can cover stuff like file page, category page, user script page, site css page, translation table, Lua module, system message, etc - anything that needs special behavior should have a different type. This is similar to how the default content model of the main slot is currently determiend. The page type would add a level of indirection - the type determines the default model of the main slot (not the other way around).

Semantically, a page no longer has a content model with MCR -- each stream has one. We could keep this field around and use it as the default for the main slot, but the exact semantics of the interaction between page_content_model and rev_content_model have been causing confusion before. Also, this usually NULL. So, when converting to the MCR-only schema, we should also stop reading and writing the page_content_model field. Current use cases can be covered as follows: * the content model of the main slot of the current revision, `$page->getRevisionRecord()->getSlot(SlotRecord::MAIN)->getModel()` * the page's default content model, `$slotRoleRegistry->getRoleHandler(SlotRecord::MAIN)->getDefaultModel($title)` * the "kind" of page This should cover all existing use cases. As a note for later, we may want to stop using the page's content model to determine what "kind" of page a given page is. Instead, depending on the namespace (mostly):we should introduce the concept of a "page type". For now, this could just be something like `PageTypeInfo::getPageType(LinkTarget): string`, with no special logic intrinsically attached. Page types would initially be configured per namespace, plus regular expressions for titles, so we can cover stuff like file page, category page, user script page, site css page, translation table, Lua module, system message, etc - anything that needs special behavior should have a different type. And the type determinesThis is similar to how the defaultt content model of the main slot, is currently determiend. not the other way aroundThe page type would add a level of indirection - the type determines the default model of the main slot (not the other way around).