Page MenuHomePhabricator

Default page restrictions for each namespace
Closed, ResolvedPublic

Description

Author: lowzl

Description:
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.


Version: unspecified
Severity: enhancement

Details

Reference
bz2073

Related Objects

StatusSubtypeAssignedTask
ResolvedNone
ResolvedNone

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:27 PM
bzimport set Reference to bz2073.
bzimport added a subscriber: Unknown Object (MLST).

lowzl wrote:

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.

attachment per-namespace-default-restrictions.patch ignored as obsolete

wegge wrote:

  • 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 ) )

lowzl wrote:

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.

lowzl wrote:

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

attachment default-restrictions-per-namespace.patch ignored as obsolete

wegge wrote:

  • 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.

lowzl wrote:

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.

attachment default-restrictions-per-namespace.patch ignored as obsolete

lowzl wrote:

Patch against 1.5beta1

Updated patch for 1.5beta1.

attachment default-restrictions-per-namespace.patch ignored as obsolete

zigger wrote:

See also bug 1924 (Restricted read access for subset of wiki), which also has
patches.

zigger wrote:

*** Bug 3126 has been marked as a duplicate of this bug. ***

lowzl wrote:

Patch against 1.5.6

Attached:

robchur wrote:

It might be worth closing this in favour of an extension request...

lowzl wrote:

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...

Attached:

ayg wrote:

This has been added in the form of $wgNamespaceRestrictions. See
[[mw:Manual:$wgNamespaceProtection]].