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

Problem with "author" permission

I created a new group and assigned only the permission "authorprotect." Users can create a page and set the "author protection", but when they try to edit the page, they get the message "you do not have the necessary permissions", why?

I have read that the extension will automatically assign the permission "author" to the creator of the page, but does not seem to do it...

I have Mediawiki 1.22.6

Does this only protect against changes?

I'm trying to understand the documentation. It seems that this extension only protects against changes. Is that correct?

I'm looking for something that would prevent non-authors reading a page, not just from modifying it.

Fustbariclation (talk) 13:52, 22 July 2014 (UTC)

The problem with Author protect extension when the page was unblocked

I have following situation with this good extension:
For example - the Author protects the page. It works fine
And then it is unblocked by the author or Admin
Than Admin makes some changes in article and protects it from others.
After that Author cannot make changes of the Article, and when it is unblocked again by Admin, other can make a changes, but he cannot protect this page Are the any solution of this?

Or if the Page was protected by Author and Admin makes anyway some changes, so after that the Author cannot edit his page. PLease help how to resove this issue?

Can confirm that this problem exists, although I don't see much need for fixing this. The page needs to be deleted by the administrator and then re-created by the user, to give back the author-protect right for the page to the user. AhmadF.Cheema (talk) 08:05, 3 April 2016 (UTC)

Compatible with MediaWiki 1.33?

Does anyone know if this extension still works with MediaWiki 1.33.1? I installed per the instructions but I can't see the Protect option on pages that I create as a regular user.

No, the extension does not seem to compatible with 1.33 at this time. It will need modification to support the actor table changes, should be a relatively straightforward modification. --Skizzerz 19:18, 31 October 2019 (UTC)

I tried modifying the UserIsAuthor function to account for this (referencing the revision_actor_temp table instead) but haven't gotten it working. Any thoughts on what I might be missing?--MeganKatsumi (talk)

Update: the issue an oversight on my part - I hadn't realized that the author ID and user ID's are distinct. I was able to get it working by revising the UserIsAuthor function as follows:

	public static function UserIsAuthor( $user, $title, $checkMaster = false ) {
		if ( !$title instanceof Title ) {
			return false; // quick hack to prevent the API from messing up.
		}

		if ( $user->getID() === 0 ) {
			return false; // don't allow anons, they shouldn't even get this far but just in case...
		}

		$id = $title->getArticleID();
		$dbr = wfGetDB( $checkMaster ? DB_MASTER : DB_REPLICA );
		$aid = $dbr->selectField( //revised to get actor id from revision_actor_temp table
			'revision_actor_temp',
			'revactor_actor',
			[ 'revactor_page' => $id ],
			__METHOD__,
			[ 'ORDER BY' => 'revactor_timestamp ASC' ]
		);
		$uid = $dbr->selectField( //select corresponding user id from actor table
			'actor',
			'actor_user',
			[ 'actor_id' => $aid ],
			__METHOD__
		);

		return $user->getID() == $uid;
	}

--MeganKatsumi (talk) 14:24, 8 November 2019 (UTC)

Are you planning to push your patch to the official repository ? Anyway thanks a lot for this bug fix MeganKatsumi which is working with MediaWiki 1.34.0 !

--Nicolas NALLET Wiki-Valley.com (talk) 10:45, 22 February 2020 (UTC)

To meet quality criteria we have to improve this patch with proper methods : avoid using direct access to revision_actor_temp but use RevisionStore::getQueryInfo() ; there are details on Actor migration. ~ Seb35 [^_^] 11:08, 5 March 2020 (UTC)

Something like that is probably more future-proof (tested on MW 1.34):

	public static function UserIsAuthor( $user, $title, $checkMaster = false ) {
		if ( !$title instanceof Title ) {
			return false; // quick hack to prevent the API from messing up.
		}

		if ( $user->getID() === 0 ) {
			return false; // don't allow anons, they shouldn't even get this far but just in case...
		}

		$id = $title->getArticleID();
		$dbr = wfGetDB( $checkMaster ? DB_MASTER : DB_REPLICA );
		$revQuery = Revision::getQueryInfo( [ 'user' ] );
		$aid = $dbr->selectField(
			$revQuery['tables'],
			$revQuery['fields']['rev_user'],
			[ 'rev_page' => $id ],
			__METHOD__,
			[ 'ORDER BY' => 'rev_timestamp ASC' ],
			$revQuery['joins']
		);

		return $user->getID() == $aid;
	}

~ Seb35 [^_^] 12:48, 5 March 2020 (UTC)

And Gerrit patch submitted.

~ Seb35 [^_^] 13:36, 5 March 2020 (UTC)

Question

Do users with the (author) permission need to have the (authorprotect) permission for anything? Since I recently removed the (authorprotect) permission from Users on a wiki, because I don't want users to be able to protect all pages they create, in-case they use it to randomly protect pages that should be open for others to edit, regardless if they created the page or not.

I did this because I wanted them to ask a user with the ability to protect authored pages to protect the pages for them, if a user with the (author) permission genuinely thinks that the page has a legitimate reason to be author protected. I've just done a check, and I still seem to access the option to protect pages from non-authors without the (authorprotect) permission. So I'm assuming that the (authorprotect) permission is unnecessary for users that already have the (author) permission. ― C.Syde (talk | contribs) 02:42, 23 January 2020 (UTC)

Just did some checking, and it seems that (author) does require (authorprotect) to work. Although apparently if users have the (protect) permission, they can still change the protection levels of pages, setting them to author protection, if they also have the (author) permission. ― C.Syde (talk | contribs) 05:25, 24 January 2020 (UTC)

The author permission should generally never be manually assigned to any non-privileged group. It is automatically granted to the page author. In order to protect or change protection settings, the authorprotect permission is needed. Granting author manually is only useful for letting a group edit all author-protected pages (so, you may consider giving it to administrators) --Skizzerz 20:29, 25 January 2020 (UTC)

No longer working

I was wondering what I could do to see why this extension suddenly stopped working. Is it perhaps not compatible with 1.34.2? Reception123 (talk) 06:03, 7 July 2020 (UTC)

Which error message do you get ? EverybodyWiki (talk) 08:17, 23 December 2020 (UTC)

Error message when editing a protected page with Visual editor

After protecting one of a page I have created I got this error message :

This page has been protected to prevent editing or other actions.

when trying to save with Visual editor. Workaround : If I switch to Wikicode from Visual Editor I can save my edits. Versions :

• MW : 1.35.0
• AuthorProtect 1.4.0 (ea8cddf) 08:39, 13 July 2020

EverybodyWiki (talk) 10:55, 23 December 2020 (UTC)