Page MenuHomePhabricator

stop using page_content_model
Open, LowPublic5 Estimated Story Points

Description

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 (if the page does not yet exist), $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).

Event Timeline

WDoranWMF lowered the priority of this task from Medium to Low.Sep 17 2019, 4:45 PM
WDoranWMF set the point value for this task to 5.
daniel updated the task description. (Show Details)

Removing from sprint board. This isn't ready. Needs breaking up. Also, this doesn't block the schema migration for the revision table. It affects the page table instead.

CCicalese_WMF added a subscriber: CCicalese_WMF.

Removing from sprint board. This isn't ready. Needs breaking up. Also, this doesn't block the schema migration for the revision table.

Since this is not ready and it does not block the current MCR schema migration initiative, I'm moving it from Platform Team Initiatives (MCR Schema Migration) to Platform Team Initiatives (MCR) and removing T174045 and T231693 as parent tasks.

It affects the page table instead.

Does this imply that the current MCR schema migration initiative is focused only on the revision table and that there will need to be a separate page table schema migration activity later?

Does this imply that the current MCR schema migration initiative is focused only on the revision table and that there will need to be a separate page table schema migration activity later?

Essentially, yes. Though that should be *much* simpler. I was hoping to fold that in, but don't want to block on it now.