Extension talk:Approved Revs/Archive 2010 to 2012

Not working correctly with MW 1.13.4

Approved Revs is not working correctly with MW 1.13.4. Althought the (approve) link displays on the history page, when clicked it does not actually approve the page revision.

I made sure that this was on a revision after Approved Revs was installed.

Thanks for the help in advance. --Dgennaro 16:47, 25 August 2010 (UTC)

Hi - that's too bad; sorry about that. I'm never sure about the MediaWiki version compatibility for different extensions. I just changed the requirement to 1.14 - I'm on firmer ground with that one, I think. Yaron Koren 18:13, 25 August 2010 (UTC)

I can confirm it works with 1.15.4. --Dgennaro 19:52, 25 August 2010 (UTC)

approveAllPages.php

• It did not run correctly. I was attempting to run the maintenance script for Approved Revs and nothing happened. From what I can tell, it did not run...or it just ended right away. Nothing printed. --Dgennaro 16:41, 27 August 2010 (UTC)

• For me it is not working either, it requires Maintanance.php script, which not exists :(

What version of MediaWiki are you using? Yaron Koren 15:15, 22 July 2011 (UTC)

• I'm runnning 1:17, and I get the message that the Class ApprovedRevs is missing. Mwmoron 13:58, 31 January 2012 (UTC)

Do you have Approved Revs installed, in LocalSettings.php? Yaron Koren 14:13, 31 January 2012 (UTC)

Sort of, it's enabled in the SemanticBundleSettings.php, and i am able to manually approve pages.

"PHP Fatal error: Class 'ApprovedRevs' not found in extensions/ApprovedRevs/maintenance/approveAllPages.php on line 58"

Changes since approval

Is there a way to list all pages that have changes since their last approval? - that is, the results of this query:

SELECT *
FROM approved_revs
INNER JOIN page ON approved_revs.page_id = page.page_id
WHERE page_latest > rev_id

The idea would be to use this special page to be able to click on each page with outstanding approvals, immediately see the diff between the two pages and choose to approve or not. -- Philip 09:43, 2 November 2010 (UTC)

This is now available as a list within the 'ApprovedRevs' special page, as of version 0.5. Yaron Koren 02:51, 18 November 2010 (UTC)

Inline query for articles with an approved current revision

Is there a way to do an inline query to return a list of pages whose latest/current revision is 'approved'? (and leave out any pages which have no approved revision or whose current revision is not approved)

No - Approved Revs doesn't support inline queries. But you can get that same information by going to the page Special:ApprovedRevs. Yaron Koren 00:48, 23 January 2011 (UTC)

$egApprovedRevsBlankIfUnapproved

setting it to true it will set category pages as unapproved pages too. And if you set $egApprovedRevsNamespaces[] = NS_CATEGORY to fix this problem it will cause some other problems. Newuser1389 08:39, 19 February 2011 (UTC)

I believe that problem was fixed in the latest version, 0.5.5 - are you using that one? Yaron Koren 18:42, 20 February 2011 (UTC)

Sorry,you're right.Now I'm using the last version. Thank you.--Newuser1389 09:14, 24 February 2011 (UTC)

Conflict with ConfrimEdit extension

Have you installed both of confirmedit and approved_reves together? It seems they conflict with each other. Thanks for your attention.--Newuser1389 07:11, 7 March 2011 (UTC)

They're both working together on discoursedb.org... what's the problem you're seeing? Yaron Koren 15:30, 7 March 2011 (UTC)

Version: MediWikiVersion:1.16.0 , PHP: 5.2.9-2. On confirm page, the content appears 6 times.--Newuser1389 08:30, 8 March 2011 (UTC)

Hi - I see the issue, and I think I know how it can be fixed. In your LocalSettings.php, is Approved Revs included before ConfirmEdit? If so, please move it to anywhere after ConfirmEdit, and let me know if that fixed the problem. Yaron Koren 04:58, 9 March 2011 (UTC)

Hi. I installed MediaWiki 1.16.2 and Approved Revs inclusion placed after ConfirmEdit. But the problem stayed the same. --Newuser1389 08:00, 9 March 2011 (UTC)

Indeed, I was too optimistic. But I just checked in some code to Approved Revs that I think does fix the issue. If you're getting the code from SVN, could you update, and see if the problem goes away? Thanks. Yaron Koren 22:51, 11 March 2011 (UTC)

Yes. The problem was fixed. Thanks a lot.-- 06:15, 12 March 2011 (UTC)

Cool, that's good to hear! I just released a new version, 0.5.7, containing the fix. Yaron Koren 20:15, 14 March 2011 (UTC)

Special:ApprovedRevs page

Should the special page show up in my Special:SpecialPages list? I don't see it. Right now I have to type in the URL for Special:ApprovedRevs. Otherwise the extension seems to be running fine on my WinXP/XAMPP/MW1.16.2 test server. ~ 05:35, 9 March 2011 (UTC)

I see it there, as "Approved revisions" in the "Lists of pages" section. If you still don't see it, what version of Approved Revs are you running? Yaron Koren 20:52, 9 March 2011 (UTC)

• Very excellent. I found it. Had it turned off in the wrong security section of my file. Just knowing it should be there helped me fix it. Thanks! 22:07, 9 March 2011 (UTC)

Conflict with Admin Links?

Going to Special:AdminLinks page I get the following error at the top of the page:
Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method ApprovedRevsHooks::addToAdminLinks() should not be called statically in D:\xampp\htdocs\riftwiki\includes\Hooks.php on line 133
Is this an Approved Revs issue or an Admin Links issue? If I disable Approved Revs the Admin Links page works fine which leads me to Approved Revs as the culprit. 17:49, 9 March 2011 (UTC)

Yes, indeed - you've found a bug in Approved Revs when using PHP with "strict standards". This will be fixed in the next version, but for now you can fix it in your code by just replacing "function" with "static function" around line 511 of ApproveRevs.hooks.php. Yaron Koren 20:41, 9 March 2011 (UTC)

• Made the patch. Fixed it right up. Excellent work. Thanks! 22:07, 9 March 2011 (UTC)

How to configure not to prevent search engines bots

Excuse me about my bad English. Approve Revs by default prevents bots to index the wiki. Is there a way to allow search engines to crawl the wiki? 06:26, 10 March 2011 (UTC)

I don't think so - what users see is what search engines see. Yaron Koren 15:35, 10 March 2011 (UTC)

I see in wiki html code this tag : <meta name="robots" content="noindex,nofollow" />. And I think it is added by Approved Revs.-- 16:19, 10 March 2011 (UTC)

No, it's not. Yaron Koren 18:13, 10 March 2011 (UTC)

Thanks for such a good, helpful and optimized extension.-- 22:17, 10 March 2011 (UTC)

Hi. Excuse me but I think this problem exists,I correct my question and ask it again. Mediawiki prevents bots to index revisions of pages. And when we use ApprovedRevs, mediawiki prevents bots to index revisions even the approved revision. When there is no revision as approved, MW do not add meta tag. Is my guess true ?-- 06:46, 13 April 2011 (UTC)

Indeed, you were right! Thanks for the clarification. I just checked in what I think is a fix for this problem in SVN - if you're using SVN, feel free to update, and see if it works for you. Yaron Koren 18:31, 13 April 2011 (UTC)

Thank you very very much.-- 18:10, 14 April 2011 (UTC)

On my MW-1.15, this is still a problem. As a test, I added an "echo" to the line right after the "setRobotPolicy('index,follow')" in removeRobotsTag() and it does get called. But the meta-tag isn't removed. Im new to MW's internals and cant figure out why this doesnt work. Any suggestions on how to debug further? -- 10:30, 11 October 2011 (UTC)

Allright.. I debugged a lot and found that, at least for mw1.15, the "PersonalUrls" hook is a bit too early for the setRobotPolicy() and the policy will be overidden in Article.php, once it discovers that there is an "oldid" (which is also set, if the revision isnt the newest version). The "right" place for me, is the "DisplayOldSubtitle" hook. Thus adding:

               $title = $article->getTitle();
               ApprovedRevsHooks::removeRobotsTag( &$title, &$title );

to beginning of setSubtitle(), which is in the ApprovedRevs.hooks.php document, fixes this for me. My second problem was that new pages, though shown as blank if unapproved, does NOT contain noindex,nofollow. I've fixed this by adding

               global $wgOut;
               $wgOut->setRobotPolicy( 'noindex,nofollow' );

right before the last "return true" in showBlankIfUnapproved(). I hope this is useful to anyone -- 09:37, 19 October 2011 (UTC)

SMW shows semantic properties of latest (non-approved) version?

From the main page of this extension, I understand that with this extension installed Semantic MediaWiki queries should only consider properties of the approved version of a page. ("Extensions that get specific data from pages, however, such as Semantic MediaWiki and DPL, will, fortunately, display the correct (i.e., approved) data.")

However, the behavior I see is different: {{#ask: ...}} queries as well as the Special:Ask page retrieve results based on the latest, non-approved version of the page. Is the behavior I see erratic, or did I misinterpret the information on the main page?

Rcdeboer 22:34, 23 March 2011 (UTC)

No - you interpreted it correctly. What versions of MW, SMW and AR are you using? Yaron Koren 23:03, 23 March 2011 (UTC)

I'm using MW1.15.4 with Semantic Bundle 0.5.20101125 (SMW1.5.4, AR0.5.2). I've also tried the latest version of ApprovedRevs (0.5.7) without success. Rcdeboer 23:20, 23 March 2011 (UTC)

I just tried it again, and it works fine for me - I'm using MW 1.16.2 and SMW 1.5.6. I don't know if either of those are the issue, but I'd say it's a good idea to upgrade in any case... beyond that, I have no idea why it's failing for you. Yaron Koren 01:05, 24 March 2011 (UTC)

I found the problem. I have set $egApprovedRevsAutomaticApprovals to false. Things work fine if I edit as a normal user without approval rights. I changed the following lines in ApprovedRev.hooks.php. This seems to fix my problem. Rcdeboer 19:26, 28 March 2011 (UTC)

from

if ( $title->userCan( 'approverevisions' ) {
	return true;
}

to

global $egApprovedRevsAutomaticApprovals;
if ( $title->userCan( 'approverevisions' ) && $egApprovedRevsAutomaticApprovals) {
	return true;
}

Oh... oops, that's a bug - and your fix makes sense. Thank you! Yaron Koren 21:55, 28 March 2011 (UTC)

Script does not work with CharInsert

I installed Approved Revs, but CharInsert panel is gone. How I can return the panel? Please, help. THX Oktano 21:56, 30 March 2011 (UTC)

I have found the reason of the problem. I have removed a string $wgHooks['ParserBeforeTidy'][] = 'ApprovedRevsHooks::handleMagicWords'; from the ApprovedRevs.php. The CharInsert panel has returned. Is it correct or not? I use MediaWiki 1.16.2. Sorry for my bad English. Oktano 21:40, 13 April 2011 (UTC)

Hi - I just tried installing CharInsert myself, and for me the two extensions work fine together - which makes it hard to debug. Your solution, unfortunately, disables part of Approved Revs' functionality, so it's not something I can add. Are you using the latest versions of both Approved Revs and CharInsert? Yaron Koren 14:35, 14 April 2011 (UTC)

Yaron, thx for your reply. On the local server I use Denwer, panel CharInsert with Approved Revs does not work. After that I tried to run modules Approved Revs and CharInsert on a server on the Internet, both modules are working well. It is my mistake, sorry for the trouble. Oktano 01:29, 15 April 2011 (UTC)

Okay, that's good news. Yaron Koren 02:19, 15 April 2011 (UTC)

Still under Approved Revs control when actually not.

Ill first provide the reproduction and then explain

1. Edit a page under Approved Revs control (preferably a namespace other than main for ease of use)
2. Mark that page as "Approved"
3. Remove the Namespace from Approved Revs control
4. edit the page again and save
5. run index.php?title=Special:ApprovedRevs&show=notlatest

Your page should show up here, this makes sense as the page has been edited and now has a new revision that is not approved but as its no longer under Approved Revs control you cannot bring it forward.

You can resolve this by moving the namespace back under Approved Revs control, go mark the page approved version as "unapproved" which will make the most current rev the current page and then remove that namespace from Approved Revs control again.

__APPROVEDREVS__ not displaying on Special:ApprovedRevs

Pages marked with the magic word __APPROVEDREVS__ via a template are not currently displaying on Special:ApprovedRevs. --Dgennaro 20:30, 25 April 2011 (UTC)

Is there any update on the issue above? --Dgennaro 17:21, 16 May 2011 (UTC)

Hi, sorry I forgot about this - thanks for the reminder. I think I just fixed the problem in SVN - if you test it out, please let me know if the fix worked. Yaron Koren 01:37, 17 May 2011 (UTC)

approveAllPages.php whines about the parser

If you run approveAllPages.php in 1.17, it will throw notices:
Notice: Undefined variable: parser in /path/to/wiki/extensions/ApprovedRevs/ApprovedRevs_body.php on line 182
It appears to otherwise work fine. —Emufarmers^(T|C) 00:24, 29 June 2011 (UTC)

Oh, indeed - I'm amazed that this didn't get called earlier, because I don't think the problem is new to MW 1.17. I believe I just fixed this now, in SVN. Yaron Koren 04:52, 29 June 2011 (UTC)

Detect if page is approved

Hello,

is there any way to detect a page/revision is marked as approved or not (in order to show one content or other with a set of templates and parser functions)? Thanks! --Toniher 12:38, 2 July 2011 (UTC)

Hi - detect from where - another page? Or the same page? Or elsewhere? Yaron Koren 02:58, 3 July 2011 (UTC)

Actually, from the same page. --Toniher 21:18, 3 July 2011 (UTC)

That can't be done, no. Yaron Koren 02:05, 4 July 2011 (UTC)

Is it compatible with version 1.17.0

Hi I installed this extension on the version 1.17 but it seems its not working as Im not able to see approve link in my history page?? --Harshadachavan 08:48, 17 August 2011 (UTC)harshadachavan

Yeah, it works with MW 1.17 (and higher). Maybe you just lack the permission for it? Are you logged in as an administrator? Yaron Koren 15:09, 17 August 2011 (UTC)

Hey thanks got it to work some how maybe some permission errors only thanks for the reply though --Harshadachavan 08:09, 24 November 2011 (UTC)

Possible to move the approved and latest message to the bottom?

Hi.

Great extension :) Is it possible to move the approved and latest message to the bottom of the screen?

Thanks! --Mitchelln 16:43, 14 September 2011 (UTC)

That's an interesting question - Approved Revs puts its messages in the "subtitle" field, which it's up to the skin to decide where to place it on the page. (Though I think all skins put it at the top.) You could modify the skin to move it to the bottom of the page - what do you think of that solution? Yaron Koren 18:43, 14 September 2011 (UTC)

Hi. Thanks for getting back to me so quickly :) Yes, modifying the skin is probably the best way to do this now I know which field to change. I'll let you know how I get on!

--Mitchelln 09:16, 15 September 2011 (UTC)

Well, that was easy enough! Just searched for

<div id="contentSub"><?php $this->html('subtitle') ?></div> 

in the skin PHP and moved it to the bottom of the content :)

--Mitchelln 09:20, 15 September 2011 (UTC)

Please explain installation more clearly to novices

• I have tried to execute the database php file, but how is this done before adding the line to LocalSettings.php.
• How exactly can I run the ApproveAll script, if the maintenance shell does not list it, as it is not within its folder?

Hi - if you're running update.php, you need to run it after Approved Revs is included. That means that there will be a brief period of time when the wiki is out of commission, because the DB table doesn't exist yet. And the "/maintenance" folder in question is not the main MediaWiki one, but rather the one in the "ApprovedRevs" folder - the documentation should probably be clearer about that. Yaron Koren 07:26, 2 October 2011 (UTC)

I thought that this page was on my watchlist -- I did not get a notice that you replied. For the novices, could you explain how to properly run the script? Should I use the Maintenance Sheel extension, or use SSH? MKRD info 14:36, 16 October 2011 (UTC)

• Hi, great extension, but again, for the novice, could you explain what you mean by running a the ApproveAll script 'from the command line'?

See here. Does that clarify it? Yaron Koren 19:22, 7 November 2011 (UTC)

• Excited to be using this soon. Thanks for your hard work. I've managed to install semanticbundle, but I am stuck on this step. how do you run the ApproveAllPages.php script from the command line? All I (think) i know so far is that it involves Terminal and the web address that the script is at. What do I type into terminal please? Jenny Gristock (talk) 17:09, 7 December 2012 (UTC)

Is it this procedure here? Manual:Update.php ?Jenny Gristock (talk) 17:30, 7 December 2012 (UTC)

No - update.php is called in order to create the database table that Approved Revs uses. approveAllPages.php does the automatic approvals - it uses that DB table that update.php creates. The two are in different directories. Both are called in the same way, though - you go to that script's directory (from the terminal), and type "php update.php" or "php approveAllPages.php". Yaron Koren (talk) 21:00, 7 December 2012 (UTC)

Why is an edited page still showing as approved

Perhaps I am missing the point here, but I have page that I have approved, and that works fine.

If I then edit that page, is still shows as approved. Shouldn't the most revent edit be Unapproved ?

I'm assuming you're an administrator - if you have the right to approve pages, then all your edits are automatically approved. Yaron Koren 14:14, 13 October 2011 (UTC)

Database prefix

Just a minor note to keep in mind: if your MW installation uses a custom database prefix, then running the sql update script will create a table without that prefix, and your wiki installation will still be offline. If that happens, go into phpMyAdmin, click on the table, and then rename it from the page that appears.

Watchlist emails not working

Hi there Firstly, thanks for the extension (and your various other contributions to MediaWiki). I'm having some trouble with getting our installation to send out emails notifying that a watch page has been changed. I have two installations of MediaWiki, one with Approved Revs and one without. The one without sends an email out no problem, but the one with it installed doesn't. This is for both approved and unapproved changes to the page. Weirdly, the only time an email has been sent out was when running the 'approve all' PHP script on the database. Any ideas?

I have the following set in my LocalSettings.php file:

require_once( "$IP/extensions/ApprovedRevs/ApprovedRevs.php");
	$wgGroupPermissions['sysop']['viewlinktolatest'] = true;
	$wgGroupPermissions['*']['viewlinktolatest'] = false;
	$egApprovedRevsBlankIfUnapproved = true;

I should also point out that email correspondence such as forgotten passwords, new user setup etc do work correctly, it's just the watchlist notification.

Thanks! Csf90 09:28, 2 November 2011 (UTC)

Hi - two questions: for pages that don't have an approved revision at all (like, say, category pages), does watchlist emailing work? And if not, could you try temporarily disabling the extension, and see if that causes watchlist emailing to work? Yaron Koren 12:10, 2 November 2011 (UTC)

Thanks for your reply. Indeed, watchlist emailing doesn't work even on category pages. Disabling the extension (commenting it out) throws up 500 Internal Server Error on all pages. Is this to do with the fact there's a new table? I remember a similar error message when I installed the extension and hadn't yet created the new table, might be related? Csf90 14:17, 2 November 2011 (UTC)

That's very strange. No, the fact that there's an unused DB table there shouldn't be causing any problems. I can't think of any reason why that would happen. Perhaps you're accidentally commenting something else out too? Yaron Koren 14:23, 2 November 2011 (UTC)

Tried again, commenting with // on each line rather than /* at the start (it's at the bottom of my LocalSettings.php) and stopped getting the error. And disabling the extension still didn't work, so I guess it's not an issue with this extension. Sorry! I just assumed it may have been because we got the watchlist email when running the 'approve all' script. Still, I don't suppose you have any ideas? Thanks for your responses anyway. Csf90 14:33, 2 November 2011 (UTC)

Maybe watchlist emailing isn't enabled on that wiki? It could be that the emailing that Approved Revs did was being done accidentally. Other than that, I have no idea. Yaron Koren 21:03, 2 November 2011 (UTC)

Problem solved! It was enabled on the MW, however the $wgEmergencyContact variable wasn't set to an email address, just a string. Setting it to an email address format (even though the email address doesn't actually exist) and it sends through fine. Which is weird. Thanks for your suggestions! Csf90 11:27, 3 November 2011 (UTC)

