Extension talk:AuthorProtect

Error Accessing Database table
I have a prefix on my tables "wac_" and thus line 153 weas causing an error "Unknown table". So I change the code:

FROM:
 * $res = $dbr->query( "SELECT `rev_user` FROM `{$wgDBPrefix}revision` WHERE rev_page={$id} LIMIT 1", __METHOD__ );

TO: --Wolcott 12:43, 7 July 2008 (UTC)
 * $res = $dbr->query( "SELECT rev_user FROM ".$dbr->tableName('revision')." WHERE rev_page={$id} LIMIT 1", __METHOD__ );
 * The {$wgDBPrefix} should have filled in the appropriate prefix, not sure why it didn't. -- Skiz zerz  20:39, 7 July 2008 (UTC)
 * After looking closer you have $wgDBPrefix when it is suppose to be $wgDBprefix. Lowercase "p".  Needs to be changed in two places in the function.--Wolcott 21:43, 7 July 2008 (UTC)
 * >_< Fixed. *grumbles something about how variable names should be case insensitive* -- Skiz zerz  23:28, 7 July 2008 (UTC)

AuthorProtect kills API
When using the AuthorProtect Extension the Mediawiki APi is not useable anymore! This Error ocurres

Fatal error: Call to a member function getArticleId on a non-object in /.../extensions/AuthorProtect/AuthorProtect.php on line 151

plz correct this bug fast

--DaSch 19:02, 25 September 2008 (UTC)
 * I think I've fixed it, can you please verify? -- Skiz zerz  20:36, 25 September 2008 (UTC)
 * Seams to work now. Thanks. --DaSch 13:48, 27 September 2008 (UTC)

Systemmessages not used
The systemmessage Protect-level-author is not used instead the Protect-fallback is used --DaSch 22:25, 9 February 2009 (UTC)

Security hole when page has images
This is a nice extension, but I believe there is a security hole : if the protected page has an image, another user can change that image by reuploading it, and thus change the image content of the protected page.

I thought that protecting the Image:filename page would do it, but that's protecting the image description, not the image (at least I believe that, I did not test it). I may try to use this hook : if the image description is protected, then only authors can reupload that image.

Any other idea ? Pcarbonn 23:50, 24 February 2009 (UTC)
 * Protecting an image page will protect the image as well. Anyway, the same "security hole" you described happens with other transcluded things, such as templates. This is the way that protection works by default, so unless the protection method is altered (which it won't be since cascading protection already exists), this will probably not be fixed. -- Skiz zerz  00:26, 25 February 2009 (UTC)


 * Thanks for your useful response. It's good that protecting an image page protects the image as well.  Your point about Cascading Protection is also interesting : wouldn't it be useful to have a checkbox in AuthorProtect allowing an author to cascade protect his page ? Pcarbonn 09:48, 25 February 2009 (UTC)
 * No, it wouldn't, since it would protect those transcluded pages for their respective authors, which doesn't solve the problem and only creates more of a headache. -- Skiz zerz  22:53, 25 February 2009 (UTC)

Fatal error
Fatal error: Call to protected method Article::flattenrestrictions from context '' in C:\wamp\www\sanopedia\extensions\AuthorProtect\AuthorProtect.php on line 208

208	$current = Article::flattenRestrictions( $current );

I use windows xp sp2, wamp2, mediawiki 1.14.0.

--C32v 23:02, 1 March 2009 (UTC)
 * Bah... I should get a fix up in a day or two. -- Skiz zerz  00:00, 2 March 2009 (UTC)

Hello! You managed to do the modification? --C32v 17:26, 4 March 2009 (UTC)
 * I'm still testing it out, there appears to be a bug that prevents it from unprotecting fully after my modifications. -- Skiz zerz  04:09, 5 March 2009 (UTC)


 * I have the same problem, it works with mediawiki 1.13 but with mediawiki 1.14 I get "Fatal error: Call to protected method Article::flattenrestrictions from context '' in /home..../extensions/AuthorProtect/AuthorProtect.php on line 210 - Is a fix available? (btw the function flattenrestrictions is static protected in Version 1.14, it was not protected in Version 1.13 - perhaps this is the reason? - --Ulli 757 20:47, 30 May 2009 (UTC)
 * Yes, that would be the reason. Since I'm a bit busy at the moment, it might take a while to get a fix up. In the meantime, removing the word "protected" in front of the function definition will work. -- Skiz zerz  22:16, 31 May 2009 (UTC)
 * My workaround was to copy the function flattenrestrictions into your sourcecode, it works for me and I did'nt have to change MediaWiki Corefiles. Probably another solution could be to call the public function "updateRestrictions( $limit = array, $reason = '', &$cascade = 0, $expiry = array )" instead of "$success = doProtect( $restrictions, $wgRequest->getText('wpReason'), $wgRequest->getText('wpExpiryTime') );" ??? ---Ulli 757 06:22, 1 June 2009 (UTC)