Extension talk:Page access restriction

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

1.8 support

And what about v. 1.8?! - CharlesC 11:23, 1 November 2006 (UTC)

• I'm download the version 1.8.1 of wikimedia for intranet use. After read this page for restrict access, i used and works. I'm download the patch for 1.7.1 and replace the "1.7.1" entries by "1.8.1" in a text editor. When i'm patching, promt-me about find some languajes messages files, but dont exist, for that reason i choose skip. - Elidio M. --201.148.140.147 22:21, 8 November 2006 (UTC)

• Noob question: is there a release for 1.8.2 which doesn't require applying a patch? I'm running 1.8.2 on a windows server (yuck) and don't have access to all the cool big boy tools like patch. Roy --Rmiller 23:08, 28 December 2006 (UTC)
  • I doubt there are pre-patched 1.8x (or 1.9x) releases. You can find patch binaries on windows. there are standalone versions or you could use cygwin.

• I have a version of 1.9.x running on my machine and I want to install this patch desperately.Is a version of patch that will help me do this?

1.7 Support

Does anyone know if support for mediawiki 1.7 is being worked on?

From Jerome's website re 1.7 support

his reasons for transitioning from a patch to an extension

'Hi Andy and all,

The patch doesn't work for 1.7.1. As you see many modifications are rejected when patching, due to MW changes.

I think I will not update this patch anymore. I am thinking about an extension, what is more stable when MW updates.

I cannot give any date for the first release, just subscribe to the mailing list to keep in touch :) [restrict-mediawiki-list-subscribe@conseil-recherche-innovation.net restrict-mediawiki-list-subscribe@conseil-recherche-innovation.net])

Read you, Jerome'

-Jinkee 13:27, 9 August 2006 (UTC)

Previously Untitled Questions and Answers

You wrote: This feature is mainly useful for intranet relying on WikiMedia as a non-encyclopedic content  
management system, like e-learning platforms or informational systems. It is not appropriate to use it to 
restrict public access!

I really like on the page editing. I was hopign that I would be able to use WikiMedia as a non-encyclopedic content management system on the web, and to prevent public access from the editing tabs for instance (I came here in search of a way of removing the edit tab for everyone except me). But from what you say above it sounds like it is not possible to use Wikimedia in this way. Can this be true?

In fact you can use the patch freely, for the use you want... I just added this warning as it is not in the wiki philosophy to restrict access to pages. The restriction feature is not like hiding the 'edit tab' (the protect tab does it), it avoid users to access and modify pages.

Jej

---

I see. Also perhaps I can use the 'protect' tab to do what I want. Thank you. The "Philosophy" sounds rather sad though. We all have different ones and they keep us apart.

I'm using MediaWiki to run an internal portal at a small company. One of the management types asked me recently if he could restrict access to certain pages, so I think your patch is exactly the right thing. Any idea on whether it will be merged into the main branch of the source? I know it's not really useful for wikipedia, but it would be nice not to have to patch every new version that I wanted to run...

gjm

I think we have to wait for stable 1.5 before to propose this feature. This version has a new security model, so probably page restriction will be easier and safer to implement. As you say mediawiki is wikipedia oriented so this feature is not useful for the project and maybe has no chance to be merged. So, the patch is a good alternative for now in spite of update problems. But after 1.5 we will have to redo all the job... Another solution would be to think about a new kind of tool, between wiki and formal content management system.

Jej 11:49, 4 May 2005 (UTC)

---

I might just be missing something, but the phrase "optionaly the user's pages can be restricted to their owner" suggests that this patch will let me do what I want, but I don't seem to be able to get it to work. The desired behavior is this:

I have a MediaWiki used for tracking role-playing campaigns. I've set it up so that anyone can read, but only registered users (i.e. the players) can edit. There are times, however, when a player wants to post something that they don't want other players to read. The idea would be that only they (the creator of the page) and the gamemaster (a sysop) would be able to read or edit it.

The line "optionaly the user's pages can be restricted to their owner" seems to indicate that the player could use the restriction feature on pages they create, but this doesn't seem to be the case. What am I missing?

-- Wordman

I should precise "user home page" only (not pages created by a single user). I mean that the User:XXXX page is only readable/writeable by user XXXX and people in the restrict group. The feature you ask is interesting but need further work on the mediawiki engine. I add it to the todo list. Maybe for mediawiki 1.5...

Jej 8 July 2005 10:15 (UTC)

---

