mv restriction-version.mediawiki-version.patch ./mediawiki-version cd ./mediawiki-version patch -p0 < restriction-version.mediawiki-version.patch

/**
  * If true, a new menu action allows to restrict pages access to 'restrict' group users.
  * If false, all previously restricted pages are accessible again.
  */
  $wgEnableRestrict = true;

  /**
  * If true, new pages are restricted by default for 'restrict' group users.
  */
  $wgRestrictNewPages = false;

  /**
  * If true restrict user pages to their owner (as well as viewrestrict/restrict members)
  */
  $wgUserPageRestrict = false;

  /**
  * when wgUserPageRestrict and this option are true, allows user pages to be read but not edited by others?
  * added to restrict version beta-0.8.2
  */
  $wgUserReadRestrict = false;

  /**
  * Regular expression array to restrict matching pages
  * eg. $wgRegexRestrict = array("^Secure:", "^Secret ");
  *     restrict all pages where title is like 'Secure:...' or 'Secret ...'
  * with restrict version beta-0.8.1 you can also use Inverse regex matching
  * eg. $wgRegexRestrict = array("!!Public.*", ".*");
  *     any pages starting with "Public" is un-restricted and all others are restricted.
  */
  $wgRegexRestrict = array();

  /**
   * If true do not add recent changes entry for restricted pages
   */
  $wgNoRecentChangesRestrict = true;

  /**
   * If true hide log entries related to restriction, except for 'restrict' or 'viewrestrict' users (Special:Log page)
   */
  $wgHideRestrictLog = true;

  /**
   * MediaWiki permissions setup
   */
  $wgGroupPermissions['restrict']['restrict'] = true;
  $wgGroupPermissions['restrict']['viewrestrict'] = true;
  $wgGroupPermissions['viewrestrict']['viewrestrict'] = true;
  // with restrict version beta-0.8.2 when $wgUserPageRestrict and $wgUserReadRestrict is true
  // 'authors' group members get 'edituser' rights and can edit other users pages and sub pages.

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

237 réponses à “Restrict pages under MediaWiki”

1. Jerome Combaz dit :
   7 septembre 2005 à 16:09

   Please, add your comments below, or subscribe to the mailing list (see above)

   Jerome

2. Chunho Lee dit :
   11 septembre 2005 à 11:09

   Hello,

   I tried your patch for page access restriction. But when I pressed the "confirm" button on the "restrict" tab, it caused an error with the following message:

   Fatal error: Only variables can be passed by reference in [mediawiki]\includes\Article.php on line 1703

   I have mediawiki 1.5rc4, mysql 4.1, apache2 2.0.54 and php 5.0.5 running on a Windows XP SP2 system.

   What could be the source of the problem? PHP?

   Thanks.

   Chunho

3. Jerome Combaz dit :
   11 septembre 2005 à 22:09

   DEPRECATED, thanks for your help.

   Hello Chunho Lee,

   The source of the problem is probably a too permissive configuration of my PHP installation

   Please could you try this new patch on a fresh install ? conseil-recherche-innovat… (for a full patched archive : conseil-recherche-innovat… )

   or just change in Article.php near 1703 :

   $getredit = $this->mTitle->getRestrictions(’edit’);
   $edit = "edit=".current($getredit);
   $getrmove = $this->mTitle->getRestrictions(’move’);
   $move = "move=".current($getrmove);

   Thanks,
   jej

4. Chunho Lee dit :
   11 septembre 2005 à 22:09

   Hello Jerome,

   Thank you so much for your prompt response. I tried your suggestion (by directly editing the Article.php) and it worked without any further problem. But now the color scheme of the "unrestrict" tab link does not look correct. The text color is white and when viewed against almost gray background, it is not legible. Do you have a solution to that problem?

   Thanks again.

   Chunho

5. Jerome Combaz dit :
   12 septembre 2005 à 10:09

   arwfff… probably a non-compliant browser ? Did you try to browse with firefox, and what is the visual result ?

   jej

6. Will dit :
   13 septembre 2005 à 02:09

   I’ve gotten this installed and (seemingly) configured correctly, but there’s one problem: anonymous users can still view restricted pages. All other restriction properties work fine; nobody can edit a restricted page (or delete one), it’s just that anybody can view them whether in the "viewrestricted" group or not. I don’t know how to manipulate group permissions for "anonymous," but the Special:Permissions extension shows the anonymous user is not in the "restrict" or "viewrestrict" groups.

   Any ideas?

   Using Mediawiki 1.5rc4.

   Thanks!

7. Jerome Combaz dit :
   13 septembre 2005 à 10:09

   Strange… It works perfectly for me for anonymous users. Did you set $wgEnableRestrict = true in LocalSettings.php ?

   jej

8. Will dit :
   13 septembre 2005 à 20:09

   Yes. In case it matters, I have made some minor changes to the default permissions. Here’s the entire relevant section:

   $wgGroupPermissions['*' ]['createaccount'] = true;
   $wgGroupPermissions['*' ]['read'] = true;
   $wgGroupPermissions['*' ]['edit'] = false;
   $wgGroupPermissions['*' ]['talk'] = true;

   $wgGroupPermissions['user' ]['move'] = false;
   $wgGroupPermissions['user' ]['edit'] = false;

   $wgGroupPermissions['sysop' ]['move'] = true;
   $wgGroupPermissions['sysop' ]['edit'] = true;

   $wgEnableRestrict = true;

   The patch applied cleanly, by the way, against the 1.5rc4 installation I’m running.

9. Will dit :
   14 septembre 2005 à 23:09

   Actually, some additional notes.

   A page I marked as restricted does NOT appear in search results or special pages ("dead end pages," etc.). However, typing the page’s title directly *does* produce the page’s content as normal for anonymous users even when it’s restricted.

10. Jerome Combaz dit :
    15 septembre 2005 à 09:09

    Hi Will,

    Well, it’s difficult to answer you, as it works as expected on my installation.

    - Did you patch an already existing installation ?
    - Could you please test a fresh install from the full archive provided above ?
    - Could you send me your LocalSettings.php to the contact email ? (remove database passwd if needed)

    It’s normal that restricted pages are not shown to non allowed users in special pages. Allowed users should see it. But access should be forbidden for non ‘restrict’ or ‘viewrestrict’ users in every cases…

    jej

11. kyle dit :
    20 septembre 2005 à 21:09

    Do you have a specific changelog between patch 0.56 and 0.57…I don’t want to have to remake the site if I don’t have to…

    thanks

12. kyle dit :
    22 septembre 2005 à 08:09

    This extension is fantastic! However, I am now having a problem getting an rss feed for several pages. Any ideas??

13. Will dit :
    22 septembre 2005 à 11:09

    Sure, I’ll give it a stab in the next couple of days just to make sure it’s not something funky on this end. I’ll also dig through the code some more to try to get my mind wrapped around how MediaWiki decides whether to show a page or not (I need to understand that process anyway) and see if I can’t track this one down myself.

    Thanks for the suggestions

14. huwi dit :
    22 septembre 2005 à 14:09

    Hello Jerome

    Thanks for that great script! Any hint: in monobook/main.css the li#ca-unrestrict a { color: white; } should be a different color to see the text on tab (see message 4 from Chunho Lee). In german language file the ‘umlaute’ are displayed as ä ü etc., I replaced them by ä, ü etc., then it works correct in german version…;-)

