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. https://gerrit.wikimedia.org/r/#/c/170129/ 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 [1], 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[2] 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 this right.
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? :)
[1] https://www.mediawiki.org/wiki/Flow/Rollout Relax, is happening slowly. [2] https://en.wikipedia.org/wiki/Wikipedia:Co-op
On Fri, Jan 9, 2015 at 7:25 PM, Erik Bernhardson <ebernhardson@wikimedia.org
wrote:
The Co-op team will ask the Bot Approval Group on enwiki to grant their bot this right.
*enwiki BAG hat on*
FYI, they'll be asked to advertise the request on enwiki [[WP:VPR]], and probably [[WP:AN]] wouldn't hurt too. They can save time by doing those advertisements right away instead of waiting to be asked.
Hi,
On 01/09/2015 04:25 PM, Erik Bernhardson wrote:
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. https://gerrit.wikimedia.org/r/#/c/170129/ is the patch.
I think this is fine to turn on as well.
There are issues with granting the editcontentmodel right, see T85847.
I disagree that we need a "editcontentmodel" user right. I think all users should be allowed to change the content model of a page (provided they have the right to edit it, etc.). Changing the content model of a page is currently disruptive because the only way to do it (and undo it) is via the API[1], and normal tools like undo don't work[2]. For now I'd suggest we grant it to syops and then later on grant it to '*' by default.
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.
That might make sense for changing the content model of an existing page, but I don't think it applies for when we want to create a new page with a content model different from the default. For example, in the MassMessage extension we let people create pages with the "MassMessageListContent" type wherever they want. It's not set as a default anywhere meaning that you currently need the "editcontentmodel" right to just create a list. :/
[1] https://phabricator.wikimedia.org/T72592 [2] https://phabricator.wikimedia.org/T73163
-- Legoktm
On 01/22/2015 10:00 PM, Legoktm wrote:
I disagree that we need a "editcontentmodel" user right. I think all users should be allowed to change the content model of a page (provided they have the right to edit it, etc.).
I think that setting a content model different from the namespace's default only makes sense in certain cases.
E.g. it may not make sense for schema-tized JSON (whether it's Zero config, EventLogging schema, Wikidata JSON etc.) to be outside its dedicated namespace.
It probably doesn't make sense for CSS files or JS files to exist outside of the MediaWiki and User namespaces, and even in those namespaces, the content model should probably match the end of the title.
Similarly, dedicated namespaces (e.g. Wikidata's main namespace) should not be able to hold wikitext pages.
Matt Flaschen
On Jan 23, 2015 8:43 PM, "Matthew Flaschen" mflaschen@wikimedia.org wrote:
On 01/22/2015 10:00 PM, Legoktm wrote:
I disagree that we need a "editcontentmodel" user right. I think all users should be allowed to change the content model of a page (provided they have the right to edit it, etc.).
I think that setting a content model different from the namespace's
default only makes sense in certain cases.
E.g. it may not make sense for schema-tized JSON (whether it's Zero
config, EventLogging schema, Wikidata JSON etc.) to be outside its dedicated namespace.
It probably doesn't make sense for CSS files or JS files to exist outside
of the MediaWiki and User namespaces, and even in those namespaces, the content model should probably match the end of the title.
Similarly, dedicated namespaces (e.g. Wikidata's main namespace) should
not be able to hold wikitext pages.
From a security perspective, I like limiting the content models per
namespace to a relatively small whitelist. I think it will give more flexibility to anyone coming up with new content type definitions if we don't have to worry about "what happen if someone changes main page to this format" or "how do i write a lossless conversion script from a flow page and back, just in case an admin converts a flow page to my new type and back."
Matt Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 01/24/2015 07:52 AM, Chris Steipp wrote:
From a security perspective, I like limiting the content models per namespace to a relatively small whitelist. I think it will give more flexibility to anyone coming up with new content type definitions if we don't have to worry about "what happen if someone changes main page to this format" or "how do i write a lossless conversion script from a flow page and back, just in case an admin converts a flow page to my new type and back."
This can already by done by overriding ContentHandler::canBeUsedOn() in individual content handlers.
-- Legoktm
I agree with pretty much all of this. In my mind, editcontentmodel is a temporary hack that should go away completely once the bugs that led to its creation are fixed.
Jackmcbarn
On Fri, Jan 23, 2015 at 1:00 AM, Legoktm legoktm.wikipedia@gmail.com wrote:
Hi,
On 01/09/2015 04:25 PM, Erik Bernhardson wrote:
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. https://gerrit.wikimedia.org/r/#/c/170129/ is the patch.
I think this is fine to turn on as well.
There are issues with granting the editcontentmodel right, see T85847.
I disagree that we need a "editcontentmodel" user right. I think all users should be allowed to change the content model of a page (provided they have the right to edit it, etc.). Changing the content model of a page is currently disruptive because the only way to do it (and undo it) is via the API[1], and normal tools like undo don't work[2]. For now I'd suggest we grant it to syops and then later on grant it to '*' by default.
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.
That might make sense for changing the content model of an existing page, but I don't think it applies for when we want to create a new page with a content model different from the default. For example, in the MassMessage extension we let people create pages with the "MassMessageListContent" type wherever they want. It's not set as a default anywhere meaning that you currently need the "editcontentmodel" right to just create a list. :/
[1] https://phabricator.wikimedia.org/T72592 [2] https://phabricator.wikimedia.org/T73163
-- Legoktm
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Jackmcbarn wrote:
I agree with pretty much all of this. In my mind, editcontentmodel is a temporary hack that should go away completely once the bugs that led to its creation are fixed.
This is now being discussed at https://phabricator.wikimedia.org/T92794.
MZMcBride
wikitech-l@lists.wikimedia.org