I'm somewhat confused here. So, this patch will allow me to restrict pages only to the restrict group, or will it allow me to restrict pages to a specific group (preferably a custom defined group)?

-- Ryan

Multiple groups?

Is there a way to define multiple access groups? So that, for example, folks in dept. B-52 can't see the pages created by those in A-51, and vice-versa. Or that folks in dept C can see all the pages, but not edit them. etc. 192.35.232.241 21:27, 14 October 2005 (UTC)

No... It requires probably to go deeper in MW hacking (modify the database scheme for example).

Jej

well, in the database scheme of mediawiki 1.5.x, table page, there is a field called page_restrictions. Some comments lining out that there could be a list of comma-seperated entries representing something like edit=groupX, move=sysop, view=* . In search for a solution of exactly the same problem, I've grep'ed for page_restriction, mRestriction, but I found no Functions handling these array-elements. Possibly in a new release. A fiew use-cases are in Article.php, Title.php, but I have not seen real Group handling. Who knows more about it ? I think, this would be an often needed feature for intra-wiki solutions (like mine) --GerhardSchwarz 09:45, 4 April 2006 (UTC)

Has anyone found a solution to this question/problem? Define multiple access groups and restrict pages according to access groups? Thanks.

142.104.170.192 00:25, 18 May 2007 (UTC)

New Version?

I'm currently using 1.5.3, this patch does exactly what I need it to do, but I’m not sure if patching 1.5.3 with this outdated patch will work... I'm using it to make a wiki on the internet that is basically half inter and have intra. So that developers on my project who are all over the country can work together on the unreleased projects, but at the same time publish projects to the web and so forth. I need to have restricted pages to even begin using my wiki unfortunately, as the primary use of it will be internal developers working on an unpublished project.

mortico@yahoo.com Dec.14.2005

UPDATE: I’ve successfully installed the patch on 1.5.3 - I read the raw patch file and took note of the files that would be modified if I patched. I don't have Linux so I downloaded the archive for the pre-patched version of this mod. The pre-patched version is only 1.5.2 and contains the entire MediaWiki, and I’m using 1.5.3 and with the many modifications I’ve already made to it, I didn't want to start over. So I went through the archive of the pre-patched version and took out only the files that the patch file said it would modify. I then wrote those files over their 1.5.3 counterparts and added the prescribed lines to the localsettings.php file. After that I crossed my fingers and it worked!

To save some of you some effort if you have the same issue, I have all the modified files archived without the rest of the 1.5.2 package. Just use these files to overwrite the corresponding 1.5.3 files and it should work. You'll need to edit the LocalSettings.php manually of course.

mediawiki-1.5.2-restriction-patch-beta-0.59-repacked-for-1.5.3.rar

mortico@yahoo.com Dec.14.2005

New version of the patch for 1.5.3

In fact the patch for version 1.5.2 applies well on the 1.5.3 version. I uploaded a new version of the patch and archive for this MW version. Next time, just remind me there is a new version of MW, it will save your time :) Jej

1.6Devel

I am using 1.6devel on one of my wikis and was wondering when you might have a patch ready for 1.6devel. I could really use it! --Kf4bdy 01:03, 23 December 2005 (UTC)

1.5.4

BTW, They released a new version today 1.5.4. Just thought you would like the heads up. --Kf4bdy 01:11, 23 December 2005 (UTC)

Handy for customer support

This patch will be extremely useful for writing documentation sets which should be generally visible, but have a few sensitive pages that should be only be seen by internal staff, like internal resource planning or comments on customers. The extension to have multiple groups, so a customer could see their own page but not someone else's, would be useful, but not vital.

User:jrbray 4 Jan 06

Multiple groups needs a deeper modification of the MW security model and forms managment. I think it's better to wait for some improvements in these directions. But I understand and agree that's it's not the priority of the MW dev team for now.

Jej 09:30, 20 January 2006 (UTC)

How to patch Mediawiki running in Windows Environment?

I notice the patch command is working in Linux. How can patch it in Windows?

You can download a full patched archive. Else you can try cygwin tools... Jej 08:04, 28 April 2006 (UTC)

Just how invisible are the hidden pages?

