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:

• $res = $dbr->query( "SELECT rev_user FROM ".$dbr->tableName('revision')." WHERE rev_page={$id} LIMIT 1", __METHOD__ );

--Wolcott 12:43, 7 July 2008 (UTC)

The {$wgDBPrefix} should have filled in the appropriate prefix, not sure why it didn't. --Skizzerz 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* --Skizzerz 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? --Skizzerz 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. --Skizzerz 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. --Skizzerz 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. --Skizzerz 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. --Skizzerz 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. --Skizzerz 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)

This has been fixed in the latest version --Skizzerz 20:51, 1 June 2009 (UTC)

Works perfect now (tested with MW 1.14)! Thank you very much!! - --Ulli 757 20:02, 2 June 2009 (UTC)

Sorry,I have the problem on 1.15.2, I use the latest version --ytwang

help

Warning: pg_query() [function.pg-query]: Query failed: ERROR: ошибка синтаксиса в или рядом "`" LINE 1: SELECT /* userIsAuthor Vpa */ `rev_user` FROM `revision` WHE... ^ in /usr/local/www/data/wiki/includes/db/DatabasePostgres.php on line 578

Внутренняя ошибка A database error has occurred Query: SELECT `rev_user` FROM `revision` WHERE rev_page=1 LIMIT 1 Function: userIsAuthor Error: 1 ERROR: ошибка синтаксиса в или рядом "`" LINE 1: SELECT /* userIsAuthor Vpa */ `rev_user` FROM `revision` WHE... ^

Backtrace:

1. 0 /usr/local/www/data/wiki/includes/db/Database.php(591): DatabasePostgres->reportQueryError('ERROR: ???????...', 1, 'SELECT `rev_use...', 'userIsAuthor', false)
2. 1 /usr/local/www/data/wiki/extensions/AuthorProtect/AuthorProtect.php(155): Database->query('SELECT `rev_use...', 'userIsAuthor')
3. 2 /usr/local/www/data/wiki/extensions/AuthorProtect/AuthorProtect.php(36): userIsAuthor()
4. 3 [internal function]: efAuthorProtectDelay(Object(Title), Object(User), 'read', NULL)
5. 4 /usr/local/www/data/wiki/includes/Hooks.php(117): call_user_func_array('efAuthorProtect...', Array)
6. 5 /usr/local/www/data/wiki/includes/Title.php(1409): wfRunHooks('userCan', Array)
7. 6 /usr/local/www/data/wiki/includes/Wiki.php(148): Title->userCanRead()
8. 7 /usr/local/www/data/wiki/includes/Wiki.php(55): MediaWiki->preliminaryChecks(Object(Title), Object(OutputPage), Object(WebRequest))
9. 8 /usr/local/www/data/wiki/index.php(114): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
10. 9 {main}

wut to do? MW 1.14 ---217.170.213.124 13:39, 17 July 2009 (UTC)

Namespace

any ways to exclude AuthorProtect from Talk namespace? Stahn85 06:30, 19 November 2009 (UTC)

PHP error with MW 1.16.0

There is a PHP error that pops up with enabled with MW 1.16.0. Has anyone else had this issue?

Thanks in advance. --Dgennaro 17:02, 11 August 2010 (UTC)

The most current version of AuthorProtect is only compatible with 1.18 and above (1.18 should be put into beta stage pretty soon). This is because it is very difficult to add a protect link into Vector for 1.16 and 1.17. --Skizzerz 22:04, 10 August 2011 (UTC)

Author protect menu option not visible in Vector skin

Extension works brilliantly very keen to use it but I don't get the option to protect the page when using the Vector skin. I understand it handles menus slightly differently. Any help? --Tim Byrne 11:06, 18 April 2011 (UTC)

You can still type "blabla/index.php?title=pagename&action=authorprotect" in the addressbar. As a workaround i made a link to put in the page direcly: [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAMEE}}|action=authorprotect}} protection] (actually i put it into a template)--84.196.112.226

I made a fix. you have to hack the vector.php for this. The disadvantage is that there is no knowledge of the author here, so the protect feature is visible to everyone with authorprotect permisson. But it will only work for the author (like should). I expect a better vector.php implementation soon, because more extensions rely on custom actions. Add the following on line 226, it is an extension of the user-protect if-statement.
elseif (
$this->mTitle->getNamespace() !== NS_MEDIAWIKI &&
$wgUser->isAllowed( 'authorprotect' )
) {
if ( !$this->mTitle->isProtected() ) {
$links['actions']['protect'] = array(
'class' => ( $action == 'protect' ) ?
'selected' : false,
'text' => wfMsg( 'vector-action-protect' ),
'href' =>
$this->mTitle->getLocalURL( 'action=authorprotect' )
);
} else {
$links['actions']['unprotect'] = array(
'class' => ( $action == 'unprotect' ) ?
'selected' : false,
'text' => wfMsg( 'vector-action-unprotect' ),
'href' =>
$this->mTitle->getLocalURL( 'action=authorprotect' )
);
}
} hope it helps, --Clemens Zweekhorst

Or you could just wait until MediaWiki 1.18, where this is actually fixed/implemented. --Skizzerz 22:02, 10 August 2011 (UTC)

RestrictionTypes display

Upon implementing this extension in MW 1.17, the form displays additional options which i think has no function at all:

• <authorprotect-create>
• <authorprotect-upload>

I believe, the create and upload options were derived from $wgRestrictionTypes value from DefaultSettings.php How can i remove those additional options? --lonely_girl01 06:40, 29 September 2011 (UTC)

The current version of AuthorProtect is made for versions 1.18 and above. You can either wait for 1.18 to be released, try using an older version and making the changes described above to make it show up in vector, or just ignore the superfluous options for now :). --Skizzerz 03:27, 30 September 2011 (UTC)

Thanks User:Skizzerz! What i did for now is, create an empty description for the two unused options so there would be no text display beside the checkbox.haha --lonely_girl01 06:33, 1 October 2011 (UTC)

I think I have found the solution. In AuthorProtect.php, Instead of reading global $wgRestrictionTypes; you may use $article->getTitle()->getRestrictionTypes(); This loads the per-page available restrictions and solves the problem. With this, the current hack if( $type == 'upload' || $type == 'create' ) { continue; } is no more needed :) I do not know how to update the SVN, so I post the solution here. I am currently working on an extension to have a full READ right management working (lot of people are looking for it) based on AuthorProtect. --Yannouk