When ContentHandler support was added to MediaWiki in 2012, the content
type and content model of a revision is stored with it. However, the DB
tables for WMF wikis did not have the new columns, so
$wgContentHandlerUseDB was set to false on our wikis.
Eventually the database jobs to add and populate the columns completed, and
$wgContentHandlerUseDB has been true on some wikis including mediawiki.org
for months. There are several projects that are requesting this be set
true everywhere, T51193.
However, changing the content model of an existing page is a disruptive
change. We added the right `editcontentmodel` without which attempts to
change content model through the API or EditPage.php fail. Currently no
group (user or bot) has this right. So we think it's OK and safe to enable
$wgContentHandlerUseDB on WMF wikis.
is the patch.
There are issues with granting the editcontentmodel right, see T85847.
The Flow discussion and collaboration software has its own contentmodel.
Currently the Flow team changes a talk page to a Flow board by editing a
PHP config variable (!), which doesn't scale. (FYI, plans for enabling Flow
are at , and it is happening slowly.) When we do we archive the
existing talk page content.
The first change to the status quo is allowing a *new* page to be a Flow
board. In particular, the Co-op project wants to provide a Flow board
for each new editor who signs up to collaborate with a mentor. This
doesn't feel like changing the content model of a page, since there was
nothing present before. So Flow has its own right, 'flow-create-board',
which we grant to flow-bot group; attempting to add a Flow topic or Flow
board header to an non-existent page fails unless the user has this right.
The Co-op team will ask the Bot Approval Group on enwiki to grant their bot
Eventually we envision having a Special:Flowify page that will let admins
turn a page into a Flow board. This will run PHP code to archive the
current page, handle redirects, and then create a Flow board revision, etc.
This feels like the 'editcontentmodel' right, but it will probably be a
more restrictive right, 'flow-flowify'.
Daniel Kinzler proposed that we should not grant the editcontentmodel right
because any change to content model is a special case that requires smart
handling via dedicated PHP code. Which is what Flow is doing for both the
Co-op bot and the future Special:Flowify.
So is there anything to discuss? :)
Relax, is happening slowly.