You say that users outside the right groups cannot read, search, export etc. hidden pages, but does that also prevent hidden pages from showing up in (for instance) Recent Changes, or other special pages? Does it really filter them out from anywhere content might be leaked? (I'm using the feasibility/requirements section from Hidden_pages as a guideline) Thibgc 08:29, 9 March 2006 (UTC)

Update: It looks from inspecting the files that are modified by the patch that the restrictions are pretty thorough, but I'm no MediaWiki hacker. Thibgc 10:04, 9 March 2006 (UTC)

Yes I tried to do the best to eliminate restricted pages title from everywhere (search, rc, export, etc). Except restricted pages with regex, for whose the titles can be displayed (but pages content not viewable). A special page lists all restricted pages (for allowed members only). Jej 08:10, 28 April 2006 (UTC)

About that special page that lists restricted pages, it doesn't appear to be showing my list of pages, it's just empty? Any ideas? Otherwise it seems to be working great! Thanx... --D0li0 23:38, 6 December 2006 (UTC)

At least you can see your Special:Restricted page. Even as a Sysop with all the restrict rights, when I attempt to go there, I get:

You have requested an invalid special page.
A list of valid special pages can be found at Special:Specialpages. 
Return to Main Page.

- Marc 09/27/07

Recent MediaWiki versions? (e.g. 1.5.7)

Is the patch still up to date for a more recent version of MediaWiki like 1.5.7? Thibgc 08:29, 9 March 2006 (UTC)

Update: I see that things have been more up to date on your website, at http://conseil-recherche-innovation.net/index.php/1974/04/11/41-restrict-pages-under-mediawiki-15 Thibgc 10:02, 9 March 2006 (UTC)

Small bug

Can't figure out why (I'm no expert) but when clicking Unrestrict to unrestrict a page, the title "Confirm unrestriction" is correct, reason is correct "Reason for unrestricting:" but just above that it says "Do you really want to restrict this page?" instead of UNrestrict! Tried it several times on different pages, always the same wrong word. Looking in the Special messages file, all seems to be correct though! Can you test this and verify? Thank you - mathabaTAKETHISOUT@gmail.com 29march2006

Thanks, I will check and fix it. Jej 08:12, 28 April 2006 (UTC)

Problem in 1.6.7?

1.6.7 the file SpecialRecentchanges.php appears to be significantly different than what your patch suggests. Any ideas on how to include this code correctly in this version of MediaWiki? Maybe I should be in the rightfile. SpecialRecentchanges.php isn't supposed to be changed, it's SpecialRecentchangeslinked.php. I don't feel at all foolish.

Looks like I have it working, but I need to test it. I'm going to have to go through and restrict every page I want restricted (after confirming that I can actually unrestrict pages).

Also, I had to do this by hand because my shared hosting server won't allow me to use the Patch command. Hence I have a copy of all of the individual files that had to be changed for Mediawiki 1.6.7 and will post a link to them momentarily.

You can download a copy from my personal webserver here.

Please read the README.txt file, and please only do this download if you do not have the patch command available as I would like to save on my bandwidth for this website.

Dwees

Workaround