15. Jerome Combaz dit :
    22 septembre 2005 à 21:09

    Hola,

    Thanks everybody for your comments. I am away for some days, so I will look closely next week. To be quick :

    - kyle : you don’t have to re-install if $wgUserPageRestrict = true. Anyway see the changelog above For the rss, not sure the patch is involved… I will have a look.
    - huwi : it’s ok under mozilla/opera/linux. Please, what is your configuration ?

    I have killed some bugs, new patch available next week. Thanks for you help.

    Jej

16. huwi dit :
    27 septembre 2005 à 07:09

    Hi Jerome

    Yep, all browsers. I assume it’s a translation mistake in wiki in german version (UTF8)?!? But doesn’t matter: (re-)renamed in umlaute it works fine. Have you email address? I can send you the correct file …DE.php
    Our config: MediaWiki 1.5rc4 / PHP 5.0.4 (appache2handler) / MySQL 4.1.1 / all on a linux server. Standard-browsers: IE6 and firefox. (additional in wiki: FCKEditor, Geshi codehighlighting, and other small extensions. That’s why I couldn’t use your script ;-(. PS: rss works fine.
    thanks. huwi

17. Jerome Combaz dit :
    27 septembre 2005 à 09:09

    Hi Huwi,

    Thanks for the …DE.php. You can send it to restrict-mediawiki /at/ conseil-recherche-innovation.net

    Is it ok now for the link color ?

    Jej

18. kyle dit :
    28 septembre 2005 à 23:09

    Hi J,

    I’m having problems displaying a modified quickbar with your extension…I have used the meta.wikimedia.org/wiki/M… extension to alter the site menu, but the php table is somehow being modified by your patch such that the menu is not read correctly. Any suggestions?
    -Kyle

19. Jerome Combaz dit :
    29 septembre 2005 à 10:09

    Hi K,

    I don’t think the patch modify anything in the navigation bar code, for version 1.4.x. In branch 1.5 you have to edit the page [[MediaWiki:Sidebar]] so no code is modified by an extension nor the patch. This is only what I understand from the doc

    Please, give feedback here for other users if you solve this problem.

    Jej

20. Matt dit :
    30 septembre 2005 à 18:09

    Great patch. Is it possible to have all new pages restricted by default when created?

21. Henning dit :
    5 octobre 2005 à 15:10

    Hi,
    i have a problem:
    i`ve got it correctly installed and the parameters in the
    LocalSettings.php configured, but there is no new tab link or
    the new groups are available in the user rights mangement.
    i dont know what i have done wrong.

    ps.: i am using MediaWiki 1.5rc4 and the patch beta 0.57

    could u help me

22. Kyle dit :
    6 octobre 2005 à 09:10

    Not sure why the Modified navigation menu was not working, but the site is running well now. Thanks, Jej

    Kyle

23. Jerome Combaz dit :
    10 octobre 2005 à 14:10

    Hi Henning,

    It seems that nothing works, so maybe you do not browse the correct installation ? Do you have any .rej file after patching ?

    Jej

24. Marcel dit :
    11 octobre 2005 à 22:10

    hi there

    i just uploaded your restriced stuff, but what I realy miss are the concept of groups to allowing or restricting access to certain pages and not only one group restrict. is there an easy hint to define a group and give them only the read and/or write access?

    thanks.
    marcel

25. Henning dit :
    12 octobre 2005 à 08:10

    Hi Jerome,

    no i haven`t any *.rej files… do i have to have some of these? if i have *.rej files… then the installation is correct or why do u ask ?

    thx for answer

    greetings henning

26. Jerome Combaz dit :
    12 octobre 2005 à 10:10

    Hi Marcel,

    "Go to the User rights management page (in special pages) and add users in group restrict (allow to view and restrict pages) or viewrestrict (allow only to view restricted pages)."

    Then a logged user of the ‘restrict’ group should see a new tab called ‘restrict’ (near ‘protect’).

    jej

27. Jerome Combaz dit :
    12 octobre 2005 à 10:10

    Hi Henning,

    No, *.rej means the patch is not applied. Send your LocalSettings.php to the mail contact, maybe I can investigate a little bit more (remove database params).

    jej

28. Henning dit :
    12 octobre 2005 à 11:10

    ok, i`ve sent you the localsettings.php is there a way to install the patch in windows?

    thanks

29. Marcel dit :
    12 octobre 2005 à 11:10

    hey jej

    sorry I explained my "wish" may not clear enough (bad English)… so another try:
    what I looking for is a function like ACL with this I would be able to say Group "A" has access to Page X and Group "A" and "B" has Access to Page Y. Also with the possibility for Accessrights like read, write, change and/or delete. You know? In my eyes this would need to make all the programming more "dynamics" so that’s not limited to one Group “restrict”, so that I can define groups, add users to those and add them with accessrights to the pages.

    Cya
    Marcel

30. Jerome Combaz dit :
    12 octobre 2005 à 12:10

    Henning: see this note : conseil-recherche-innovat…

    Marcel: I agree that mediawiki security model is not very powerful (as it does’nt need it for wikipédia). The patch can’t help it. Maybe DokuWiki is for you : wiki.splitbrain.org/wiki:…

    jej

31. Anthony dit :
    13 octobre 2005 à 00:10

    Hello,

    There seems to be a problem with with newest release of this patch. I used the windows full download of version 0.58 and in the recent changes it only shows changes to the log not changes to unrestricted pages. I would expect the recent changes to hide the changes to restricted pages but not to unrestricted ones.

    Any help you can provide on this matter would be appreciated.

    Anthony

32. Kyle dit :
    14 octobre 2005 à 05:10

    Holy smokes!
    You guys are asking for quite a bit…
    Anthony, as long as the page is not viewable, why should it matter that it’s in the log? (as in the recommendations, don’t name your pages intuitively!)

    Kyle

33. Jerome Combaz dit :
    14 octobre 2005 à 14:10

    To ensure everybody is happy I introduced a new option for the next version (v0.59)

    $wgNoRecentChangesRestrict = true to hide restricted pages changes.

    jej

34. David dit :
    14 octobre 2005 à 22:10

    I am having a hard time installing this–it tells me the directory does not exist when I attempt the second step?

    I am using the version of 1.5.0 released on the 5th of October. I have not modified it in anyway, and it is functioning currently. I added your settings to my localsettings file, but, can not complete the second step of the install so don’t know…

    Thank you for any help, I really appreciate your dedication to this free application you have created

35. Hexi dit :
    16 octobre 2005 à 22:10

    The RSS feeds seem to show the diffs for restricted pages. At least in version 1.5. Is there away around this?

36. Anthony dit :
    19 octobre 2005 à 12:10

    Kyle,

    You missed my point. But I figured out what the problem was. It will not show any changes made to any pages if you are logged into the master account. Any other account will show the recent changes of non-restricted pages and will not show the recent changes of Restricted pages. So for the regular users it works just like it is supposed to, just not for the master account user.

    Anthony

37. David dit :
    20 octobre 2005 à 19:10

    I’m sorry, I think I misunderstand this. I figured out how to install & it is setup. But, isn’t this supposed to allow…chosen users, to modify/see chosen pages? I don’t mean to ask for too much or to give a hard time–am just honestly confused

    it seems right now–like I can restrict a page for ALL who are not on viewrestrict. But what I was hoping was, that I could restrict it to only be accessible by one GROUP or INDIVIDUAL.

    Can anyone help? Thanks

38. na dit :
    27 octobre 2005 à 21:10

    Does this work with 1.5.1? I tried to patch using restriction-beta-0.58.mediawiki-1.5.0.patch, but it didn’t work quite right. I could see the restrict tab, and restrict the pages, and add the restrict and viewrestrict groups to users.

    But anonymous users could still view the restricted pages.

39. Jerome Combaz dit :
    28 octobre 2005 à 10:10

    I hope to have a bit of time this week-end to update the patch for 1.5.1. Sorry for the delay, that’s a really part time job

    David : "restrict it to only be accessible by one GROUP or INDIVIDUAL". That’s the same ! Register the "individual" you mean in the group viewrestrict or restrict. Like an individual can be sysop or not, and some actions are allowed to sysop group or not (and not directly to individual). I use the MediaWiki permission model, not more.

    Jej

40. Zotty dit :
    31 octobre 2005 à 11:10

    Can’t wait to give it a try as this might just be what I was looking for. Was hoping you got around to finish the update this weekend.

    In short, hurry up with that 1.5.1 patch will you

41. Chaitanya dit :
    9 novembre 2005 à 08:11

    Hi I am able to achieve group wise restriction by placing the following code in function view() of Article.php after $wgOut->setRobotpolicy( ‘index,follow’ ); line

    #——–start copy here ———-#

    $dbr =& $this->getDB();

    $sql="SELECT ug_group from user_groups where ug_user=" . $this->getUser();
    $res = $dbr->query($sql, $fname);
    $line = $dbr->fetchObject( $res );
    $dbr->freeResult($res);

    $contribgrp = $line->ug_group;
    $curgrps = $wgUser->getGroups();

    if ( !(in_array( $contribgrp, $curgrps ) ) ) {

    $relative_url = "index.php";

    header("Location: ".$_SERVER[’HTTP_HOS… ‘/\\’) . "/".$relative_url);

    return;
    }
    #——-stop copy here ———#

42. Lenny dit :
    10 novembre 2005 à 15:11

    I’m trying the patch. is there any problem to revert to the official release?
    where the restricted status is saved?
    bye.
    PS: great work

43. Jerome Combaz dit :
    10 novembre 2005 à 16:11

    The status of a page is saved in the ‘page’ table, field ‘page_restriction’. I just add ":view=1" for restrict, like MW use move=1 or edit=1 for page protection. So it should not avoid to use the offical release on a modified database.

    Any feedback welcome.

    Jej

44. Bzz dit :
    22 novembre 2005 à 13:11

    I have a problem, and would appreciate a helpinghand.
    The patch runs without any errors. But as soon as I add myself to the group ‘restrict’ i get:

    Fatal error: Call to undefined function: isrestricted() in /usr/local/WWW/www.derechtswinkel.nl/htdocs/intern/wiki/includes/SkinTemplate.php on line 619

    Likewise, if I add myself to the groep ‘viewrestrict’ i get:

    Fatal error: Call to undefined function: isrestricted() in /usr/local/WWW/www.derechtswinkel.nl/htdocs/intern/wiki/includes/SkinTemplate.php on line 643

    Is there something I overlooked?

45. Bzz dit :
    22 novembre 2005 à 13:11

    To be more precise; I used the patch on a fresh 1.5.2 install, and also tried the pre-patched archive. Both have the same error as a result.

    Many thanks in advance !

46. Jerome Combaz dit :
    22 novembre 2005 à 13:11

    Really strange… It seems that /include/Title.php is not patched… I tried the pre-patched archive and it works well here. Could you check that line 885 in this file defines the isRestricted() function ?

    Jej

47. Bzz dit :
    22 novembre 2005 à 13:11

    Yep, 885 states:

    function isRestricted() {
    global $wgEnableRestrict;

    if ( $wgEnableRestrict == true ) {
    $a = $this->getRestrictions("view");
    if ( $this->isRegexRestricted() || (!empty($a) && $a[0] == true) ) return true;
    }

    So that looks allright to me..

48. Jerome Combaz dit :
    22 novembre 2005 à 14:11

    Yep, to me too ! isProtected() is defined just above in the same file, is used in SkinTemplate.php and produces no error…

    Did you use an old database or a fresh one ?

    Jej

49. Bzz dit :
    22 novembre 2005 à 14:11

    When I updated my Wiki to 1.5.2. I used the supplied tools to update my database as well. I haven’t had any problems since.

    Was there a database-change needed for this extension to work?
    Haven’t noticed any in the readme’s…

50. Jerome Combaz dit :
    22 novembre 2005 à 14:11

    No database modification.

    Maybe it’s a problem with the MW cache. To be sure, try to install a new wiki & database with the 1.5.2 installer, in a different path. If it works well, then switch to your old database params.

    Jej

51. Bzz dit :
    22 novembre 2005 à 15:11

    Okay… new install works beautifully…
    BUT as soon as I switch to my old db it goes wrong again.

    I’m open to suggestions…
    BTW thanks for your quick response so far.. usually takes weeks for a developer to respond

52. Jerome Combaz dit :
    22 novembre 2005 à 16:11

    Try to empty the objectcache and querycache tables. Please give feedback if you find the answer

    Jej

53. Bzz dit :
    22 novembre 2005 à 20:11

    Nope, that didn’t work either… I’ll try to compare the two databases to see if there’s a difference that might be the cause.

54. Bzz dit :
    22 novembre 2005 à 21:11

    Okay… there’s a lot of differences between the two, but nothing out of the ordinary… mostly extra tables which is to be exspected when comparing a empty wiki-db to a full wiki-db.

    But now for the funny part; I changed the db params from the old db back to the freshly installed db, which now gives the same error.

    I’m out of ideas here… I’ll wrap it up for 2-day and will try again tomorrow (really looking forward to the possibilities of your extension)…

55. Bzz dit :
    23 novembre 2005 à 10:11

    I’m not too well at home in php, but in the definition of the isRestricted() function, there’s "getRestrictions("view")", but I can’t find that function defined anywhere in MediaWiki.

    Am I Chasing a wild goose here?

56. Jerome Combaz dit :
    23 novembre 2005 à 12:11

    Bzz,

    getRestrictions() is defined in Title.php (it’s a genuine MW function). It’s still very strange that from two functions defined in the same file, one is well recognized and one produces an error… I cannot understand that !

    I updated just now an old wiki from 1.4 to 1.5 with upgrade1_5.php and update.php scripts and no problem was encountered. The patch works, user managment as well… So it’s really difficult to help you more if it is an isolated problem. Try maybe to export/import articles instead of playing with DB convertion.

    What I know is that during my tests, the cache often redirect me to an old url pointing to an old installation instead of using the current wiki path, and sometime I was confused as I did not noticed it and my modificaitions did not work. Maybe you encounter the same case, chect that.

    Else… good luck

    Jej

57. Bzz dit :
    23 novembre 2005 à 15:11

    It’s probably a fluke in my db. It’s got 3 (!)wiki installs at the moment. All with different prefixes, but as you pointed out, the caching might be the thing thats bugging.

    I’ll just set up a new install (again) and import articles. Luckily there aren’t that many articles yet.
    Thnx for your help.

58. kent1 dit :
    25 novembre 2005 à 18:11

    Do you believe it will be possible to create different groups and to restrict different pages to these different groups?
    In my case, I work with 5 projects but it’s not interesting for me to open 5 different Wikis.
    I just want to have 5 groups, 1 for each project.
    Excuse me for my poor English (I’m french), I only want that all people understand it…
    Thanks for this great patch too…

59. Jerome Combaz dit :
    1 décembre 2005 à 10:12

    Hi kent1,

    For now not possible. As it is a recurrent request I will have a look. The problem is to implement that feature without too much hack of mediawiki (eg. no database scheme modification).

    Then, keep in touch with the blog, and maybe one day you will have it

    Jej

60. NullEnRegexp dit :
    8 décembre 2005 à 16:12

    Bonjour,
    can you give a small regexp example for the array $wgRegexRestrict ?
    for example, how can I restrict all pages begining with ‘myBrain:’
    Thus [[myBrain:myIdea]] would be restricted.
    Thanks

61. Jerome Combaz dit :
    8 décembre 2005 à 16:12

    It should be :

    $wgRegexRestrict = array( ‘^myBrain:’ );

    Is it ?

    Jej

62. Jerome Combaz dit :
    8 décembre 2005 à 16:12

    Ooops, becareful the Uppercase (Mediawiki uppercase the first letter in the title) :

    $wgRegexRestrict = array( ‘^MyBrain:’ );

    Jej

    ps: it works, tested.

63. HappyRegexper dit :
    8 décembre 2005 à 22:12

    Thanks for the example, for the feature, and for this great extension !
    Merci!

64. xshot dit :
    10 décembre 2005 à 15:12

    Hello,

    I tried your patch for page access restriction.I got this message on every page

    Warning: Invalid argument supplied for foreach() in /www/htdocs/v147709/wiki/includes/Title.php on line 900

    In the User rights management page I can’t find a group named "special"

    ???

65. xshot dit :
    10 décembre 2005 à 17:12

    /include/defaultSettings.php was not patched .. i did it per hand … works fine now

66. Karen dit :
    12 décembre 2005 à 13:12

    is it no longer possible to hide the restriction log (in the patch for version 1.5.2)?

    // Hide restriction log entries for non-members users
    $wgHideRestrictLog = true;

    I’ve added this to LocalSettings.php but it makes no difference. People who are not in the viewrestrict group can still see the restriction log.

67. tof dit :
    15 décembre 2005 à 10:12

    Hey man, great extension. I’m just wondering, for windows users, you provide the whole mediawiki installation, patched. But in my case, I already have everything installed, and configured, so I can’t just overwrite my files. Any chance you could provide a package with only the files that are concerned by your extension ?

    Cheers!

68. Jerome Combaz dit :
    15 décembre 2005 à 12:12

    Karen,

    ok, the option is back in version 0.6 (for 1.5.3). It was removed with the 1.5.x branch.

    Jej

69. Jerome Combaz dit :
    15 décembre 2005 à 12:12

    tof,

    Here is the list of patched/new files, as you can see in the patch file:

    ./includes/Article.php
    ./includes/DefaultSettings.php
    ./includes/Defines.php
    ./includes/LogPage.php
    ./includes/OutputPage.php
    ./includes/Parser.php
    ./includes/QueryPage.php
    ./includes/SearchMySQL.php
    ./includes/Skin.php
    ./includes/SkinTemplate.php
    ./includes/SpecialAllpages.php
    ./includes/SpecialAncientpages.php
    ./includes/SpecialBrokenRedirects.php
    ./includes/SpecialCategories.php
    ./includes/SpecialContributions.php
    ./includes/SpecialDeadendpages.php
    ./includes/SpecialDisambiguations.php
    ./includes/SpecialDoubleRedirects.php
    ./includes/SpecialExport.php
    ./includes/SpecialLog.php
    ./includes/SpecialLonelypages.php
    ./includes/SpecialMostlinked.php
    ./includes/SpecialMovepage.php
    ./includes/SpecialNewpages.php
    ./includes/SpecialPage.php
    ./includes/SpecialPopularpages.php
    ./includes/SpecialRandompage.php
    ./includes/SpecialRecentchangeslinked.php
    ./includes/SpecialRestrictedpages.php
    ./includes/SpecialShortpages.php
    ./includes/SpecialUncategorizedpages.php
    ./includes/SpecialWhatlinkshere.php
    ./includes/Title.php
    ./index.php
    ./languages/LanguageDe.php
    ./languages/LanguageFr.php
    ./languages/Language.php
    ./README.restriction-patch
    ./skins/monobook/main.css

    If you ask me now what are the modifications in these file, please have a look in the patch file

    Jej

70. dechartorn dit :
    20 décembre 2005 à 03:12

    hi , i need to know — how to install patch on window

71. Jerome Combaz dit :
    20 décembre 2005 à 09:12

    You can find a port of the patch command for windows here : unxutils.sourceforge.net. Read also : this comment

    No windows here so not tested

    Jej

72. Martin dit :
    24 décembre 2005 à 11:12

    Hi!

    I’m trying to restrict all Special:* pages using the following line within the LocalSettings.php:

    $wgRegexRestrict = array("^Special:", "^Special ");

    However, this does not work. It works with e.g. Test:* pages.

    In fact, I like to restrict the user (or to be more precise a software agent) to grep all pages from the wiki.

    Is there a possibility to restrict access to the Special pages?

    Best regards

    Martin

73. Jerome Combaz dit :
    26 décembre 2005 à 11:12

    Mediawiki manages special pages access in a different way, so the restriction does not apply as normal pages.

    I think native features could do the job. Look at this page : meta.wikimedia.org/wiki/P… (To prevent a special page from being listed at [[Special:Specialpages]], edit SpecialPage.php and change the relevant entry…)

    Jej

74. Dan East dit :
    27 décembre 2005 à 14:12

    Regarding message 71 "You can find a port of the patch command for windows here : unxutils.sourceforge.net":

    This does work, but first you must re-save the patch file to add in CR/LF pairs, which the win32 version of patch requires.

    Open the .patch with WordPad then save to add in the windows style new lines.

    Dan East

75. Jerome Combaz dit :
    28 décembre 2005 à 15:12

    Thanks for this info.

    Jej

76. edward dit :
    2 janvier 2006 à 23:01

    Hello,

    Some questions about the patch you made.

    1) I am working on vs. 1.5.4 of wikimedia. Does your patch also work for this release?

    2) Do pictures on a page have the same protection as text?

    3) What I want to do is make a site for diving-enthousisast. Every visitor has its own pages which he/she can edit, and the possiblity to upload his underwater-photo’s and dive-statistics (depth, duration, etc). This must not be able to be changed by others (changed by owner only) but must be able to be viewed by everyone.

    However, the user may also make pages on ‘dive locations’ and ‘animal species description’ which must be able to be edited by anyone (in the true wiki spirit).

    With your patch is it possible to divide the wiki easlily in a ‘personal part’ and a ‘public part’?

    Looking forward to your reaction,
    Edward Hage

77. renewe dit :
    4 janvier 2006 à 10:01

    Hi

    Can someone help me?
    How can i put New-Users by default to the group "viewrestrict"?

    Thx

78. Jerome Combaz dit :
    4 janvier 2006 à 10:01

    meta.wikimedia.org/wiki/M…

    Jej

79. Bill Jones dit :
    9 janvier 2006 à 21:01

    OK, I have read the long discussion about access control lists and all the related materials on MW FAQ site — however I want to know if someone can provide step-by-step instructions to implement this patch BUT substitute student for restrict and studentview for viewrestrict?

    IE, I want to expand the category groups. I tried setting up a student group but how can I restrict access to individual classes? IE, UserID studentA is allowed to view and/or edit class IT306 Software Application Programming?

    I am sorry if this seems like a duplicate question but after all the reading and testing and troubling shooting I am totally confused.

    Any help or insight would be most welcome and appreciated right about now.

    Thx/Bill

80. Denis dit :
    13 janvier 2006 à 00:01

    Great Patch,

    I’m having some difficulties with the wgNoRecentChangesRestrict option.

    I’ve noted that it indeed does restrict changes from being listed in the recent changes page, however it doesn’t remove the logs of the fact that the pages have been restricted.

    I would like to remove all record of restricted pages from the log so that people can’t view the titles of the pages

81. Jerome Combaz dit :
    13 janvier 2006 à 09:01

    It’s quite easy to implement through a new option. I add it to my TODO list.

    But if you’ve time to do it you can submit a patch on the patch

    Jej

82. David Van Ronk dit :
    17 janvier 2006 à 19:01

    Could you please post a update for 1.5.5, I can’t get patch to work on my windows machine.

    Thank You

83. Jerome Combaz dit :
    18 janvier 2006 à 10:01

    The current patch (0.6) works greatly on 1.5.5. Check your windows

    Jej

84. Jerome Combaz dit :
    18 janvier 2006 à 12:01

    Denis (comments 80 and 81) : I’am totally stupid, the option already exists and was reintroduced in last version… just add $wgHideRestrictLog = true; in your config.

    Becareful with sensible information in page titles. It’s still unadvised.

    Jej

85. Peter dit :
    20 janvier 2006 à 05:01

    Jerome,

    We are using your RESTRICT extension on
    MediaWiki: 1.5.0
    PHP: 4.3.11 (apache2handler)
    MySQL: 3.23.58

    and it is working well. I was surprised that RESTRICTED pages are still shown in the list of all pages when this is displayed by a person who is not in the RESTRICT or VIEW RESTRICT group (the contents of the page is not visible to the person.

    Is there a setting that hides the titles of RESTRICTED pages? Or is there a way to see a list of all pages that are NOT restricted so people can navigate around these pages.

    Thanks for your excellent work.

    Peter

86. Jerome Combaz dit :
    20 janvier 2006 à 10:01

    Peter: That’s the way it works ! The Special:Allpages page hides restricted titles for normal users and shows it for ‘restrict’ and ‘viewrestrict’ groups. Check that ./includes/SpecialAllpages.php is well patched.

    Jej

87. Alex dit :
    23 janvier 2006 à 22:01

    I installed the restriction extension, everything works fine. Great work, thank you for your efforts.

    One question: I would like to restrict basically all of the pages in my wiki. Do I have to restrict my pages now page by page or is there a shortcut?

88. Jerome Combaz dit :
    24 janvier 2006 à 10:01

    Alex: thanks for your comment.

    It’s not possible to restrict all existing pages except for new pages ($wgRestrictNewPages option). Generally with this patch we need only some pages restricted. It you need all pages restricted maybe you have to rely on apache authentification or mediawiki features.

    Jej

89. Voltaire dit :
    30 janvier 2006 à 20:01

    Most of the comments out there pertain to problems with this customization. I got it to work but by taking the list of files that Jerome listed and just overwriting them in the file server.

    Thanks again.

    Merci Jerome! Ca marche tres bien!
    Voltaire

90. Jerome Combaz dit :
    31 janvier 2006 à 09:01

    Thank you

    jej

91. Chris dit :
    31 janvier 2006 à 15:01

    Jerome,

    Thank you very much for the patch! It works exactly the way I needed it to.

92. Jerome Combaz dit :
    31 janvier 2006 à 15:01

    Thank you too !

    A nice day today

    Jej

93. Bernd dit :
    1 février 2006 à 12:02

    Hello,
    after I have restricted an article I would expect a view=1 in the page table. The user are still allowed to view the acticle, but not allowed to edit them.
    A would like that they not able to view the article.
    Bernd

94. ahru dit :
    11 février 2006 à 07:02

    I encountered the following error upon installing the patch from the pre-patched archive:
    Deny from all
    Fatal error: Class languageutf8: Cannot inherit from undefined class language in /home/content/l/e/h/lehommenet/html/zenru/wiki/languages/LanguageUtf8.php on line 38

95. Jerome Combaz dit :
    13 février 2006 à 11:02

    Sorry, small mistake in LanguageSv.php. Add a comma at the end of the line 892. Patch updated.

    Jej

96. Jonathan dit :
    21 février 2006 à 10:02

    Hi,

    i installed the patch with mediawiki 1.5.0. Now i’m using 1.5.6 without any patches. How do i remove the rest of the patch (there is still the ‘button’ restrict page, and the recent changes-pages doesn’t work anymore….)

    Jonathan

97. Jerome Combaz dit :
    21 février 2006 à 10:02

    Just install 1.5.6 in a new directory…

    Or replace all files modified (see comment 69) by the patch with the files from 1.5.6 version.

    Jej

98. Luke Stebbing dit :
    25 février 2006 à 07:02

    Hi,
    I installed the patch and almost everything is working great, but pages that were restricted with a regular expression don’t seem to be treated quite the same as pages that were directly marked as restricted (with action=restrict). For example:
    $wgRegexRestrict = array("^A:");

    pages:
    B <- "testphrase"
    Restricted:B <- "testphrase"
    A:B <- "testphrase"

    Say B was set to restricted with the "restrict" tab. Of course, the other two pages already show up as restricted pages.

    If I search for "testphrase" as a user who doesn’t have the "viewrestrict" right, the line in B will not show up, but the lines in Restricted:B and A:B will. I can’t click on those pages, but I can still figure out lots of the content by guessing different words.

    Looking in the database, B has "edit=:move=:view=1" in its page_restrictions field, but Restricted:B and A:B don’t. If I force that field to be added by putting …/A:B?action=restrict in the address bar, then the restriction works and I can no longer search for the phrase.

99. Morrissimo dit :
    28 février 2006 à 17:02

    What I’ve seen so far of this addon I love — but I can’t quite make it do what I was trying to do. Hopefully you guys can set me straight.

    1) I’d like to restrict User pages to be editable only by their User — I’ve figured out how to do this.
    2) I’d like User pages to be *viewable* by anyone. — I can’t figure out how to do this.

    Can anyone help me figure out how to set up this addon to do both 1) and 2) at the same time? Thanks in advance…

100. Joel dit :
     1 mars 2006 à 12:03

     Hello, thanks for your patch.

     I’m having trouble with recent changes. I have set $wgNoRecentChangesRestrict = true; but creation of pages restricted by $wgRegexRestrict still shows up in the recent changes log. Is this as inteded or is my setup faulty?

     regards
     Joel

101. Joel dit :
     1 mars 2006 à 12:03

     Hi and thanks for your patch.

     I’m having trouble with the recent changes page. Pages restricted through the $wgRegexRestrict still shows up in the recent changes even though both the log setting and the recent changes setting ($wgHideRestrictLog, $wgNoRecentChangesRestrict) are true.

     Is this as intended or is my setup faulty?

102. Kevin dit :
     5 mars 2006 à 08:03

     Hello there, great to find a patch for exactly what I need… However, I have downloaded the new 1.5.7 of MW and the patch fails in many places when I try to apply. Could you please have a look and see what needs some updating?… it would be amazingly helpful! Some of the work I’m doing actually does use the IE7 beta browsers and the latest fixes for that browser in the MW 1.5.7 could be quite useful. I am a windows user (so using the ported patch.exe) and yes have changed the patch file through WordPad to fix that CR/LF issue.

     The failed outputs are listed below. Thankyou in advance.

     patching file `./includes/SpecialExport.php’
     Reversed (or previously applied) patch detected! Assume -R? [n]
     Apply anyway? [n]
     Skipping patch.
     3 out of 3 hunks ignored — saving rejects to ./includes/SpecialExport.php.rej

     patching file `./languages/LanguageFr.php’
     Reversed (or previously applied) patch detected! Assume -R? [n]
     Apply anyway? [n]
     Skipping patch.
     2 out of 2 hunks ignored — saving rejects to ./languages/LanguageFr.php.rej

     patching file `./languages/Language.php’
     Hunk #1 FAILED at 2128.
     1 out of 1 hunk FAILED — saving rejects to ./languages/Language.php.rej

103. Jerome Combaz dit :
     5 mars 2006 à 13:03

     Luke Stebbing: you’re true, the regex restriction is just a small hack to add this feature. I (or you can inspect more closely the patch code to see whether it’s possible to propagate the same behavior to regex restrictions.

     Thansk for your expertise

     Jej

104. Jerome Combaz dit :
     5 mars 2006 à 20:03

     Joel: same as comment above. It needs some work to make regex restriction working exactly like manual restriction.

     Jej

105. Jerome Combaz dit :
     5 mars 2006 à 20:03

     Kevin: keep in touch. I will have a look on 1.5.7. By the way, thanks to announce me this new version

     Jej

106. Kevin dit :
     6 mars 2006 à 16:03

     Thanks for updating the package, everything appears to be working great. Fantastic work :-0

107. T O X I N dit :
     8 mars 2006 à 13:03

     Rusian Translation 08.03.2006

     #Restrict patch (meta.wikimedia.org/wiki/P…
     ‘restrict’ => ‘Ограничить’,
     ‘restrictthispage’ => ‘Ограничить статью’,
     ‘unrestrict’ => ‘Не ограничивать’,
     ‘unrestrictthispage’ => ‘Не ограничивать статью’,
     ‘restricttitle’ => ‘Доступ к статье ограничен’,
     ‘restricttext’ => ‘Данная страница ограничена для публичного просмотра. Для просмотра вы должны быть проверенны.’,
     ‘restrictedpages’ => ‘Ограниченные статьи’,
     ‘restrictlogpage’ => ‘Журнал ограничений’,
     ‘restrictlogtext’ => ‘Ниже список страниц с ограничениями. См. [[{{ns:4}}:Ограниченные статьи]] для большей информации.’,
     ‘restrictedarticle’ => ‘Ограниченно [[$1]]’,
     ‘unrestrictedarticle’ => ‘Не ограниченно [[$1]]’,
     ‘restrictsub’ => ‘(Ограничить \’[[$1]]\’)',
     ‘confirmrestrict’ => ‘Подтвердить ограничение’,
     ‘confirmrestricttext’ => ‘Вы действительно желаете ограничить эту статью?’,
     ‘restrictcomment’ => ‘Причины для ограничения’,
     ‘unrestrictsub’ => ‘(Не ограничивать \’[[$1]]\’)',
     ‘confirmunrestricttext’ => ‘Вы действительно желаете снять ограничение?’,
     ‘confirmunrestrict’ => ‘Подтвердить снятие ограничений’,
     ‘unrestrictcomment’ => ‘Причины снятия ограничений’,
     ‘restrictreason’ => ‘(укажите причину)’,
     ‘tooltip-restrict’ => ‘Ограничить статью’,
     ‘notallowedtomoverestrictedpagetext’ => ‘Для перемещения этой страницы, Вы должны быть членом \’restrict\’ группы.’,
     ‘restrictedpagespagetext’ => ‘В этом списке страниц ограниченные для просмотра статьи. ‘,
     ‘regexrestrictedpagespagetext’ => ‘Все названия статей удовлетворяющих этому/этим семантическим выражениям будут так же ограниченны: ‘,

     );

108. Jerome Combaz dit :
     8 mars 2006 à 14:03

     Thank you TOXIN. I will include your translation in the next release.

     Jej

109. borgx dit :
     9 mars 2006 à 09:03

     How about releasing patch for 1.6Devel

     Borgx

110. Thib dit :
     9 mars 2006 à 11:03

     Thank you Jerome for what looks like a lot of work. (I had been posting to your talk page on meta.wikimedia.org but this is the place ot be) We’re in the process of evaluating MediaWiki, to see whether or not it suits our needs, and one of our needs is page restriction — just like this patch.

     The patching ran smoothly — it complained it could not find .cvsignore, but that’s not a major problem, and it also gave non-empty success messages because a few PHP files in our directories have one or two extra lines (so patch was able to detect the slight offset).

     Patching did not change any permissions on any file, so we did not need to fix the permissions after patching.

     As soon as we tried to go to the wiki, though, we could not go anywhere; we would get an HTTP 403 Forbidden for any page request. The Apache error log just showed a Denied line but no PHP error output was visible in the log. This has happened whether or not we add the restriction-specific parameters in LocalSettings.php or not, and whether we enabled restriction or not there.

     Do you know what the problem could be?

     We had a backup and as soon as we rolled out the backup everything went back to normal.

     We’re using MediaWiki 1.5.7 with the 1.5.7 patch from this page.

     D’avance merci,

     Thib

111. Jerome Combaz dit :
     9 mars 2006 à 11:03

     borgx: why not… but need still more and more time to do that ! That’s the problem

112. Jerome Combaz dit :
     9 mars 2006 à 11:03

     Thib: I think the patch itself is not involved in your problem. Maybe the patching process changed some permissions, check again. Please paste a sample of your apache log and a ‘ls -la’ output.

     Jej

113. Thib dit :
     10 mars 2006 à 09:03

     Hi Jerome, and thanks for helping.

     I saved the output of ls -la on the entire directory structure before applying the patch, and after applying the patch. I compared the outputs with diff, and I verified the following:

     * README.restriction-patch was added.
     * The only files that are listed differently between the "before" and the "after" are the files that were changed by the patch, because their size has changed.
     * None of the files have changed permissions.
     * None of the files have changed owners or groups.

     Here is a sample (I don’t want to page many screenfuls of text):
     153,156c156,159
     < -rw-r–r– 1 root root 11920 Mar 7 20:19 SpecialContributions.php
     < -rw-r–r– 1 root root 1120 Mar 7 20:19 SpecialDeadendpages.php
     < -rw-r–r– 1 root root 1998 Mar 7 20:19 SpecialDisambiguations.php
     < -rw-r–r– 1 root root 3154 Mar 7 20:19 SpecialDoubleRedirects.php
     —
     > -rw-r–r– 1 root root 12092 Mar 10 00:21 SpecialContributions.php
     > -rw-r–r– 1 root root 1285 Mar 10 00:21 SpecialDeadendpages.php
     > -rw-r–r– 1 root root 2165 Mar 10 00:21 SpecialDisambiguations.php
     > -rw-r–r– 1 root root 3323 Mar 10 00:21 SpecialDoubleRedirects.php

     If I access any page, for instance:
     example.com/index.php/Mai…

     I get:
     "Forbidden: You don’t have permission to access /index.php/Main_Page on this server."

     And the Apache log shows:
     [Fri Mar 10 00:32:11 2006] [error] [client 66.159.xxx.xxx] (13)Permission denied: access to /index.php/Main_Page denied

     If you insist on me posting a full output of ls -la, I will gladly do it (I didn’t today because it’s really long).

     Encore merci,

     Thib

114. Jerome Combaz dit :
     10 mars 2006 à 09:03

     Thib: I think your problem is related to the server side. Check permissions on the index.php file (and on the full directory tree…). I don’t think the patch could restrict access at the apache level… Check also any .htaccess file.

     Jej

115. Thib dit :
     13 mars 2006 à 20:03

     Jérôme:

     I applied the patch to an "out of the box" version of MediaWiki and it works just fine. I have also not been able to find anything permission-related or webserver-related that would cause this "Forbidden" jail. Therefore I guess the little changes we made to the PHP code and the little changes made by the patch are in fact messing up the PHP I don’t know PHP, so I was hoping I wouldn’t have to look inside the files… but I have to,

     Merci pour votre excellent travail sur ce patch, il nous sera bien utile.

     Regards,

     Thib

116. kinnaert dit :
     13 mars 2006 à 22:03

     Hello Jerome, how far are you from adding the ablity to have user level restricted pages? It seems like it wouldn’t be too hard to get the patch working so that we could select specfic users from a list that will be allowed to view a particular page.

     I was thinking about trying to extend your patch to do this if you you’re not going to do it.

117. Jerome Combaz dit :
     14 mars 2006 à 10:03

     Hi Kinnaert,

     This needs deeper modifications of mediawiki. I think these features could be part of the main branch of MW, instead of a patch difficult to maintain. We speak about to implement a true ACL and security model in the core of mediawiki, so this could be a concern of the mediawiki team, not only of a patch.

     As GPL permits it you can extend the patch ! And we can put your contribution and credit here if you want. Discussions are welcome here to continue on this topic.

     Jerome

118. Kinnaert dit :
     14 mars 2006 à 12:03

     Thanks for the quick reply,

     I think since mediawiki’s role is as they have stated to be the wiki appliation for wikipedia etc. and not all things to all people, perhaps like tiki is trying to be, that I can’t really see them spending the time to add ACL to their core code. If they would do it, I and a lot of other peoplw would be gratefully surprised, and it would be a gift to the community since they themseleves really don’t need this type of functionality.

     Having said that, perhaps we should ask them, if they have any plan at all to do anything with ACL’s? If not that perhaps a fork of wikimedia might be in order since it seems too many things are having to be changed in the core files? It’s getting to be more then a simple extention.

     I don’t like coding something, if there’s already an existing solution that fills the need correctly, it’s a true waste of human effort. Do we really need another wiki,cms, or forum system?

     Before we talk anymore about turning mediawiki into a robust ACL wiki, does anyone know of any wikis or structued wikis with page level user ACL? I did find one so far, don’t know how good it is yet I have to test it out.
     wackowiki.com/

     Know of any other’s with page level ACL’s?

119. Jerome Combaz dit :
     14 mars 2006 à 15:03

     We had a discussion about that on the mediawiki developers list : mail.wikipedia.org/piperm…

     In fact I don’t know what to think I use mediawiki for some advantages and mainly because some other engines lack of some features. For example some forbid to include <html>, or use only OldFashionWikiNames to link pages, some lack of category, etc, etc. At the end, we fall back on mediawiki !

     To make an ACL patch for mediawiki will be difficult to maintain as the core engine change everytime and it needs deep modifications. That’s why I think the core of MW should be modified to allow easily ACL integration even if wikipedia use it only to protect pages or some administrative operations. A good code design for a low level feature is still useful ! To make a fork is not a good idea, it would be better to make a new tool based on special needs not related to encyclopedic needs (not saying that it is a huge work……).

     So for now, I wait ! I think that if we need more restrictions it is stupid to use a tool made to be wide open like mediawiki is. Maybe you can have a look on wiki.splitbrain.org/wiki:… and its ACL features.

     Hope it helps,
     Jerome

120. kinnaert dit :
     14 mars 2006 à 16:03

     I think the "open" community takes things a little too far sometimes…

121. Jerome Combaz dit :
     14 mars 2006 à 17:03

     What do you mean ?!

122. Chan Sarinyamas dit :
     24 mars 2006 à 22:03

     Hi, I have a few questions if someone would be so kind to answer them, I’d really appreciate it!

     Can this patch be applied over an existing install of MediaWiki or do I have to back up the wiki and then install the patch and restore the wiki database?

     I downloaded the .patch file, but I’m not sure what to do with it. Is it some script that i can just run? or is there some exe that will know how to unpack/use the restrict patch file? thanks!
     -Chan

123. tof dit :
     31 mars 2006 à 08:03

     Jerome,

     I’ve applied the patch (on windows), now it all works alright except the display. instead of having restrict or unrestrict in the tab name, I have "&lt;restrict&gt;" and "&lt;unrestrict&gt;" .same thing for "&lt;Unrestrictrestrict&gt;" and "<confirmrestricttext>"

     Any idea ?

124. tof dit :
     3 avril 2006 à 02:04

     forget about it man. When running the patch, it failed to update language.php, that’s why. I added the new messages manually and it work fine now. cheers.

125. SHIBUYA K. dit :
     5 avril 2006 à 08:04

     I found a pretty bug on the patch for 1.5.7. In Article.php line 1763, ‘confirmrestricttext’ should be ‘confirmunrestricttext’.

     BTW, I translated the system messages for this patch into japanese. How can I send it to you?

126. T O X I N dit :
     6 avril 2006 à 08:04

     MediaWiki 1.6.0 released what plans or roadmap you have to patch new version 1.6.0?

     If You plane to continue? work please made "ready to use" distributive (already patched).

127. Jerome Combaz dit :
     6 avril 2006 à 09:04

     SHIBUYA: Thanks for this report, I will check that and insert your translation (see "Mailing list and contact" above to mail me or post as a comment here)

     Jerome

128. Indy Sams dit :
     10 avril 2006 à 02:04

     DEPRECATED, thanks for your help.

     I have ported the Restriction mod to MediaWiki 1.6.1 now, although I have not tested all the special pages and some functions yet, it appears to be working.

     Here are the files you need to install the mod: http://www.driftsolutions.com/wi...

     Just overwrite your existing MW 1.6.1 files with these, and edit your LocalSettings.php as per the instructions @ the top of this page.

     As a side benefit, you get the Permissions mod installed as well since I already had it applied before I started porting this.

     Let me know if anything doesn’t work and I’ll try to fix it ASAP.

129. Jerome Combaz dit :
     10 avril 2006 à 18:04

     Hi Indy,

     Thanks a lot for this work. I have done a diff and now I check if everything looks good. I didn’t know the Permissions mod you mention. I think that’s better to separate the two features and leave the choice to apply the one and/or the other.

     I will update this blog later and add a credit to you

     Jerome

130. T O X I N dit :
     11 avril 2006 à 08:04

     Please made already patched wiki 1.6.x distributive, i`m (and perhaps some other readers of this blog) did`t have enough programmer skill to made it self-dependent. Please HELP us!

131. Jerome Combaz dit :
     11 avril 2006 à 09:04

     toxin: see comment 129. Indy Sams made changes for version 1.6.1

     I did not verify the integrity of its contrib, so use it at your own risk. And don’t forget to thank him

     Jerome

132. void dit :
     13 avril 2006 à 01:04

     Please update the patch for the newest version 1.6.3. I just installed mediawiki 1.6.3. Thank you very much!

     Steven

133. Pinchao Si dit :
     14 avril 2006 à 09:04

     Restrict new pages to their author only (or to be able to restrict any page to a single user)

     Hava you finished?

134. Jan Pavlovic dit :
     14 avril 2006 à 12:04

     DEPRECATED, thanks for your help.

     I’ve made a patch from the version 1.6.1 and it is working (hope so) for 1.6.3 as well.

     http://www.fi.muni.cz/~xpavlov/m...

     Jan

135. Anthony dit :
     15 avril 2006 à 19:04

     The patch in comment 135 does not work on 1.6.3. It has errors in the SpecialUserRights.php and does not show the tab for restrict at the top of page.

136. Jerome Combaz dit :
     16 avril 2006 à 19:04

     Anthony: I have the same problem with this contrib… And no answer from the author.

     Jerome

137. Jan Pavlovic dit :
     18 avril 2006 à 00:04

     well it is not the problem of 135 patch it is the problem of original 129 patch which has the same error witch specialuserright.php

     contact Indy Sams

     –
     Jan

138. Jerome Combaz dit :
     18 avril 2006 à 09:04

     Jan Pavlovic: I was speaking about contrib #129. Sorry for the confusion.

     Jerome

139. Chris Evich dit :
     20 avril 2006 à 13:04

     Along with the people above, I’d also like to see a working 1.6.3 port of this patch!

     Also, how about having this merged upstream?

140. Jerome Combaz dit :
     20 avril 2006 à 14:04

     Sorry for the delay. Two contribs here (#129, #135) propose this patch for 1.6. You can use it for now at your own risk. They are incomplete and I have still a lot of work to do to make the full genuine patch working for 1.6.

     For the merge upstream I have to ask to the mw team. I don’t think that it’s a priority for them to add this feature.

     Jerome

141. Anthony dit :
     20 avril 2006 à 21:04

     DEPRECATED, thanks for your help.

     I have created a patch for the 1.6.3 version. I make no promises but it works on my server. You can get the patch at http://www.taac.us/restrict.patc...

     And for those that need the complete file you get it here http://www.taac.us/mediawiki-1.6...

     I no very little about php but I can do a little if you find a problem.

     Anthony

142. Jan Pavlovic dit :
     21 avril 2006 à 03:04

     Well Anthony it seems to be working. Good job!
     thanx

     Jan

143. Jerome Combaz dit :
     21 avril 2006 à 09:04

     Anthony: thank you. It seems to be a very good base for an official version of the patch. As soon as I have a bit of time I will check your patch and produce a new official release.

     For now I put a link in the note. Thanks a lot for this contrib.

     Jerome

144. Andy dit :
     21 avril 2006 à 20:04

     Would it be possible to post a patch for the linux version as well? Diff on linux doesn’t understand how to read the patch file for 1.6.3 (esp. the windows file locations, which I tried fixing using sed, but it still fails to patch even after finding the correct files).

145. Anthony dit :
     22 avril 2006 à 04:04

     Andy, I am not sure how to fix that little problem. I have only worked with linux for a little while and currently all my machines run Windows (I may get brave and put a version of linux on my laptop). Maybe someone can help you with a windows to linux conversion of the patch.

146. anagy dit :
     23 avril 2006 à 23:04

     DEPRECATED, thanks for your help.

     I have modified the file from Anthony, so it now works fine on Linux!!!

     restrict-patch:
     http://www.sendspace.com/file/y5...

147. Andy dit :
     24 avril 2006 à 19:04

     The patch that anagy posted doesn’t seem to work against 1.6.3, maybe I am doing something wrong? I just copy the patch file into the wiki directory, then do `patch -p0 < restrict.patch`. I get errors such as

     patching file ./includes/Article.php
     Hunk #1 FAILED at 842.
     Hunk #2 FAILED at 1172.
     Hunk #3 FAILED at 1203.
     Hunk #4 FAILED at 1367.
     etc….

     Any help with this is greatly appreciated!

148. Jerome Combaz dit :
     25 avril 2006 à 09:04

     I released a patch for MW 1.6.3. Thanks for the different contributors for their help. Please, read the note & changelog.

     Jerome

149. andy dit :
     25 avril 2006 à 21:04

     Thankyou very much. The new patch for 1.6.3 works perfectly.

150. Kyle dit :
     29 avril 2006 à 18:04

     Thanks again, Jerome. This feature is the <b>most important</b> MediaWiki extension, and everyone really appreciates it!

151. Nicholas E. May dit :
     30 avril 2006 à 22:04

     When I followed the instructions found on this page, the patch did not work. However, when I followed the instructions in the READEME that came with the patch (1.6.3), things worked fine. This page told me to add the code for LocalSettings.php to the end of the file, whereas the READEME told me to add it right after require_once( "includes/DefaultSettings.php" );

     Point being, you might want to edit this page a bit to specify the correct location for the code. Ditto for the MediaWiki page about the patch.

152. Tony dit :
     1 mai 2006 à 04:05

     Can someone tell me how I might restrict a Category?

153. Jerome Combaz dit :
     1 mai 2006 à 14:05

     Nicholas E. May: I specified to place the config after the "require" because some novice users reported bug after putting the config at the most top of the LocalSettings.php file. I can clarify a bit more, but I don’t think your problem is related to that.

     Jerome

154. Tony dit :
     1 mai 2006 à 14:05

     I think I found a bug. When I create a page and manually restrict it, the page does not show up in the search results.

     When I create a page that has a title that matches this $wgRegexRestrict = array("^Secure:", "^Secret "), it is properly restricted, but it shows up in search results. These results display quite a bit of the actual text on the page.

155. T O X I N dit :
     1 mai 2006 à 21:05

     I have such eror when i click on Category Link

     «1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘WHERE cl_to = `page`.page_title AND `page`.page_restrictions NOT LIKE ‘%view=1%” at line 7 (localhost)».

156. Jerome Combaz dit :
     1 mai 2006 à 21:05

     Tony: for now it’s not a bug, just a lack of the patch.

     Regex restriction is a "light solution" to restrict pages based on their title. The restriction works only when accessing the page. It would add cpu load to check the regex restriction everywhere it’s necessary (actually many checks are made with SQL, I don’t know if we have the same regex in SQL and what could be the cpu overload).

     Jerome

157. Jerome Combaz dit :
     1 mai 2006 à 21:05

     Hi T O X I N,

     Thanks for the report. You have a new patch to download and test (v0.64). It includes as well the hebrew translation (see changelog)

     Jerome

158. Yong dit :
     4 mai 2006 à 16:05

     There is a problem in the latest patch on the Special:Recentchangeslinked page. There is SQL error if restriction is enabled. I think the query should also join with the pages table.

     A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

     (SQL query hidden)

     from within function "wfSpecialRecentchangeslinked". MySQL returned error "1054: Unknown column ‘rc_title’ in ‘on clause’ (localhost)".

159. Yong dit :
     4 mai 2006 à 16:05

     Wrong SQL error in the last post, it should be:

     A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

     (SQL query hidden)

     from within function "wfSpecialRecentchangeslinked". MySQL returned error "1054: Unknown column ‘page_restrictions’ in ‘where clause’ (localhost)".

160. Anthony dit :
     5 mai 2006 à 08:05

     Just for those that wondered…0.64 patch works with 1.6.5. I have it running just fine at my site.

     YONG…I cannot duplicate the error you describe. Both 1.6.3 and 1.6.5 with patch 0.64 does not give this error. I would suggest that you rename your LocalSettings.php and rerun the installer and see if that does not fix your problem. Don’t forget to add the restrict data back into LocalSettings.php when you are done!

161. T O X I N dit :
     5 mai 2006 à 19:05

     Anybody please made Wiki 1.6.5 patched version

162. Anthony dit :
     15 mai 2006 à 03:05

     You can get the files already patched at http://www.taac.us/mediawiki-1.6...

     If you have any problems let me know and I will see what I can do.

     Anthony

163. ahru dit :
     15 mai 2006 à 04:05

     thanx for the patched 1.6.5 anthony.

164. Ency dit :
     16 mai 2006 à 00:05

     #Polish translation by Janusz ‘Ency’ Dorożyński 2006-05-16
     #Restrict patch (