Extension talk:Approved Revs/Archive 2016 to 2017

From mediawiki.org

Call to undefined method WebRequest::getOffsetLimit()

When trying to access the page Special:ApprovedRevs I get the following error: 

 Fatal error: Call to undefined method WebRequest::getOffsetLimit() in /var/www/html/extensions/ApprovedRevs/SpecialApprovedRevs.php on line 23

I looked through that php file and found the call to getOffsetLimit() but no defined method within that page, and I don't see any includes for another spot the method would be located. Has anyone else seen this?

What version of MediaWiki are you running? Yaron Koren (talk) 19:45, 14 January 2016 (UTC)
I'm using MediaWiki 1.26.2. - chazbot7 21 January 2016
It looks like this function got renamed to getLimitOffset(), and changing getOffsetLimit() to getLimitOffset() seems top fix it. I guess this makes sense since the return value is [$limit, $offset] (and not [$offset, $limit])... Carpetsmoker (talk) 08:15, 30 January 2016 (UTC)
Sorry about that! And thanks for figuring out the issue. This wasn't due to a change in MediaWiki, just a bug in a recent patch to Approved Revs. I just checked in a fix. Yaron Koren (talk) 02:36, 31 January 2016 (UTC)

Issue with PHP7

When I try to use this Extension on a server with PHP7, I get the following error:
Fatal error: Redefinition of parameter $flags in [IP]\wiki\extensions\ApprovedRevs\ApprovedRevs.hooks.php on line 90

I think this might be due to PHP7: Redefinition of Function Parameter when the Name is Duplicated

In the hooks file, I simply changed the first $flags to &$flags and accordingly deleted the second &$flags. I'm not a PHP expert, but right now it seems to work on my test server. Can anybody with more expertise approve this modification? --TheFamilyBusiness (talk) 13:14, 8 February 2016 (UTC)

I would like to answer my own question: It seems that the deletion of the second flags parameter won't lead to the desired result. The automatic confirmation won't work anymore. I think I found the critical functions:
$wgHooks['ArticleSaveComplete'][] = 'ApprovedRevsHooks::setLatestAsApproved';
$wgHooks['ArticleSaveComplete'][] = 'ApprovedRevsHooks::setSearchText';
line 48-49 of ApprovedRevs.php
The respective functions can be found in ApprovedRevs.hooks.php. I simply changed the function parameters from the original code
static public function setLatestAsApproved( &$article , &$user, $text,
	$summary, $flags, $unused1, $unused2, &$flags, $revision,
	&$status, $baseRevId )
line 90 of ApprovedRevs.hooks.php
to
static public function setLatestAsApproved( &$article, &$user, $text, $summary, 
	$minoredit, $watchthis, $sectionanchor, &$flags, 
	$revision, &$status, $baseRevID)
as demanded by Manual:Hooks/ArticleSaveComplete. The same procedure has to be done with 
static public function setSearchText
(line 123).
As it seems right now, the ApprovedRevs extension seem to work with PHP7! --TheFamilyBusiness (talk) 13:31, 22 February 2016 (UTC)

Code proposal

original code in ApprovedRevs.hooks.php: 

		// Show the user links if they're allowed to see them.
		// If hidden, then show them only if requested...
		$userlinks = Linker::revUserTools( $revision, !$unhide );

		$infomsg = $current && !wfMessage( 'revision-info-current' )->isDisabled()
			? 'revision-info-current'
			: 'revision-info';

replace by 

		// Show the user links if they're allowed to see them.
		// If hidden, then show them only if requested...
		$userlinks = Linker::revUserTools( $revision, !$unhide );
		// Show link to approve current rev
		if ( ApprovedRevs::userCanApprove( $title ) ) {
			$approvecurrentlink = ' ' . Linker::link(
				$title,
				wfMessage( 'approvedrevs-approvethisrev' )->escaped(),
				array(),
				array( 	'action' => 'approve',
					'oldid' => $revisionID ),
				array( 'known', 'noclasses' )
			);
		} else {$approvecurrentlink = ' ';}

		$infomsg = $current && !wfMessage( 'revision-info-current' )->isDisabled()
			? 'revision-info-current'
			: 'revision-info';

after that original code 

		$outputPage->addSubtitle( "<div id=\"mw-{$infomsg}\">" . wfMessage( $infomsg,
			$td )->rawParams( $userlinks )->params( $revision->getID(), $tddate,
			$tdtime, $revision->getUser() )->parse() . "</div>" );

replace by 

		$outputPage->addSubtitle( "<div id=\"mw-{$infomsg}\">" . wfMessage( $infomsg,
			$td )->rawParams( $userlinks )->params( $revision->getID(), $tddate,
			$tdtime, $revision->getUser() )->rawParams( $approvecurrentlink )->parse() . "</div>" );

Now when viewing latest revision you will have button to approve current revision

and on more inside displayNotApprovedHeader function at the end