As far as I have tested, but I have little idea, it is possible to access any protected page by creating a new one pointing towards it (with the tag #REDIRECT restricted_page)... --Triuri 05:14, 20 May 2006 (UTC)

I have tested this and cannot seem to make it work. So as far as I can tell it does not break the protection. Version 1.6.5 patched. --Kf4bdy 19:06, 20 May 2006 (UTC)

I'll check the localsettings file, maybe I have done something wrong there. It's the same version.--Triuri 17:14, 21 May 2006 (UTC)

No problem with redirections, I confirm. Jej 08:22, 22 May 2006 (UTC)

Translation Questions (moved from article page)

Q: I translate it in /languages/MessagesCs.php, nothing happend still in English. So I translate it in Messages.php but surprisingly, it still talk in English. What I do wrong? (Test on different computers so browser cache is it not.)

Is the rest of the interface in Czech? Send me your MessagesCs.php so I can investigate. Thanks. Jej 08:23, 7 June 2006 (UTC)

Q: Hi I ve got the same problem with czech language. Could you help me?

Restrict Special Page

Q: Hi, How to restrict special page? Thank You

It's a native feature of mediawiki -> m:Preventing Access#Preventing access to some SpecialPages

Jej 15:42, 9 November 2006 (UTC)

UserPageRestrict=true (read,!edit)

See Page_access_restriction_with_MediaWiki#Readable_Restricted_Users_Pages as this feature has been enhanced and added to the restriction patch version beta-0.8.2

I have modified the way $wgUserPageRestrict = true; functions in order to allow users to still read, but not edit other users User: pages. They can now only edit their own user page, unless they are members of a new special group. everyone can still edit the users talk page. --D0li0 00:02, 7 December 2006 (UTC)

Perhaps this would be better if it had it's own added option like $wgUserPageRestrictReadable = true;

1. In includes/Title.php comment out the return false; line in the userCanRead() function for the // restricted user pages code block to allow everyone to read user pages.
2. Copy that // restricted user pages code block from the userCanRead() function into the userCanEdit() function, see below
3. Add a usereditors group to the LocalSettings.php, these users can edit other users pages. viewrestrict users can also edit users pages, yet usereditors can not view or edit the normal restricted pages. This could probably be changed such that only restrict and edituser are allowed to edit user pages, which may be more appropriate...

includes/Title.php commented out return false; within userCanRead function.

               // restricted user pages ?
               if ( $wgUserPageRestrict == true ) {
                       if ( $this->getNamespace() == NS_USER
                            && $wgUser->getName() != $this->getText() ) {
                               if ( ! $wgUser->isAllowed('viewrestrict') ) {
//                                      return false;
                               }
                       };
               }

includes/Title.php new userCanEdit function.

       function userCanEdit() {
               global $wgUser, $wgUserPageRestrict;
               // restricted user pages ?
               if ( $wgUserPageRestrict == true ) {
                       if ( $this->getNamespace() == NS_USER
                            && $wgUser->getName() != $this->getText() ) {
                               if ( ( ! $wgUser->isAllowed('viewrestrict') )
                                 && ( ! $wgUser->isAllowed('edituser') ) ) {
                                               return false;
                               }
                       };
               }
               return $this->userCan('edit');
       }

Add this to LocalSettings.php for a group of users who can edit other users pages.

$wgGroupPermissions['usereditors']['edituser'] = true;

Inverse Restriction

Q: Is the Inverse Restriction code instead of, or in addition to the code above it? Mensch 12:53, 23 March 2007 (UTC)

problem with the wgRestrictNewPages option

I'm having some trouble with the $wgRestrictNewPages option, It doesn't seem to work with the update for MW1.10. I have verified that it does work with MW1.6.7 and the older 0.64 patch, although the new page appears in the recent changes unlike edits to restricted pages, but that's a separate issue perhaps.

I'm not sure if I broke this in the 0.8.+ updates, or if it was broken by some previous change. perhaps the 0.70 change regarding "SQL requests are not modified anymore to check the restriction". I'm assuming that it was already broken in the 0.8 update. Can anyone verify that $wgRestrictNewPages was still working with the use of patch versions 0.70, 0.71, 0.72, or 0.8? to help track down the problem? --D0li0 22:54, 7 June 2007 (UTC)

installing the patch?

Noob: Where do I actually upload the patch to before i enter the commands? Bouncingmolar 14:08, 8 June 2007 (UTC)

per Page_access_restriction_with_MediaWiki#Quick_summary_of_what_I_did_to_get_this_running

You place the patch in the root folder of your mediawiki installation and then run the patch command. --D0li0 10:37, 9 June 2007 (UTC)

cheers :) Bouncingmolar 14:55, 10 June 2007 (UTC)

restricting viewing of pages

I've managed to install this patch. I can restrict editing of a tab, but how to I prevent all users and new users from viewing those pages; I would like to stop people from seeing restricted pages except the ones with viewing rights. I made a new account and I can see the restricted page ok... just can't edit it. Bouncingmolar 08:23, 12 June 2007 (UTC)

bug in 1.10 against postgresql

The patch installed fine, but I was getting an error on trying to protect a page. line 70 in SpecialPage.php was $this->whereClauses[] = 'log_type !="restrict"'; and I changed it to $this->whereClauses[] = "log_type !='restrict'"; since in PostgresQL double-quotes signify table/column names, not strings

Patching MW 1.11

