Last modified: 2007-05-08 16:15:37 UTC
This feature may be useful in some circumstances, for instance, a late-Nupedia-like set up where the general public can edit draft pages, while the main article namespace is protected (by default) from editing/creation/moving etc.
Created attachment 499 [details] Proposed patch Explanation: Title.php is modified so that new articles can't be created in protected namespaces. Article.php is modified so that new articles will be created with the default restrictions. DefaultSettings.php is modified so that there are some example default restrictions.
* Does not apply to the current HEAD. * What happens when requesting for restrictions missing in $wgDefaultRestrictions? * Why not use NS_MAIN, NS_MEDIAWIKI instead of numbers in DefaultSettings.php? * Documentation in DefaultSettings.php could be better * The patch doesn't follow the coding conventions in all places: (! isset($restrictions)) should be (! isset( $restrictions ) )
> Does not apply to the current HEAD. It was originally written against 1.5beta1. I'll see about rewriting it for HEAD. > What happens when requesting for restrictions missing in $wgDefaultRestrictions? + // check if $restrictions is still NULL. (i.e. missing entry in $wgDefaultRestrictions.) PHP is quite lax about missing items in arrays - it will return NULLs instead of errors. > Why not use NS_MAIN, NS_MEDIAWIKI instead of numbers in DefaultSettings.php? Defines.php may not have been included yet, I'm not sure.
Created attachment 561 [details] Patch against HEAD of phase3 module I used this command to retrieve the source, I hope that it is the correct one: cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/wikipedia co -P phase3
* Cosmetic: use tabs for indentation. Your patch contained spaces instaed, so it did not apply without ignoring whitespace. * Useage: Did you actually test this version of the patch? I was unable to see any results, no matter what restrictions I put on NS_MAIN. In Title.php/getRestrictions, I find this: if ( 0 == $id ) { $res = $wgDefaultRestrictions[$this->mNamespace]; ... // check if $restrictions is still NULL. (i.e. missing entry in $wgDefaultRestrictions.) if (! isset( $res ) ) { $res = ''; ... } else { $dbr =& wfGetDB( DB_SLAVE ); $res = $dbr->selectField( 'page', 'page_restrictions', 'page_id='.$id ); } (You see the point about indentation?) What happens is that IF a new page is edited, and IF no default restrictions are set, THEN it's restrictions are pulled from the database. That doesn't make a whole lot of sense to me.
Created attachment 562 [details] Brace mismatch correction I apologise. (Profusely.) I copied & pasted from a terminal screen, so tabs were expanded into spaces. The brace mismatch occured when I moved code around. I thought it was a single-line if block (I'm used to start-brace-on-new-line, you see), so I didn't spot the error.
Created attachment 650 [details] Patch against 1.5beta1 Updated patch for 1.5beta1.
See also bug 1924 (Restricted read access for subset of wiki), which also has patches.
*** Bug 3126 has been marked as a duplicate of this bug. ***
Created attachment 1323 [details] Patch against 1.5.6
It might be worth closing this in favour of an extension request...
Created attachment 2049 [details] Extension for MediaWiki 1.6 and later I rewrote it as an extension when time came to deploy MediaWiki 1.6 on the server. It makes use of a new hook, ArticleInsertComplete, so isn't much use for older versions...
This has been added in the form of $wgNamespaceRestrictions. See [[mw:Manual:$wgNamespaceProtection]].
