Until $wgContentHandlerUseDB is set to true, page_content_model will be NULL. This prevents changing the default content model with $wgNamespaceContentModels because NULL will be interpreted with the new default instead of whatever the page actually is.
page_content_model, rev_content_model (I think just the last revision should be sufficient), ar_content_model all need to be populated.
Change 221755 had a related patch set uploaded (by Legoktm):
[WIP] script to populate page,revision,archive.*_content_* fields
Hmm, so I just filed T104275: Write maintenance script to change page's content model not knowing that this task exists. Do we ultimately want two maintenance scripts here: one for populating the content model and one for bulk-changing content models? Or maybe T104275 should just be folded into this task?
The maintenance script that we wrote for this task uses WHERE page_content_model IS NULL , FWIW.
Change 221755 merged by jenkins-bot:
Add maintenance script to populate page,revision,archive.*_content_* fields
Change 221981 had a related patch set uploaded (by Catrope):
Add maintenance script to populate page,revision,archive.*_content_* fields
Change 221982 had a related patch set uploaded (by Catrope):
Add maintenance script to populate page,revision,archive.*_content_* fields
Change 221981 merged by jenkins-bot:
Add maintenance script to populate page,revision,archive.*_content_* fields
Change 221982 merged by jenkins-bot:
Add maintenance script to populate page,revision,archive.*_content_* fields
The purpose of this script (T103388) is just to make the database store the current state (this is important because the defaults can change). Changing the state in response to a user or sysadmin request would be a different script.
Removing the blocked by's. It might be a blocker to T104278: E7. Run populateContentModel.php for page on all WMF wikis, but not to this one.