After running the 1.10 patch (http://www.dolio.net/restriction-beta-0.8.3.mediawiki-1.10.0.patch) on MW 1.11, I got the following:

/wiki> find . -name '*.rej'
./includes/OutputPage.php.rej
./includes/Parser.php.rej
./includes/SpecialCategories.php.rej
./includes/SpecialNewimages.php.rej
./includes/Title.php.rej
./languages/messages/MessagesCs.php.rej
./languages/messages/MessagesHe.php.rej
./languages/messages/MessagesEn.php.rej
./languages/messages/MessagesRu.php.rej
./skins/monobook/main.css.rej

After taking a look at the *.rej files, I attempted to make my own modifications and they appear to be working properly upon first glance. Here are the diffs between the originals and the new version. I regret not having the knowledge for making a patch for this.

Please note that have no PHP or coding knowledge at all. I did this just by looking at what the .rej files were giving me and attempted to do what I thought was right. If anyone notices anything wrong, or any changes I should make, please feel free to say so.

- Marc 09/27/07 12:42 PM EST

./includes/OutputPage.php

 /wiki> diff includes/OutputPage.php.orig includes/OutputPage.php
 932a933,948
 >       function restrictGroupRequired() {
 >               global $wgUser, $wgTitle;
 >
 >               $this->setPageTitle( wfMsg( 'restricttitle' ) );
 >               $this->setHTMLTitle( wfMsg( 'errorpagetitle' ) );
 >               $this->setRobotpolicy( 'noindex,nofollow' );
 >               $this->setArticleRelated( false );
 >               $this->mBodytext = '';
 >
 >               $sk = $wgUser->getSkin();
 >               $ap = $sk->makeKnownLink( wfMsgForContent( 'administrators' ), '' );
 >               $this->addHTML( wfMsg( 'restricttext', $ap ) );
 >               $this->returnToMain( false );
 >       }
 >
 >

./includes/Parser.php

/wiki>diff includes/Parser.php.orig includes/Parser.php
3134a3135,3137
>                                           if (!$title->userCanRead())
>                                                       $articleContent = "";
>                                               else

./includes/SpecialCategories.php

/wiki> diff includes/SpecialCategories.php.orig includes/SpecialCategories.php
55a56
>               if ($GLOBALS['wgEnableRestrict'] and $title->isRestricted() and ! $GLOBALS['wgUser']->isAllowed('viewrestrict')) return "".wfMsgHtml( 'restricttitle' )."";

./includes/SpecialNewimages.php

/wiki> diff includes/SpecialNewimages.php.orig includes/SpecialNewimages.php
137a138
>               $img = Image::newFromTitle( $nt );
140c141,142
<               $gallery->add( $nt, "$ul
\n".$wgLang->timeanddate( $s->img_timestamp, true )."
\n" );
---
>               if (! $GLOBALS['wgEnableRestrict'] or ! $nt->isRestricted() or $GLOBALS['wgUser']->isAllowed('viewrestrict'))
>                      $gallery->add( $img, "$ul
\n".$wgLang->timeanddate( $s->img_timestamp, true )."
\n" );

includes/Title.php

/wiki> diff includes/Title.php.orig includes/Title.php
1255a1256,1291
>       * Does the title correspond to a restricted article?
>       * (restrict-patch by Jerome Combaz)
>       * @return boolean
>       * @access public
>       */
>       function isRestricted() {
>               global $wgEnableRestrict;
>
>               if ( $wgEnableRestrict == true ) {
>                       $a = $this->getRestrictions("view");
>                       if ( $this->isRegexRestricted() || (!empty($a) && $a[0] == true) ) return true;
>               }
>
>               return false;
>       }
>
>       function isRegexRestricted() {
>               global $wgEnableRestrict, $wgRegexRestrict;
>
>               if ( $wgEnableRestrict == true ) {
>                       foreach ( $wgRegexRestrict as $k=>$v ) {
>                               // Reverse restriction START
>                               // If an entry starts with "!!" and the remaining string matches the namespace,
>                               // the page is NOT restricted
>                               if (substr($v, 0, 2) == "!!") {
>                                       if (ereg (substr($v, 2), $this->makeName( $this->mNamespace, $this->mTextform) ) ) return false;
>                               } else
>                               // Reverse restriction END
>                               if ( ereg ( $v, $this->makeName( $this->mNamespace, $this->mTextform) ) ) return true;
>                       }
>               }
>
>               return false;
>       }
>
>       /**
1261c1297
<               global $wgUser;
---
>               global $wgUser, $wgUserPageRestrict, $wgUserReadRestrict, $wgUserPagePrivate;
1262a1299,1325
>               // restricted page ?
>               if ( $this->isRestricted() && ! $wgUser->isAllowed('viewrestrict') ) {
>                       return false;
>               }
>
>               // restricted user pages ?
>               if ( $wgUserPageRestrict == true ) {
>                  if ( $wgUserReadRestrict == false ) {
>                       if ( $this->getNamespace() == NS_USER
>                            && $wgUser->getName() != $this->getText() ) {
>                               if ( ! $wgUser->isAllowed('viewrestrict') ) {
>                                       return false;
>                               }
>                       }
>               } else {
>                       if ( $this->getNamespace() == NS_USER
>                            && $wgUser->getName() != $this->getText() ) {
>                               if ($wgUserPagePrivate) {
>                               foreach ( $wgUserPagePrivate as $k=>$v ) {
>                                       if ( ereg (substr($v, 2), $this->makeName( $this->mNamespace, $this->mTextform) )
>                                               && ! (substr_count($this->getText(), $wgUser->getName() ) ) )
>                                               return false;
>                                       }
>                               } }
>                       }
>               }
>

languages/messages/MessagesEn.php

/wiki> diff languages/messages/MessagesEn.php.orig languages/messages/MessagesEn.php
2879a2880,2908
> ##################
> #Restrict patch (m:Page access restriction with MediaWiki)
> ##################
> 'restrict' => 'Restrict',
> 'restrictthispage' => 'Restrict this page',
> 'unrestrict'    => 'Unrestrict',
> 'unrestrictthispage' => 'Unrestrict this page',
> 'restricttitle' => 'Restricted page',
> 'restricttext'  => 'This page is restricted. To view it you have to be member of the \'restrict\'  group or \'viewrestrict\' group.',
> 'restrictedpages' => 'Restricted pages',
> 'restrictlogpage' => 'Restriction_log',
> 'restrictlogtext' => 'Below is a list of page restrictions. See Project:Restricted page for more information.',
> 'restrictedarticle' => 'restricted $1',
> 'unrestrictedarticle' => 'unrestricted $1',
> 'restrictsub' => '(Restrict \'$1\')',
> 'confirmrestrict' => 'Confirm the restriction',
> 'confirmrestricttext' => 'Do you really want to restrict this page?',
> 'restrictcomment' => 'Reason for restricting',
> 'unrestrictsub' => '(Unrestrict \'$1\')',
> 'confirmunrestricttext' => 'Do you really want to unrestrict this page?',
> 'confirmunrestrict' => 'Confirm unrestriction',
> 'unrestrictcomment' => 'Reason for unrestricting',
> 'restrictreason' => '(give a reason)',
> 'tooltip-restrict' => 'Restrict this page',
> 'notallowedtomoverestrictedpagetext' => 'To move this page, you have to be member of the \'restrict\' group.',
> 'restrictedpagespagetext' => 'This page lists all restricted pages in the wiki. ',
> 'regexrestrictedpagespagetext' => 'All page titles matching this/these regular expression(s) are also restricted : ',
>
>

skins/monobook/main.css

/wiki> diff skins/monobook/main.css.orig skins/monobook/main.css
1587c1587,1593
< }
\ No newline at end of file
---
> }
>
> /* restriction patch tab style (white link on red background) */
> li#ca-unrestrict a {
>    color: white !important;
>    background-color: #ba0000 !important;

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.

small probs with 1.12 patch

hi, thx for this useful extension.

here is what i encountered:

languages/messages/MessagesDe.php

it should be:

$messages = array(
   'restrict' => 'Sperren',
   'restrictthispage' => 'Diese Seite sperren',
   ...

the additional lines are all patched around line 30- 60 but the start of $messages array is around line 162, so i moved that because of obvious syntax error - checked only for german message file.

And the following error, which i check later: on page Special:Restrictedpages resp. Spezial:Restrictedpages

Warning: SpecialPage::require_once(/var/www/localhost/htdocs/mediawiki_flo/includes/SpecialRestrictedpages.php) [function.SpecialPage-require-once]: failed to open stream:
No such file or directory in /var/www/localhost/htdocs/mediawiki_flo/includes/SpecialPage.php on line 675

groovehunter 12:04, 23 July 2008 (UTC)

1.16 support

Just wondering if this is in the pipeline.

is now online --Geos one 14:16, 22 October 2010 (UTC)

thanks a million!

allow users to see & edit their own subpages

Is there any specific reason why this is disabled now? A colleague came to me in panic when she could no longer access her subpages. The fix is rather simple. in Title.php, the second half of the if condition should not be a check whether $this->getText() equals $wgUser->getName(), but whether it begins with $wgUser->getName()!

strpos($this->getText(),$wgUser->getName()) !== 0

in both cases (whether wgUserReadRestrict is true or false. No idea why this isn't the default behaviour!

what version of mediawiki ? --Geos one 03:00, 16 December 2010 (UTC)