is it compatible with oracle

Hello, This extension will work with oracle or not? thanks

I think so, but I don't know. Yaron Koren 02:43, 13 January 2012 (UTC)

Unapproved revisions appear in search results

Hi - thank you very much for this great extension. It`s exactly what we searched for, but I have got a problem with the search results. I try to explain the problem with an example:

• A user (without 'approverevisions'-rights) searches for a term that only appears in an unapproved revision of a page.
• He gets a page as result and also a preview of the text, which contains the term he searched for.
• But when he opens the page the approved revision of the page shows up and it doesen`t contain the term he searched for.

I don`t know if I get something wrong, but I think this behavior could be rather confusing for a user. Is there a possibilty to exculde unapproved revisions from the search? Thank you very much! prewin12 17:03, 1 February 2012 (UTC)

Oh, I never thought to try to modify the search behavior - that makes sense, and hopefully it's possible. I'll look into it. Yaron Koren 19:36, 1 February 2012 (UTC)

Thanks for the quick reply and your help! prewin12 10:29, 2 February 2012 (UTC)

Possible to display a message on pages awaiting approval?

Hi, is it possible to place a message on the 'blank' screen if you set the following - $egApprovedRevsBlankIfUnapproved = true;

I'm using 'Create Article' and 'Category Tree' to simplify the process for users to add new content, however, once they submit and article (which we want to approve before it goes live) we just see the article title in the list, and a blank article. For those articles awaiting initial approval is there a way we can redirect to another page, or add a message saying the content is awaiting approval?

--Astraben21 (talk) 17:00, 22 February 2012 (UTC)

There's already a message, at the top of the page - "No revision has been approved for this page. View the most recent revision." Do you not see that on your wiki? Or do you want something bigger? Yaron Koren (talk) 01:19, 23 February 2012 (UTC)

Something like a message to the person who just edited the page saying that their reversion is waiting to be approved would be nice

Oh, I see. That's not possible currently, but it's a good idea. Yaron Koren (talk) 13:58, 27 February 2012 (UTC)

I imagine it is down to the way we have the site configured, but when the page is brand new, there is nothing displayed on the page, unless you are logged in as an administrator, where it then says "No revision has been approved for this page. View the most recent revision." The scenario we are trying to create is for users to submit articles, then for us to be able to check the content before being made public. We don't want general users to be able to see the content until it has been approved, hence locking it right down. I know this sort of moderation goes against general wiki rules, but because the end product will be public content representing our company, we must ensure it is clean, accurate content first.--Astraben21 (talk) 14:40, 27 February 2012 (UTC)

Hi Yaron.
I second Astraben's suggestion: It would be really helpful if a user gets a message saying his edit needs to be approved first before it goes live (I think FlaggedRevs is doing it this way too).
Also, as I understand from the documentation a message should be shown (to everyone) if there are unapproved changes of an article and they thus see an older version of the article. At my wiki (1.19.2) none of the users (admins, users, anons) sees this message... Where and when should this message be shown? I'm using the default configuration of ApprovedRevs. Is there maybe an issue with version 1.19.2?
Thanks for your help!
--Stefahn (talk) 22:14, 5 October 2012 (UTC)

Hi Stefahn - by "get" a message, do you mean see a message on the screen, or get an email? As for not seeing a message - are you sure the pages in question are being handled by Approved Revs? If they are, there should always be a message at the top of the screen - and it should work with MW 1.19. Are you using the latest Approved Revs version? Yaron Koren (talk) 22:24, 5 October 2012 (UTC)

Hi Yaron, "get a message" = message on the screen. I use the latest ApprovedRevs (0.6.3). You can see an approved article here - it has an edit which is not approved yet but there is no message shown: http://mw.stefahn.alfahosting.org/wiki/Approved. What works: it shows the approved version to the reader. The article was created before I installed ApprovedRevs but as I understand this should not matter. Thanks for your help! --Stefahn (talk) 14:30, 9 October 2012 (UTC)

Hi - ah, it's very helpful to see the page in question. You have another extension setting a subtitle for the page - it looks like it's BreadCrumbs2. Could it be that that extension is overwriting Approved Revs' message? It could be that even including them in the reverse order would fix the problem. Yaron Koren (talk) 15:54, 9 October 2012 (UTC)

Thought about this before - and it really causes the issue. I disabled BreadCrumbs2 and the Approved message appears - but only if I'm logged in as an user or as sysop. Anons still don't see the message - although they should since I didn't touch viewlinktolatest. I set $wgGroupPermissions['*']['viewlinktolatest'] = true; in LocalSettings explicitly but this didn't help either. Can you explain this?
BTW: I tried to include BreadCrumbs2 after ApprovedRevs but also in this case BreadCrumbs2 overwrites Approved Revs.
Thanks for your support! --Stefahn (talk) 17:26, 9 October 2012 (UTC)

That's very odd - I've never heard of that happening before. I assume 'viewlinktolatest' is somehow causing the issue - could it be that it's getting reset to something else, later in LocalSettings.php, or in another file? Yaron Koren (talk) 18:10, 9 October 2012 (UTC)

I guess I found out what causes the problem: It's the following line in LocalSettings.php: $wgEmailConfirmToEdit = true;. I have no idea why...
Apart from that: Would you think it's possible to show a message (on screen) to the contributor whose edit needs to be first approved? I mean there is this small message saying "This is the approved revision of this page; it is not the most recent. View the most recent revision." - but I'm afraid contributers will oversee it...
Thanks for your excellent support! --Stefahn (talk) 20:53, 9 October 2012 (UTC)

Changes visible before approval

Hi there,

I installed the extension and it seems to nearly work. But the main thing is not working. Users (not logged in) can see the created/edited page before I approve it with my administrator account. Pages are created with a normal user account, NOT the administrator.

How to fix this? Thanks for help!

You might need to set "$egApprovedRevsBlankIfUnapproved = true;" in LocalSettings.php. Yaron Koren (talk) 16:07, 13 April 2012 (UTC)

conflict with social profile

Have you installed both of Social Profile and approved_reves together? It seems they conflict with each other. please Advice.

still waiting any advice

I've never used the two together. What's the problem you're seeing? Yaron Koren (talk) 17:49, 10 June 2012 (UTC)

ApprovedRevs (0.6.1) in Mediawiki (1.19.0) cause editsection links to disappear

Hi. I was running a mediawiki 1.17 with ApprovedRevs and when I updated my mediawiki to 1.19 along with all the extensions that needed updating, I noticed that no editsection links would appear next to the headings of the pages. The editsection links appear if I visit a non approved page or if i disable ApprovedRevs. Otherwise i get no editsection links. -- harryT

I'm having this same problem... will submit it as a bug --Ashimema (talk) 10:59, 13 July 2012 (UTC)

Hi - does this happen for pages where the approved revision is the latest, or only ones where the approved is not the latest? If it's the latter, that's not a bug - MediaWiki does it that way on purpose, to avoid messing up the page. Yaron Koren (talk) 12:14, 13 July 2012 (UTC)

Yaron it happens for all pages where the approved revision is the also the latest one. -- harryT

Agree with harryT, I'm seeing this on all pages, not just those where the approved revision is not the current one. --Ashimema (talk) 13:08, 13 July 2012 (UTC)

Okay, now I see the issue. Yes, that's a bug - apparently it only happens for MediaWiki 1.19 and higher. I'll look into it. Yaron Koren (talk) 17:09, 13 July 2012 (UTC)

Does version 0.6.2 fix the issue that causes editsection links to disappear?--harryT 10:26, 16 September 2012 (UTC)

Hi - no, but this bug is fixed in the Git code, as of about a week ago; and I'm planning to release a version 0.6.3 soon, which will include the fix. Yaron Koren (talk) 20:44, 16 September 2012 (UTC)

Admins NEW pages not automatically approved.

For some reason, new pages created by myself (the sysop) are not automatically approved. I do have $wgGroupPermissions['sysop']['approverevisions'] = true; and $egApprovedRevsAutomaticApprovals = true; in my LocalSettings.php file. Any ideas?? --Zackmann08 (talk) 16:06, 16 July 2012 (UTC)

Yes - you need to set "$egApprovedRevsBlankIfUnapproved = true;" in LocalSettings.php for that to happen. This has caused a bunch of confusion, so it should probably be explained better in the documentation, but there are basically two modes: one where every page is automatically part of the approval system, and one where pages need to be manually added to the approval system by getting one of their revisions approved. The way to get the former is to add that "blank if unapproved" setting. There's no third mode, where an admin simply editing a page causes it to become part of the approval system; that's because I just thought that would lead to an arbitrary set of pages: why should page A have an approved revision, and page B not, just because a month ago an admin fixed a spelling error in page A? But if anyone disagrees with that thinking, I'd like to hear it. Yaron Koren (talk) 23:21, 16 July 2012 (UTC)

Protections not approved

One little bug you might want to address is that when an admin protects a page, that modifications isn't automatically approved. I definitely think it should be since only admins have this privileged anyway. --Zackmann08 (talk) 14:57, 17 July 2012 (UTC)

Sorry for the long delay in responding. Actually, the permission to protect pages, and to approve revisions, are two different permissions, and they're not both necessarily available to admins (though by default, they are). Anyway, isn't it possible that an admin would want to protect a page, while still keeping it at an earlier revision? Yaron Koren (talk) 16:27, 13 September 2012 (UTC)

Fatal error: Class 'DeferredUpdates' not found

• MW 1.16.x
• AR 0.6.1

Fatal error: Class 'DeferredUpdates' not found when page is approved.

To fix this, change line 229 in ApprovedRevs_body.php as follows:

// DeferredUpdates::addUpdate( new SearchUpdate( $title->getArticleId(), $title->getText(), $text ) );
$su = new SearchUpdate( $rev_id, $title->getText(), $text );
$su->doUpdate();

and line 185 in ApprovedRevs.hooks.php as follows:

// DeferredUpdates::addUpdate( new SearchUpdate( $article->getID(), $title->getText(), $approvedText ) );
$su = new SearchUpdate( $revisionID, $title->getText(), $approvedText );
$su->doUpdate();

Either code or required MW version should be fixed. --Planetenxin (talk) 07:27, 31 July 2012 (UTC)

Thanks for this patch, and sorry for not responding before. I added a fix similar to this to the code a few weeks ago, and it's now in version 0.6.2. Yaron Koren (talk) 16:22, 13 September 2012 (UTC)

Wrong page cached when saves made (1.19+)

I encountered what appears to be a bug when using ApprovedRevs in 1.19+.

When you save a page, the *APPROVED* page is the one that is cached for the current revision, instead of the current revision. This results in any attempt to view the current revision as seing the approved revision. Very confusing.

It appears this happens because of the behavior of ApprovedRevsHooks::setApprovedRevForParsing, since that function (erroneously, I believe) returns the approved revision text as the page save text (to make sure links and properties are saved).

Instead, removing that hook and replacing it with this appears to work:

	static public function doApprovedRevArticleEditUpdates( &$page, &$editInfo, $changed ) {
	       $title = $page->getTitle();
	       if ( ! ApprovedRevs::pageIsApprovable( $title ) ) {
	       	  return true;
	       }
	       // If this user's revisions get approved automatically,
	       // exit now, because this will become the approved
	       // revision anyway.
	       if ( self::userRevsApprovedAutomatically( $title ) ) {
	       	  return true;
	       }
	       $text = '';
	       $approvedText = ApprovedRevs::getApprovedContent( $title );
	       if ( !is_null( $approvedText ) ) {
	       	  $text = $approvedText;
	       }
	       // If there's no approved revision, and 'blank if
	       // unapproved' is set to true, set the text to blank.
	       if ( is_null( $approvedText ) ) {
	            global $egApprovedRevsBlankIfUnapproved;
		    if ( $egApprovedRevsBlankIfUnapproved ) {
		       $text = '';
		    }
	       }
	       $editinfo = $page->prepareTextForEdit($text);
	       $u = new LinksUpdate( $page->mTitle, $editinfo->output );
	       $u->doUpdate();

	       return true;
	}

Once that is added, you need to add the ArticleEditUpdates hook in ApprovedRevs.php:

$wgHooks['ArticleEditUpdates'][] = 'ApprovedRevsHooks::doApprovedRevArticleEditUpdates';

I haven't yet tested this thoroughly, but it appears to solve the problem, and also to handle links/properties updates in a better way.

Sorry for the long delay on this. I finally tested this out, and I couldn't see a problem. Assuming you're still reading this - can this be reproduced consistently, or does it only happen sometimes? Yaron Koren (talk) 01:00, 4 January 2013 (UTC)

I'm not the OP, but I've just started using this extension and I can consistently reproduce it on MW 1.19.2 with ApprovedRevs 0.6.4. My ApprovedRevs are set up to apply to just one namespace. If you create a page in this namespace, then approve that revision, the latest revision is the approved revision and everything works as expected. However, if you then create one or more unapproved revisions, the "latest revision" link always shows the approved revision instead of the latest revision. However, if you use the revision browsing links to move back one revision, then forward one, the correct revision is displayed. The problem doesn't seem to consistently happen when the latest approved revision isn't the first revision for the page. --66.162.23.2 17:43, 6 February 2013 (UTC)

The problem persists in MW 1.20.2. Also, further testing indicates that this seems to consistently occur; it doesn't matter if the latest approved revision is the first revision or not. A notable feature about my wiki is that I use PHP wincache (via $wgMainCacheType = CACHE_ACCEL) and the file cache; this bug may not replicate without those on. I also cache load.php through IIS's dynamic output cache, though I don't really see how that would have any effect. --66.162.23.2 23:13, 6 February 2013 (UTC)

Okay. If it's not too much work, could you try temporarily disabling wincache (I doubt the other caches are involved) and see if the problem still happens? Yaron Koren (talk) 23:20, 6 February 2013 (UTC)

Interestingly, the problem seems to persist even with $wgMainCacheType = CACHE_NONE. --66.162.23.2 16:20, 7 February 2013 (UTC)

Not working with MW 1.18

I've tried everything to make it so approvals are required on all the discussion tabs. But it's not working.

When a user makes an edit it displays automatically. Can you tell me what I'm doing wrong?

Here is the config in LocalSettings.php:

$wgGroupPermissions['*']['edit'] = false;

$egApprovedRevsBlankIfUnapproved = true;

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

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

$egApprovedRevsAutomaticApprovals = false;

$egApprovedRevsShowApproveLatest = true;

$egApprovedRevsNamespaces[] = NS_MAIN;

$egApprovedRevsNamespaces[] = NS_TALK;

$egApprovedRevsNamespaces[] = NS_USER_TALK;

$egApprovedRevsNamespaces[] = NS_TEMPLATE_TALK;

$egApprovedRevsNamespaces[] = NS_HELP_TALK;

$egApprovedRevsNamespaces[] = NS_PROJECT_TALK;

$egApprovedRevsNamespaces[] = NS_CATEGORY_TALK;

Does all of this stuff come after the inclusion of Approved Revs? Also, what version of Approved Revs are you using? Yaron Koren (talk) 13:51, 7 November 2012 (UTC)

Extension doen't work when $wgEmailConfirmToEdit=true

When $wgEmailConfirmToEdit is set to true, approved revs messages are not displayed. To be displayed, you have to login with an account which email has been confirmed, but it's quite embarrassing for non logged users. Also for admin account approve/unaprove links are not displayed if account email has not been approved.

I'll look into the first one. The second one sounds like the right behavior, though, no? As in, if you're not allowed to edit, you shouldn't be allowed to approve/unapprove? Yaron Koren (talk) 14:34, 3 December 2012 (UTC)

For the second one, it's not a right assignement issue, even if you are member of group which has rights to approve version, the links are not displayed until the account has been confirmed. In our case, it's quite embarassing because many accounts have been created before $wgEmailConfirToEdit was set to true. So in my case, even as a sysop, i had to send myself the mail with confirm link. I also think, it's possible that this case is more a global mediawiki issue.--Dsebastiao (talk) 15:05, 4 December 2012 (UTC)

Isn't it equally "embarrassing" to not be able to edit? I don't see what the difference is. Yaron Koren (talk) 15:51, 4 December 2012 (UTC)

Users are able to edit, even accounts created before the set of $wgEmailConfirToEdit to true (and so unconfirmed account).--Dsebastiao (talk) 16:08, 6 December 2012 (UTC)

I've manually confirm account of all approvers using ConfirmUsersEmail exension. Then they can approve/unapprove revisions but i still have the main issue : approve revision message which confirm if the version displayed has been approved is not displayed for non logged user and non confirm account (if $wgEmailConfirmToEdit=true).

To be able to have $wgEmailConfirmToEdit=true and still have approvedrevs messages displayed on the top i've removed in line 291 of ApprovedRevs.hooks.php

if ( ! $title->userCan( 'viewlinktolatest' ) ) {

return false;

}

I think now viewlinktolatest right in localsetting is useless now, but it's not a problem for me because it was set by default [*][viewlinktolatest]=true

--Dsebastiao (talk) 10:59, 7 December 2012 (UTC)

Thanks for that patch - I made a similar change to the code. (Though I didn't remove the 'viewlinktolatest' part.) Yaron Koren (talk) 06:26, 28 December 2012 (UTC)

Not logged users can see unapproved pages

The new pages created on the wiki show "blank" to admin (that is what is intended to happen, because there is not approved version).

However, those pages don't show blank to the other users, even with $egApprovedRevsBlankIfUnapproved = true;

If the page has some modification (it is not new) everything displays correct to all types of users, i mean, blank pages if no revision is approved or the latest approved version if there is one.

What versions of Approved Revs and MediaWiki are you using? Yaron Koren (talk) 16:30, 13 December 2012 (UTC)

DPL and Approved Revs?

Is there a chance that DPL could do queries on approved revisions? Now or in the future? Margaret

That's something you'd have to ask the DPL people. Yaron Koren (talk) 19:21, 13 December 2012 (UTC)

Patch still needed for version 1.19.3?

I just installed the extension and I'm using MediaWiki 1.19.3. As far as I can see everything works as expected even without the patch. Cormen (talk) 15:49, 30 December 2012 (UTC)

Section editing not possible if this extension is active

Running MediaWiki 1.19.3-1 and Approved Revs 0.6.1. If this extension is active the Section Editing links are missing. If I deactivate the extension they appear again. Cormen (talk) 16:46, 30 December 2012 (UTC)

Yes, that was a bug in older versions of Approved Revs - you should update your version, if possible. Yaron Koren (talk) 01:28, 31 December 2012 (UTC)