Last modified: 2011-03-13 18:05:16 UTC
Maybe this is a new feature request, but here goes: Rule: Protect User: pages from editing from everyone except sysops and registered user that "owns" user: page
Halló! If a feature like this would be implemented then it probably should provide some flexibility: Users should be able to protect / unprotect own pages as [[User:foo]] but probably not [[User talk:foo]]. Question: What should be the *default* value *unprotected* as it was until now or *protected*? Questions arive what should happen to subpages? [[User:foo/bar]] might be handled the same way but probably not [[User talk:foo/bar]]. Skin pages have a special treatment already (they are protected): [[User:foo/Monobook.css]], [[User:foo/Monobook.js]] etc. Maybe also Java subpages. How should the enhancement handle these. Regards Reinhardt
(In reply to comment #1) > Halló! > > If a feature like this would be implemented then it probably should provide some > flexibility: > Users should be able to protect / unprotect own pages as [[User:foo]] but > probably not [[User talk:foo]]. > Question: What should be the *default* value *unprotected* as it was until now > or *protected*? > > Questions arive what should happen to subpages? > [[User:foo/bar]] might be handled the same way but probably not [[User > talk:foo/bar]]. > > Skin pages have a special treatment already (they are protected): > [[User:foo/Monobook.css]], [[User:foo/Monobook.js]] etc. Maybe also Java > subpages. How should the enhancement handle these. > > Regards Reinhardt Thanks, Reinhardt. I appreciate the chance to collaborate. I agree with all your points about flexibility. Allow users to turn off/on protection of user pages. I suggest the default value should be protection on. I also agree with your assesment of user talk pages and sub pages. No changes necessary there. I am not familiar with your comments regarding Java subpages, etc. Hopefully, the intent of this suggestion will lead to a clear path for any extension of this enhancement. Thx Cd
I've implemented this protection (without any options) for my wiki by adding the following to includes\Title.php, function userCan($action): if( NS_USER == $this->mNamespace && $wgUser->getName() != $this->mTextform && (substr_compare($wgUser->getName().'/',$this->mTextform,0,strlen($wgUser->getName())+1) != 0) && !$wgUser->isAllowed( 'sysop' )) { wfProfileOut( $fname ); return false; } The code is similar to the protection for user skin and user JavaScript.
Mr. Keppler, I successfully added the code you supplied to my wiki. With some modification. And after a brief test, I believe it to be working satisfactorily. However, I did have to comment out the second conditional statement because of syntactic error otherwise. Could you explain that condition in a little more detail? What do you think the consequences are of not referencing the second condition in terms of the intent of the enhancment? In any case, I still propose that Mediawiki provide users the capability to turn on/off page protection of their individual user pages. Thanks cp
slight difference without the option for the user to protect / unprotect the *own* user page the requested *feature* would be a *change* not a simple *enhancement* Many (wikimedia foundation) wiki's have thousends of registered users where the last contribution is several months ago. Sometimes I wonder if some of these accounts have been created with bots ... From the view pont *enhancement* versus *change* the "default value" should be "unprotected". Anyhow protect / unprotect the *own* user page implays a new context related tag (namespace user and "own user page") and probbably a new action "protect own user page" and optional implamentation in [[Special:Groups]] if it would not be "hardcoded". Regards Reinhardt
(In reply to comment #4) > However, I > did have to comment out the second conditional statement because of syntactic > error otherwise. I guess you use php 4.x? That doesn't yet have the substr_compare function. > Could you explain that condition in a little more detail? > What do you think the consequences are of not referencing the second condition > in terms of the intent of the enhancment? The second statement is for sub pages of user pages. That statement looks for page titles of the form "Username/somesubpagename" (it actually only looks for the beginning including the slash). So if you don't have sub pages enabled for the user name space, you will not even notice this missing statement. :) Ciao, Michael.