after $title = $article->getTitle(); add 

		$revisionID = $article->getLatest();
		if ( ! ApprovedRevs::pageIsApprovable( $title ) ) {
			return true;
		}

		if ( ! ApprovedRevs::hasApprovedRevision( $title ) ) {
			$text = wfMessage( 'approvedrevs-noapprovedrevision' )->text();

			if ( ApprovedRevs::userCanApprove( $title ) ) {
				$text .= ' ' . Linker::link(
					$title,
					wfMessage( 'approvedrevs-approvethisrev' )->escaped(),
					array(),
					array( 	'action' => 'approve',
							'oldid' => $revisionID )
				);
			}

instead of 

		if ( ! ApprovedRevs::pageIsApprovable( $title ) ) {
			return true;
		}

		if ( ! ApprovedRevs::hasApprovedRevision( $title ) ) {
			$text = wfMessage( 'approvedrevs-noapprovedrevision' )->text();

			}

User will get link to approve latest rev of page if no revision was approved before for that page. Sry for my poor english, I hope my idea will be helpfull

@Yaron_Koren: Ibutakov.smartec (talk) 13:02, 23 March 2016 (UTC)

Thank you for this patch. When I was first designing Approved Revs, I thought about having links at the top of pages for doing approvals, just like you're doing here. But I decided that it would be better to only have them on the history page, because admins always (I think) have to go to the history page anyway when doing an approval, so that they can see what the exact changes were from the previous approval. Would you disagree with that? Yaron Koren (talk) 17:42, 23 March 2016 (UTC)
@Yaron_Koren: I agree, but here's the thing. Sometimes me (admin) need to change something on any page. I know what changes i have made, so I don't need to check them twice - in such situation buttons provided is usefull. It will be great if you could make such links as option (easy to implement and easy to use - 1 parameter in LocalSettings.php). I have another idea, but have no time to implement - allow auto-approvals only for some protected pages (such as pages only allowed to edit by sysops) or only for certain users (array of names or, better, groups). Auto-approvals everywhere is not an option for my site. P.S. Please, use mentioning so I could see your answer faster, ty. Ibutakov.smartec (talk) 14:16, 7 April 2016 (UTC)
@Ibutakov.smartec - alright. It seems like the "auto-approval" thing might be the real issue here, since, if you had auto-approvals working the right way, you wouldn't need that extra "approve" button in the first place. I agree that it would be great to have more control over who can approve which pages; there was actually an attempt to add that in to Approved Revs a few years ago, but it didn't work out. Why can't you use the standard auto-approval on your site, by the way? Yaron Koren (talk) 15:49, 8 April 2016 (UTC)
@Yaron_Koren: Because we have different types of information that need to be checked by different users (experts), so this mechanism used to double check for mistakes (sometimes it may became crucial). Thats why auto-approval for some users or groups won't completely solve my problem, it only needed for some unimportant info.Ibutakov.smartec (talk) 08:32, 11 April 2016 (UTC)
Okay, that makes sense. I'll think about this. I think we both agree that having auto-approvals based on page "ownership" is the better solution, but obviously that would take a lot more work than adding in your patch would. Yaron Koren (talk) 14:24, 11 April 2016 (UTC)
@Yaron_Koren: Thanks. Another question: is it possible to change background color of unaproved version to make it little bit more noticeable? For example that can be done by adding some class to body using OutputPageBodyAttributes hook and then color it by using common.css .notLatestRevClass { background-color: #EFEFEF; } My knowlege is not enough to make it on my own. And another one: if approved rev is not latest - show link to compare with latest.
	$text .= ' (' . Linker::link(
		$title,
		wfMessage( 'approvedrevs-difffromlatest' )->parse(),
		array(),
		array( 	'type' => 'revision',
				'diff' => $article->getLatest(),
				'oldid' => $revisionID ),
		array( 'known', 'noclasses' )
	);
	$text .= ').';
Just to be clear, that's just ideas that, I hope, would be useful. No pressure :) Ibutakov.smartec (talk) 09:24, 14 April 2016 (UTC)
By "unapproved version", do you mean a page with no approved revision? Or are you talking about just viewing any revision other than the approved one?
The "diff" idea is interesting. Yaron Koren (talk) 12:33, 14 April 2016 (UTC)
@Yaron_Koren: by unapproved I meant when I open some page that have approved revision but not latest. By default I see approved one and a sign (if activated) approvedrevs-notlatest (depends on selected language). So my code goes after that, inside setSubtitle function. (I'm just too lazy to make another translated message so used yours). If your question was about grey color - it will be great if it will be changed both cases: when page have no approved revisions and when approved revision is not latest (better if it could be turned on separately, different classes for different colors if implemented by css style). Ibutakov.smartec (talk) 13:01, 14 April 2016 (UTC)
And it will be great to have approve latest button in comparison page (Difference between revisions of "lalala"). Something like
Latest revision as of 17:25, 13 April 2016 (edit) (undo)
             Root (Talk | contribs | block)
 (Replaced content with "11")   (change visibility)
                     (approve latest)
The color thing doesn't strike me as a good idea - one of my goals in designing these interfaces is to follow MediaWiki's own interface conventions as much as possible, and MediaWiki never uses the page background color to convey information, as far as I know. (It could if it wanted to, for instance to show that the revision being viewed is not the latest one.) The link in the comparison page seems more reasonable, although wouldn't "Approve" make more sense as the link text than "Approve latest"? It's not necessarily the latest revision. Yaron Koren (talk) 14:03, 14 April 2016 (UTC)
@Yaron_Koren: Yeah, "approve" would be totally ok. Ibutakov.smartec (talk) 14:29, 14 April 2016 (UTC)
@Yaron_Koren: Another one :) Is it possible to disable approvals for redirect pages? totally strange to approve it Ibutakov.smartec (talk) 15:48, 15 April 2016 (UTC)
You really should create new sections for new topics. But no, that's not possible. Yaron Koren (talk) 16:15, 15 April 2016 (UTC)

Blank if unapproved & semantic forms

Pages that haven't an approved revision are showed as blank if $egApprovedRevsBlankIfUnapproved is setted to true. But they can't be modified with semantic forms if the user wants to do it. --Lmorillas (talk) 07:43, 11 April 2016 (UTC)

You mean, the "edit with form" tab doesn't show up? There's no way around that, I don't think. If you have "blank if unapproved", and if a page has a template added to it that would make "edit with form" show up, but this new revision is not approved, SF (like the rest of the wiki) has to assume that this revision should not be "trusted" and the page should be treated as if it's still blank. Yaron Koren (talk) 14:48, 11 April 2016 (UTC)
Yes, the "edit with form" tab doesn't show up. I understand it is the usual behaviour but I think it is a usability issue. I must to look for a workaround to solve it. Thanks. --Lmorillas (talk) 21:49, 11 April 2016 (UTC)

Special page Database error + other unintended consequences

Hi!

So I've got a bit of an odd use case here. We only need certain pages to be approveable; however, they're all mixed together in the same namespace.

To try and test this out I set 

$wgApprovedRevsNamespaces = array();

in my LocalSettings.php. I put __APPROVEDREVS__ into the template that all the pages we need to be approveable have. functionally it works; however there's at least one unintended consequence when using the SpecialApprovedRevs page. 

SELECT p.page_id AS id,ar.rev_id AS rev_id,p.page_latest AS latest_id FROM `approved_revs` `ar` JOIN `page` `p` ON ((ar.page_id=p.page_id)) LEFT OUTER JOIN `page_props` `pp` ON ((ar.page_id=pp_page)) WHERE ((p.page_namespace IN ()) OR (pp_propname = 'approvedrevs' AND pp_value = 'y')) ORDER BY p.page_namespace,p.page_title LIMIT 251

So, that's probably failing because it can't find any namespaces. Are there any other issues we might run into?

Thanks! Rosencrantz~mediawikiwiki (talk) 14:24, 3 May 2016 (UTC)

Sorry about that - I guess I never tested with that variable (actually it's $egApprovedRevsNamespaces) holding an empty array. I just checked in what I think is a fix for that bug. No idea if there are any other bugs - that's the beauty of bugs. Yaron Koren (talk) 18:10, 3 May 2016 (UTC)
I too encountered this issue the other day, but found a workaround. Thanks for properly fixing it! I also encountered another issue where pages with __APPROVEDREVS__ would always show the latest, and not the approved, content. I have submitted a patch to Gerrit a few weeks ago (https://gerrit.wikimedia.org/r/#/c/284015/) that solves this. It would be great if that patch could be merged too. --Remco de Boer 09:50, 15 May 2016 (UTC)
Thanks for pointing that out! I think I somehow missed that patch entirely. It looks good; I just checked it in. Yaron Koren (talk) 01:16, 16 May 2016 (UTC)
Thanks! --Remco de Boer 19:36, 17 May 2016 (UTC)

Non Approved Articles do not appear in category

Hello, I made an update of mediawiki and of all the plugins and now, we have to approve articles so they get shown on in the Category Page. But we dont want this behaviour, we want every article with the Category set be shown in the Category.

Is this a bug or is it possible to change this behaviour?

Regards — Preceding unsigned comment added by Deniz koekden (talk • contribs)

If the approved text does not contain the category, and the unapproved text does contain it, then it's normal and expected behavior. Imagine someone does the reverse thing, removing a category from a page, you want the page to appear in the category until it's approved. --Ciencia Al Poder (talk) 00:20, 2 July 2016 (UTC)

Okay, that makes sense. But there is no approved version of the Article. So e.g. I create an article and tag it in a category then it does not show in that category. It did before we updated mediawiki and all the plugins. That is the behaviour we want. --Deniz koekden (talk) 12:07, 2 July 2016 (UTC)

Do you have "$egApprovedRevsBlankIfUnapproved = true" in LocalSettings.php? If so, maybe this would be solved by just getting rid of that line. Yaron Koren (talk) 13:39, 6 July 2016 (UTC)

Remove: This is the approved revision of this page, as well as being the most recent.

Does anyone have a solution to remove the line: This is the approved revision of this page, as well as being the most recent. ? I have tried the $egApprovedRevsShowNotApprovedMessage = false; in localsettings.php as well. Any ideas? *UPDATE* this worked:

$wgGroupPermissions['*']['viewlinktolatest'] = false; $wgGroupPermissions['sysop']['viewlinktolatest'] = true;

I was able to edit the file en.json in the directory /ApprovedRevs/i18n/. This file contained the english strings associated with the various components. By setting the string to an empty length, I can supress the message. Jayden. I presume if your mediawiki is set to a different language, then you'll want to edit that.
You should've edited a System message instead. You'll lose your modifications on the next upgrade. --Ciencia Al Poder (talk) 09:33, 14 September 2016 (UTC)
That's true - you should avoid modifying the extension code whenever possible. Although in this case, the best solution is just to add this to LocalSettings.php:
$wgGroupPermissions['*']['viewlinktolatest'] = false;
The original poster noted that, although with the formatting it was easy to miss. Yaron Koren (talk) 13:11, 14 September 2016 (UTC)

View of latest revision

Hello,

Is there any option allowing that an administrator views automatically the latest revision instead of the approved revision ? I mean by that avoiding, for some users type, to : 1/ go to the approved page ; 2/ go to the history ; 3/ select the last revision ; 4/ view the last revision.

Thanks in advance for your answer.

No, there's no way to do that. That's on purpose, to ensure that admins always see the same thing that regular users see. If there were a way to make it easier, though, I'd definitely consider that. I wouldn't say it's four steps right now to see the latest revision, really just two steps - click on the history page, then click on the top row. Still, that can get annoying, especially if you're trying to maintain a lot of pages. Yaron Koren (talk) 18:42, 25 August 2016 (UTC)
Actually, I just realized that it's only one step - for pages whose approved revision is not their latest, you should see a small "View the most recent revision" link right below the page title. Yaron Koren (talk) 23:10, 25 August 2016 (UTC)

OK, Thanks for your answer !

The extension has a problem in 1.27 version

Hi. I was update my mediawiki system to 1.27 version. Now , there is an error in Approved Rev extension , the error is : 

Call to undefined method OutputPage::appendSubtitle() in /var/www/mawdoo3/extensions/ApprovedRevs/ApprovedRevs.hooks.php on line 901

Does there is a new version for the extension compatible with a new mediawiki version.?? Thank you.

I think you just need to update your Approved Revs code - it seems like you're using an old version. Yaron Koren (talk) 14:07, 27 September 2016 (UTC)

Who approved (code proposal)

@Yaron_Koren: I have a proposal for you: ability to see who approved latest version of page. Easy to do:

Add to ApprovedRevs_body.php: ↓
	static $mApprovedRevUserForPage = array();

/**
	 * Gets the approved revision User for this page, or null if there isn't
	 * one.
	 */
	public static function getApprovedRevUser( $title ) {
		$pageID = $title->getArticleID();
		if ( array_key_exists( $pageID, self::$mApprovedRevUserForPage ) ) {
			return self::$mApprovedRevUserForPage[$pageID];
		}

		if ( ! self::pageIsApprovable( $title ) ) {
			return null;
		}

		$dbr = wfGetDB( DB_SLAVE );
		$revUser = $dbr->selectField( 'approved_revs', 'appr_user', array( 'page_id' => $pageID ) );
		self::$mApprovedRevUserForPage[$pageID] = $revUser;
		return $revUser;
	}

        //slightly changed from original
	public static function saveApprovedRevIDInDB( $title, $rev_id ) {
		$dbr = wfGetDB( DB_MASTER );
		$page_id = $title->getArticleID();
		global $wgUser;
		$appr_user = $wgUser->getName();
		$old_rev_id = $dbr->selectField( 'approved_revs', 'rev_id', array( 'page_id' => $page_id ) );
		if ( $old_rev_id ) {
			$dbr->update( 'approved_revs', array( 'rev_id' => $rev_id ), array( 'page_id' => $page_id ) );
			$dbr->update( 'approved_revs', array( 'appr_user' => $appr_user ), array( 'page_id' => $page_id ) );
		} else {
			$dbr->insert( 'approved_revs', array( 'page_id' => $page_id, 'rev_id' => $rev_id, 'appr_user' => $appr_user ) );
		}
		// Update "cache" in memory
		self::$mApprovedRevIDForPage[$page_id] = $rev_id;
		self::$mApprovedRevUserForPage[$page_id] = $appr_user;
	}

later add something like 

		$revisionUser = ApprovedRevs::getApprovedRevUser( $title );
		if ( $revisionUser != '' ) {
			$user = User::newFromName( $revisionUser );
			$userPageTitle = $user->getUserPage();
		}

			if ( $revisionUser != '' ) {
				$text .= ' Approved by ';
				$text .= Linker::link(
					$userPageTitle,
					$revisionUser,
					array(),
					array(),
					array( 'known', 'noclasses' )
				);
			}

to your setSubtitle function inside ApprovedRevs.hooks.php and create 3rd column for SQL table (appr_user in my case) 217.108.170.8 11:15, 25 November 2016 (UTC)

This is an interesting idea. You can already see who approved the latest revision by going to the history page, then clicking on "View logs for this page" at the top - unless there has been a huge amount of activity related to that page, the latest approval should be viewable there. I admit that that's obscure - although putting the approver's name right at the top of the page seems like the opposite: a little too conspicuous.
This is all complicated by the fact that auto-approvals make the concept of "approved by" a little blurry. If an administrator makes an edit to a page and that latest revision gets automatically approved, does that administrator deserve to be listed as the approver? After all, they didn't actively do anything to approve that revision. But listing anyone else as the approver would also be strange.
What about listing the approver's username on the history page, right near the star in the approved revision's entry - and only if the approval was not an auto-approval?
I guess this is really two or more questions: where (if anywhere) to display the approver information, and whether to display it in all cases. Any thoughts on this? Yaron Koren (talk) 16:55, 25 November 2016 (UTC)
@Yaron_Koren: I think approver's name near revision in page history (+not auto approved) would be great. I proposed my version above because I created that solution for my company and we need to see approver's name right away when viewing page. Yeah, that's just in my case, but for everyone, it would be great to see that name easier than looking into log. So, username after revision in history page seems great idea to me. And, btw, we do not use auto approvals, so I didn't even think of how my idea will work with that. Sorry for my poor english :) 217.108.170.8 10:20, 28 November 2016 (UTC)

1.28.0 Warnings

Getting a lot of PHP Warnings since upgrading to 1.28.0 

2016/12/01 01:14:43 [error] 22933#22933: *1021790 FastCGI sent in stderr: "PHP message: PHP Warning:  Attempt to modify property of non-object in /<path>/extensions/ApprovedRevs/ApprovedRevs.hooks.php on line 239

Debian 8.1, nginx 1.10.2, PHP-FPM 7.0.13, MariaDB 10.1.19, Mediawiki 1.28.0, REL1_28 extensions --FoXFTW (talk) 00:22, 1 December 2016 (UTC)

This may or may not be the issue, but: you shouldn't use the MediaWiki version branch (i.e., REL1_28) for Approved Revs, or most other non-Wikimedia extensions, since it just represents a random snapshot. Instead, you should get the latest version of the code, if at all possible. If you can't do that - what code do you see on that line of that file? Yaron Koren (talk) 03:24, 1 December 2016 (UTC)
@Yaron_Koren: Hi, I have the same error on 1.28.0 (stable release) but I turned off errors viev and everythings working very vell. http://i.imgur.com/a51YYTU.png (Top of the page)
What code do you have on that line? Yaron Koren (talk) 04:32, 1 December 2016 (UTC)
@Yaron_Koren I cloned the master branch from github, still getting the warnings for line 239 
Line 239: return self::showBlankIfUnapproved( $article, $contentObject->mText );
By removing ->mText in Line 239 the warning seems to be fixed. $contentObject isn't an object but a string --FoXFTW (talk) 21:42, 1 December 2016 (UTC)
Okay, that's the same code I have for that line. It's just very strange that it's producing that error... FoXFTW - are you sure $contentObject is a string? Maybe it's null? And if it is a string, what does it hold - the page contents? Yaron Koren (talk) 05:02, 2 December 2016 (UTC)
$contentObject is not null, I tested that. I'm pretty sure that $contentObject is a string since it only holds the complete pages content. (is_object returns false) --FoXFTW (talk) 11:10, 2 December 2016 (UTC)
Alright, that's very good to know. This may possibly be a bug in MW 1.28, but in any case, I just added in a check to the code, using is_object(); so this warning message will hopefully go away. Yaron Koren (talk) 13:14, 2 December 2016 (UTC)

redirect to page after approval

@Yaron_Koren:

Maybe, it will be more convenient to redirect user to approved page after approve(unapprove) action instead of showing message? Subtitle will already say to user that his approval was successful. easy to do:

Add to ApprovedRevs.hooks.php: ↓
static function setAsApproved( $action, $article ) {
//some code
		$article->view();

		$wgOut->redirect( $article->getTitle()->getFullURL() );
//some code
static function unsetAsApproved( $action, $article ) {
//some code
		$article->doPurge();
		$article->view();

		$wgOut->redirect( $article->getTitle()->getFullURL() );

217.108.170.8 09:23, 19 December 2016 (UTC)

What do you mean by "more convenient"? What's inconvenient about the current approach? Yaron Koren (talk) 03:46, 20 December 2016 (UTC)
@Yaron_Koren: Right now when you approve some page you will see at the top of that page message that page was successfully approved AND another one, saying that this version is not approved. A little bit misleading. Another minus - no edit section links after approve action. Just IMHO, no offence :) 217.108.170.8 09:00, 20 December 2016 (UTC)
Do you really see a "this version is not approved" message, on the screen right after approving a revision? I don't see that part. Yaron Koren (talk) 14:41, 20 December 2016 (UTC)

DBQueryError

Tables are not correctly aliased in userCanApprove, query fails


$row = $dbr->selectRow( array( 'revision', 'page' ), 'revision.rev_user_text', array( 'page.page_title' => $title->getDBkey() ), null, array( 'ORDER BY' => 'revision.rev_id ASC' ), array( 'revision' => array( 'JOIN', 'revision.rev_page = page.page_id' ) ) );

results in bad query

SELECT revision.rev_user_text FROM `dbsitenamepage` JOIN `dbsitenamerevision` ON ((revision.rev_page = page.page_id)) WHERE page.page_title = 'Main_Page' ORDER BY revision.rev_id ASC LIMIT 1

should be

$row = $dbr->selectRow( array( 'r' => 'revision', 'p' =>'page' ), 'r.rev_user_text', array( 'p.page_title' => $title->getDBkey() ), null, array( 'ORDER BY' => 'r.rev_id ASC' ), array( 'revision' => array( 'JOIN', 'r.rev_page = p.page_id' ) ) );

Thanks for this fix - I just checked it in. Yaron Koren (talk) 04:52, 13 January 2017 (UTC)

Working with redirects

@Yaron_Koren: Right now when you look at Special:ApprovedRevs page you can see all pages, redirects and ordinary informational pages. I propose to slightly change formatResult function to mark redirect pages in a list of results

SpecialApprovedRevs.php: ↓
	function formatResult( $skin, $result ) {
		$title = Title::newFromId( $result->id );

		if( !ApprovedRevs::pageIsApprovable( $title ) ) {
			return false;
		}

		$pageLink = Linker::link( $title );

		if ( $this->mMode == 'unapproved' ) {
			global $egApprovedRevsShowApproveLatest;

			$line = $pageLink;
			if ( $title->isRedirect() ) {
				$line .=Xml::element( 'strong',
				null,
				' (REDIRECT PAGE)'
				);
			}
			if ( $egApprovedRevsShowApproveLatest &&
				$title->userCan( 'approverevisions' ) ) {
				$line .= ' (' . Xml::element( 'a',
					array( 'href' => $title->getLocalUrl(
						array(
							'action' => 'approve',
							'oldid' => $result->latest_id
						)
					) ),
					wfMessage( 'approvedrevs-approvelatest' )->text()
				) . ')';
			}

			return $line;
		} elseif ( $this->mMode == 'notlatest' ) {
			$line = $pageLink;
			if ( $title->isRedirect() ) {
				$line .=Xml::element( 'strong',
				null,
				' (REDIRECT PAGE)'
				);
				$line .= ' (' . Xml::element( 'a',
					array( 'href' => $title->getLocalUrl(
						array(
							'action' => 'approve',
							'oldid' => $result->latest_id
						)
					) ),
					wfMessage( 'approvedrevs-approvelatest' )->text()
				) . ')';
			}
			$line .= ' (' . Xml::element( 'a',
				array( 'href' => $title->getLocalUrl(
					array(
						'diff' => $result->latest_id,
						'oldid' => $result->rev_id
					)
				) ),
				wfMessage( 'approvedrevs-difffromlatest' )->text()
			) . ')';

			return $line;
		} else { // main mode (pages with an approved revision)
			global $wgUser, $wgOut, $wgLang;

			$additionalInfo = Xml::element( 'span',
				array (
					'class' => $result->rev_id == $result->latest_id ? 'approvedRevIsLatest' : 'approvedRevNotLatest'
				),
				wfMessage( 'approvedrevs-revisionnumber', $result->rev_id )->text()
			);

			// Get data on the most recent approval from the
			// 'approval' log, and display it if it's there.
			$loglist = new LogEventsList( $wgOut->getSkin(), $wgOut );
			$pager = new LogPager( $loglist, 'approval', '', $title->getText() );
			$pager->mLimit = 1;
			$pager->doQuery();
			$row = $pager->mResult->fetchObject();

			if ( !empty( $row ) ) {
				$timestamp = $wgLang->timeanddate( wfTimestamp( TS_MW, $row->log_timestamp ), true );
				$date = $wgLang->date( wfTimestamp( TS_MW, $row->log_timestamp ), true );
				$time = $wgLang->time( wfTimestamp( TS_MW, $row->log_timestamp ), true );
				$userLink = Linker::userLink( $row->log_user, $row->user_name );
				$additionalInfo .= ', ' . wfMessage(
					'approvedrevs-approvedby',
					$userLink,
					$timestamp,
					$row->user_name,
					$date,
					$time
				)->text();
			}

			return "$pageLink ($additionalInfo)";
		}
	}

plus you can slightly change your approveAllPages.php file to create file that will approve only redirects.

approveAllRedirects.php: ↓
<?php

// Allow people to have different layouts.
if ( ! isset( $IP ) ) {
	$IP = __DIR__ . '/../../../';
	if ( getenv("MW_INSTALL_ROOT") ) {
		$IP = getenv("MW_INSTALL_ROOT");
	}
}

require_once( "$IP/maintenance/Maintenance.php" );

class ApproveAllRedirects extends Maintenance {

	public function __construct() {
		parent::__construct();

		$this->mDescription = "Approve the current revision of all redirect pages " .
			"that do not yet have an approved revision.";
	}

	public function execute() {
		global $wgTitle;
		global $wgEnotifWatchlist;

		// Don't send out any notifications about people's watch lists.
		$wgEnotifWatchlist = false;

		$dbr = wfGetDB( DB_SLAVE );

		$pages = $dbr->select(
			'page',
			array(
				'page_id',
				'page_latest'
			)
		);

		while ( $page = $pages->fetchObject() ) {
			$title = Title::newFromID( $page->page_id );
			// some extensions, like Semantic Forms, need $wgTitle
			// set as well
			$wgTitle = $title;
			if ( ApprovedRevs::pageIsApprovable( $title ) &&
				$title->isRedirect() &&
				! ApprovedRevs::hasApprovedRevision( $title ) ) {
				ApprovedRevs::setApprovedRevID(
					$title, $page->page_latest, true
				);

				$this->output( wfTimestamp( TS_DB ) .
					' Approved the last revision of page "' .
					$title->getFullText() . "\".\n" );
			}
		}


		$this->output( "\n Finished setting all current " .
			"revisions to approved. \n" );
	}

}

$maintClass = "ApproveAllRedirects";
require_once( DO_MAINTENANCE );

217.108.170.8 09:38, 16 February 2017 (UTC)

This is interesting. Why do you want special handling for redirects - do you have a lot of them? Yaron Koren (talk) 14:34, 16 February 2017 (UTC)
@Yaron_Koren:Yeah, lots of people here creating many pages and links them to each other. And I don't want to loose that links. but our company has rules for some page names and lots of times I have to move pages. But even if you have just some small amount of redirects, to approve one you need to open special page->tap on name->tap on name of page you were redirected from->.... lots of actions. and if you have link to approve redirects right in list its very convenient and time saving :). You could make that thing optional and it won't bother someone who don't need that functionality. 217.108.170.8 08:17, 17 February 2017 (UTC)
Ah, okay. Why do you need redirect pages approved in the first place - do you have the "blank if unapproved" setting turned on? Yaron Koren (talk) 15:48, 17 February 2017 (UTC)
@Yaron_Koren: I need redirect handling because all pages here must be approved as fast as possible. All technical information needs to be double checked before usage. Thats why our technical experts must not loose time checking and approving redirects. We often use special page to check info about new unapproved and changed pages. Yeah, I know, this situation s very special, but IMO redirect pages must be somehow highlighted in list. No harm from that - thats for sure :) 217.108.170.8 07:29, 28 February 2017 (UTC)
Every additional feature does have a cost in terms of greater complexity of the software. Of course, many features are worth that extra cost. I'm still wondering, though, why you need redirects to be approved. What happens with redirects that are not approved - do they not work? Or are you just trying to keep that "List of unapproved pages" as short as possible? Yaron Koren (talk) 16:36, 28 February 2017 (UTC)
@Yaron_Koren: Trying to keep that "List of unapproved pages" as short as possible - exactly my situation. I just want to see there pages that really need to be checked.
Another way is to simple hide redirects from special page by adding few code lines below. Easy as pie and fully user controllable
function formatResult( $skin, $result ) {
		$title = Title::newFromId( $result->id );

		if( !ApprovedRevs::pageIsApprovable( $title ) ) {
			return false;
		}

		global $egApprovedRevsHideRedirects;
		if ( $title->isRedirect() && $egApprovedRevsHideRedirects) {
			return false;
		}
.........
217.108.170.8 10:56, 6 March 2017 (UTC)

Right, that would work. I'm still thinking about this issue. It's not clear to me that redirect pages should get treatment entirely different from any other page. Redirects can contain bad content just like any other page. What if someone creates a good page on some topic, then someone else overwrites all that content and replaces it with a redirect? The setup you're describing would either ignore that page, or automatically approve it, or both.

As you note, it's harder to approve pages that are redirects, because when you click on them they redirect away. This may sound like not enough, but what if Special:ApprovedRevs just added a "?redirect=no" to the link to every redirect page, so that the page didn't redirect? Then approving those pages would not be harder than approving any other page. Yaron Koren (talk) 14:07, 7 March 2017 (UTC)

@Yaron_Koren: So adding ?redirect=no to all pages in list + some sign to page lines with redirect looks most painless and useful way to me :) 217.108.170.8 09:33, 10 March 2017 (UTC)

*Phew* That's great that you think this would be enough of a solution for you. I'll add this in soon. Yaron Koren (talk) 14:26, 10 March 2017 (UTC)
@Yaron_Koren: already done by myself ;) Just proposing solutions that could be useful for someone else 217.108.170.8 14:37, 10 March 2017 (UTC)
Okay, I just checked in this change to redirect pages' display - and also set their names to be shown in italics. Hopefully this is a good enough solution... let me know if you think more should be done. Yaron Koren (talk) 18:01, 13 March 2017 (UTC)

How to get $egApprovedRevsAutomaticApprovals to also work for bots API edits

In my scenario I have a bot periodically writing a lot of pages. We need to have these pages automatically approved OR excluded from the entire process. I would have thought that since the bot making these changes inherits approve permissions from its user, settting $egApprovedRevsAutomaticApprovals to true would solve our issues; unfortunately it does not.

Does anybody have experience with a similar situation or suggestions how to solve this?

Midgethoen (talk) 10:25, 14 March 2017 (UTC) I might be wrong assuming that bots inherit permissions from the person creating them, so I testen by letting the script create pages as a real user, this yields the same results: so it seems to be related to API edits
I tried to reproduce this, but unfortunately the script I'm using to try to edit pages is not working, for some reason. On the wiki, do the edits you make via the API script show up just like edits made via the web interface? Or is there some difference between them, like that these edits show up as minor or bot edits or something else? Yaron Koren (talk) 01:21, 17 March 2017 (UTC)
@Yaron Koren, No, from the history page I can not make a distinction between an API edit or a manual edit.. Midgethoen (talk) 10:02, 20 March 2017 (UTC)
We created an API that our bots can use to auto-approve pages. Yaron, if you are interested in reviewing, I can add a task in Phabricator. --Jlemley (talk) 20:18, 29 December 2017 (UTC)
I don't fully understand what you created, but sure. Yaron Koren (talk) 19:59, 1 January 2018 (UTC)

$egApprovedRevsShowNotApprovedMessage = true;

This setting don't change anything. I include this setting (true) to LocalSettings.php, but message on top page don't appear - sysop, regular user too.

I can't reproduce that problem. Maybe the page(s) just need to be refreshed? Try adding "?action=purge" to the URL. Yaron Koren (talk) 00:50, 22 June 2017 (UTC)

Call to undefined method WikiPage::prepareTextForEdit()

prepareTextForEdit was removed with MediaWiki 1.29 (deprecated since 1.21).

When you submit a form, following error is displayed :
Error from line 77 of /srv/wiki/extensions/ApprovedRevs/ApprovedRevs.hooks.php: Call to undefined method WikiPage::prepareTextForEdit()

In ApprovedRevs.hooks.php, you have to change :
77: $editInfo = $page->prepareTextForEdit( $text );
with
77: $editInfo = $page->prepareContentForEdit( new WikitextContent( $text ));

Hope that's help (newbie in php, but test it and it works;)) -- Flo

Great, thank you! I just added in this change. Yaron Koren (talk) 13:55, 17 August 2017 (UTC)

$egApprovedRevsBlankIfUnapproved = true

Hi there,

Flo again ;) I have an error on unapproved pages when I want to display it :

[2df1883b9255c38d05e92d91] /index.php/my_page Error from line 602 of /srv/wiki/includes/page/Article.php: Call to a member function getRedirectTarget() on string

Backtrace: 

#0 /srv/wiki/includes/actions/ViewAction.php(68): Article->view()
#1 /srv/wiki/includes/MediaWiki.php(499): ViewAction->show()
#2 /srv/wiki/includes/MediaWiki.php(293): MediaWiki->performAction(Article, Title)
#3 /srv/wiki/includes/MediaWiki.php(862): MediaWiki->performRequest()
#4 /srv/wiki/includes/MediaWiki.php(523): MediaWiki->main()
#5 /srv/wiki/index.php(43): MediaWiki->run()
#6 {main}

When I comment $egApprovedRevsBlankIfUnapproved, everything works fine but I need to approve a page before display it ;) Can you help me ?

