"IAlex" posted a comment on MediaWiki.r106567.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106567#c28227

Commit summary for MediaWiki.r106567:

* Merged WikiPage::updateRestrictions() and Title::updateTitleProtection() into 
WikiPage::doUpdateRestrictions(); older methods still work for backward 
compatibility, but marked Title::updateTitleProtection() as deprecated and for 
removal in 1.20 since no extension calls it
* Removed permissions check from WikiPage::doUpdateRestrictions() and left it 
for callers, resolves the todo from documentation
* Inverted $expiry and $reason parameter between 
WikiPage::doUpdateRestrictions() and WikiPage::updateRestrictions() for more 
consistency; WikiPage::doUpdateRestrictions() also requires all parameters to 
be passed
* WikiPage::doUpdateRestrictions() returns a Status object instead of bool for 
the older one; only possible error at the moment is a read-only database
* Updated core calls to these functions
* Made maintenance scripts using it simply protect all actions returned by 
Title::getRestrictionTypes() instead of hardcoded 'edit' and 'move'
* This also means that protect.php can be used to protect a non-existing page 
for creation

IAlex's comment:

The point was to merge similar functions, and in fact the front-end code 
doesn't distinguish between these two cases. You can see in two places 
(ApiProtect.php and ProtectionForm.php, the latter was commited in the next 
revision) that the code had to call the correct function depending on whether 
the page exists or not and that one of those two functions is in Title and the 
other one is in WikiPage.

For the protection types, I think the best thing would be to let the user 
decide which types he would like to protect and in case he doesn't provide any 
choice, just use all protection types.

_______________________________________________
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Reply via email to