Extension talk:Approved Revs

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)

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)

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)