Thank you ! (Mediawiki 1.29)

Sorry about that. I checked in a fix for either this or a similar bug, in April - see here. Do you have this change in your code? Yaron Koren (talk) 17:16, 24 August 2017 (UTC)
Hi Yaron, your fix works like a charm. Just change $contentObject to $content according to your fix, no more errors ! Thank you very much for your awesome work !

Pages that should not been approved / approved by

Hello! I have two questions:

1. I have some pages (Mainpage) in the MAIN namespace that should not been approved and also no text should be displayed. Is there any possibility to exclude these pages maybe with a magic word like __NOAPPROVAL__?

2. Is there a possibilty to diplay in the message (subtitle) when the page hase been approved and who did the approval (if approved)?

Thank you in advance

  • I think the answer to both questions is "no", unfortunately. A "__NOAPPROVAL__" magic word sounds like a good idea - for some reason no one has requested that before, I think. The second one I'm less sure about - it's a bigger deal, since it would mean changing the UI. You can already see the whole approval history for a page by clicking on the History tab, then clicking on "View logs for this page" at the top. I admit that's obscure. But maybe it's good enough, for the (I think) small percentage of users who would want to know about approvals? Yaron Koren (talk) 13:19, 13 October 2017 (UTC)
  • I would also be very happy to have a "__NOAPPROVAL__" magic word!! --95.91.234.205 08:24, 24 November 2017 (UTC)

Eliminate necessity to approve a page

I got the case that someone did approve a page in our wiki (we don't use ApprovedRevisions so far) and now other people that are also entitled to edit that page are unable to do so and have their edits shown. How can I get rid of that approved stuff without uninstalling the addon (as I cant get our team in charge to do so). It is probably simple as hell, but right now I cant figure it out. Ciannicay (talk) 15:38, 4 December 2017 (UTC)

Someone with admin privilege just needs to go to the history page for that page, find the "unapprove" link and click on it. Yaron Koren (talk) 17:14, 4 December 2017 (UTC)
Retrieved from "https://www.mediawiki.org/w/index.php?title=Extension_talk:Approved_Revs/Archive_2016_to_2017&oldid=2895383"