Extension talk:Approved Revs

'approve' > Deny_action
I get Deny_action -text when I try to approve a page. My user is sysop. How can I fix this?


 * What is "Deny_action"? I've never heard of it. Also, what versions of MediaWiki and Approved Revs are you using? Yaron Koren (talk) 19:18, 5 October 2015 (UTC)
 * When I click 'approve' on any change that has been made to Mediawiki article it takes me to page where it says: Deny_action. Mediawiki: 1.25.1, PHP 5.4.16 and MySQL 5.6.26.


 * Oh, okay. What version of Approved Revs are you using? Yaron Koren (talk) 13:50, 6 October 2015 (UTC)
 * Mediawiki 1.25.1 and ApprovedRevs 0.7.1


 * Do you have the Approved Revs DB table set up, by calling update.php? Yaron Koren (talk) 18:23, 7 October 2015 (UTC)
 * Yes there is approved_revs table.


 * Sorry for the extremely long delay. On the off chance that you're still watching this, someone else had this problem and the issue turned out to be the AccessControl extension - these two extensions don't seem to be able to work together. Yaron Koren (talk) 14:28, 19 July 2016 (UTC)

$egApprovedRevsShowNotApprovedMessage = true; not working
Hi, your extension is working great besides $egApprovedRevsShowNotApprovedMessage = true;, I add this to my LocalSetting.php and re-upload it but not dice! I login as a dummy user do some editing, save then no message pops up to notify me of the whole approval thing. The rest of the system is working fine, the edit wasn't put through and is awaiting admin approval. That is the purpose of this line to my knowledge. Please correct me if I am wrong. Any suggestions?
 * My bad it does indeed say that in the editing section, I assumed it would have said it after saving the edit, :3 sorry.

Autoapprove changes to templates or files
Hi, I really don't want to re-approve every page that has a template, when I change the template. Is there a way to disable this requirement or auto approve in these cases? Heinrich krebs (talk) 14:46, 22 January 2014 (UTC)


 * Hi - I don't know what you mean by that - what happens when you change a template used by a page with an approved revision? Yaron Koren (talk) 14:49, 22 January 2014 (UTC)
 * I get a message, stating that a template of file was changed and that I should approve said change. It appears on every page in the "article" namespace, that has the changed template in use. Heinrich krebs (talk) 06:29, 12 May 2014 (UTC)


 * Could it be that you're actually using the FlaggedRevs extension? Yaron Koren (talk) 12:18, 12 May 2014 (UTC)


 * Oh, Yes I do. Sorry. Heinrich krebs (talk) 14:57, 14 August 2014 (UTC)

Using this extension for draft revisions
I'm not sure if this is feasible, but here goes anyway. I basically want a light-weight extension that allows an editor who needs it to save one or multiple draft versions of a page and later to submit the version that's fit for public view. This is arguably the same thing as marking a page as both approvable and unapproved, which is why I'm considering the Approved Revs extension, but I would like to simplify the process. I was wondering if the following approach is feasible: Is this safe to do? Or does the latest unapproved revision need to be 'approved' before removing __APPROVEDREVS__ ? Note that it is meant to bypass explicit approval in favour of making something no longer approvable, killing two birds with one stone. My biggest concern about this is that switching __APPROVEDREVS__ on and off again at irregular intervals may lead to unexpected behaviour. Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 12:43, 16 February 2014 (UTC)
 * make pages approvable only by having __APPROVEDREVS__ as an option.
 * The option would be available as a checkbox in a form (Extension:Semantic Forms) so that it can be switched on and off.
 * When a couple of drafts later, the new version of the page is good to 'go live', all you need to do is to uncheck the checkbox and save the page.


 * What's the need for all this extra interface stuff - why not just use the standard Approved Revs approval process? Yaron Koren (talk) 14:47, 16 February 2014 (UTC)


 * Quite simply because it seems more wearisome having to approve every latest revision. Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 09:13, 17 February 2014 (UTC)


 * Ah, I think I get it. Is the idea that "blank if unapproved" would be set to true? That might have been the missing piece. If so, you're essentially talking about using Approved Revs as a page-blanking system - a directive like __DISPLAYBLANKPAGE__ might be ideal for your case. :) Perhaps actually creating an extension that does that is the way to go, as silly as it sounds? It would be less overhead, and not have the potential pitfalls of Approved Revs. Thinking about it now, there actually may be a lot of use for such an extension, especially when combined with Semantic Forms. Yaron Koren (talk) 14:56, 17 February 2014 (UTC)


 * Well, blanking the entire page seems a little extreme. The latest revision before the page is made approvable should be fine, if at all possible. Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 09:09, 19 February 2014 (UTC)


 * Okay, I misunderstood the question, then. What's superior (or less wearisome) about clicking on "Edit with form", checking the checkbox, and then saving the page, vs. going to the history page and clicking "approve" on the top line? Yaron Koren (talk) 13:42, 19 February 2014 (UTC)


 * That's not a fair comparison : ) Not all pages will necessarily have to go through the approval process and those that do will need to only for the time concerned. During those intervals of revision, every page edit would be a matter of "open form and edit, then add, keep or remove the magic word (whether or not this comes with a checkbox), and save the page". Let me narrow down the question to this: (1) can the magic word ( __APPROVEDREVS__ ) be removed from the page when it is no longer needed (or is it necessary to approve the page first); (2) can the same process, i.e. adding and removing the magic word, be applied more than once on the same page? Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 14:58, 19 February 2014 (UTC)


 * Alright - I still don't understand, but since that's all you want to know, I guess it's not relevant anyway. Unfortunately, my answer is: I don't know. :) Yaron Koren (talk) 15:32, 19 February 2014 (UTC)

BlankIfUnapproved only for some groups
Is it possible to use "BlankIfUnapproved" only for special groups? For example a Administrator see the unapproved page, but a normal User see blank?


 * No, it's not possible. I'm not sure if that would be a good idea: it would mean that admins might not be aware of what regular users are seeing. Yaron Koren (talk) 16:46, 6 March 2014 (UTC)

Thank you for the fast answer! I think it would be very helpful. If an author write an unapproved articel and want to change something later, he has to click on the link or history tab. And without the blank-function I have no possibility to see on the first look, if a page is approved or not. Or is there an option?


 * Yes, it's more work for the admin - but as I said, maybe that's good, in that it's a constant reminder that a revision on the page needs to be approved. As for seeing whether a page has been approved, if "blank if unapproved" is turned off, there will be a little message at the top of the page indicating that - see here, for example. Yaron Koren (talk) 15:12, 7 March 2014 (UTC)

Sectioneditlinks gone
Our intranet wiki relies heavily on section edit links being available. These links are shown only on the current revision, as calculated on line 560 of article.php: elseif ( !$this->isCurrent || !$this->getTitle->quickUserCan( 'edit', $user ) ) { $parserOptions->setEditSection( false ); } An article is never current when Approved Revs loads the approved revision because of showApprovedRevision (&$title, &$article). This function replaces the current article object with a new one that has a revisionID which causes article.php to view the article as !current.

I've been trying to find a workaround. Initially, I added $article->mOldId=0 to function showApprovedRevision. This worked (edit links visible) but broke the function setSubtitle...The custom Approved Revs subtitles don't get displayed.


 * This works fine for me - if the latest revision is approved, all the section edit links appear. What version of Approved Revs and MediaWiki are you using? Yaron Koren (talk) 14:25, 23 March 2014 (UTC)


 * We're using MediaWiki 1.19.7 and Approved Revs version 0.6. We're also using Vector skin.


 * Alright - upgrading your version of Approved Revs might help. Yaron Koren (talk) 16:04, 26 March 2014 (UTC)

Can't suppress 'View the most recent revision' link
MW 1.22.5

Extension v. REL1_22

My LocalSettings:

require_once( "$IP/extensions/ApprovedRevs/ApprovedRevs.php" ); $egApprovedRevsAutomaticApprovals = false; $egApprovedRevsShowNotApprovedMessage = false; $egApprovedRevsShowApproveLatest = true; $egApprovedRevsSelfOwnedNamespaces[] = array(NS_USER ); $egApprovedRevsBlankIfUnapproved = true; $wgGroupPermissions['*']['viewlinktolatest'] = false; $wgGroupPermissions['sysop']['viewlinktolatest'] = true;
 * 1) Extension: ApprovedRevs

As a test, I created a new page and did not approve it. Then I logged in as a regular User and see the message at the top of the page "No revision has been approved for this page. View the most recent revision."

I require new pages with no approved revisions to be blank and for normal Users NOT to see the link to the most recent revision. Shouldn't the $wgGroupPermissions['*']['viewlinktolatest'] = false; setting achieve this?

Am I missing a Permissions setting, or is this a bug?

Thanks Bill


 * That is indeed a bug - I just fixed it in Git. Thanks for pointing out the problem. Yaron Koren (talk) 20:49, 28 April 2014 (UTC)

make ApprovedRevsSelfOwned assignable to individual user groups
Can you make the ability to allow users to own their own pages assignable to user groups? In my application, I have created a user group 'writer'. I want that group to be able to own their own pages for approval purposes. I want to give the group 'user' permission to create a page, but for that page to be blank until approved.

Or is there a way to do that that I have not seen?


 * Unfortunately, no - there's no way to do user-group-based permissioning. There are general long-term plans to add such a thing, in addition to category-based permissions. Yaron Koren (talk) 21:07, 7 May 2014 (UTC)

Thanks Yaron. Those would be very useful capabilities. Regards, Jeff


 * Jeff,


 * As Yaron mentioned there are plans to add this functionality. I have modified the extension to provided the capabilities I believe you are interested in, but Yaron and I simply have not had the time to work together to merge in the changes. My fork of the extension can be found at https://github.com/jamesmontalvo3/MediaWiki-ApprovedRevs


 * My organization has been using this fork for about six months and it is working well for us. We have a wiki with about 2500 pages, 40 active contributors and 2000 page views a day, so it has gotten decent field testing. The modified extension allows specifying different approvers based on namespace and category. It even allows you to say, for example, that all pages of category "Story" will be approvable by whoever is set as "Author" of the page using semantic properties. So if we set this page to and then added Author::Jamesmontalvo3 and Author::Jeffatcw then you and I would be able to approve this page, but Yaron would not (Sorry, Yaron :-) ). This of course requires the Semantic MediaWiki extension installed to support properties.


 * Yaron, we should setup a time to discuss the merge.


 * --Jamesmontalvo3 (talk) 15:21, 8 May 2014 (UTC)


 * Any time is good with me! Yaron Koren (talk) 16:28, 8 May 2014 (UTC)

James (and Yaron),

Thanks for this. I am going to give it another field test for you. My wiki is still in development so it will be a small test. I'll let you know how it goes. I do have Semantic Mediawiki installed.

Regards, Jeff Update from Jeff 5/21/2014:

When we looked it appeared that James' fork uses an older version of the extension that does not have some bug fixes. We have elected to wait until you are able to merge.

Possible performance problem
See Thread:Project:Support desk/Some pages taking 7 - 15 seconds to load --Ciencia Al Poder (talk) 09:30, 27 May 2014 (UTC)

CategoryPermissions deactivates ApprovedRevs?
My plan was to use ApprovedRevs only in a certain namespace/category and also only permit sysops to approve and edit articles in that namespace/category. I figured using both ApprovedRevs and CategoryPermissions would be the way to go. Unfortunately when I activate CategoryPermissions in my LocalSettings.php I can't approve or disapprove any more articles. Still, the old approved versions are being showed as default and I can see the star in the history. Any suggestions how to fix this?

Approved revisions shown twice on "Special:ApprovedRevs"
Heiya,

I noticed that the special page lists approved pages/versions twice like e.g. The respective wiki is using Approved Revs 0.7 on MW 1.23.1 with PHP 5.4 Probably there is something in the water...
 * 1) "Main Page" (Version 2)
 * 2) "Main Page" (Version 2)

Cheers --&#91;&#91;kgh&#93;&#93; (talk) 20:04, 21 July 2014 (UTC)


 * Is it on "Unapproved Pages" list only, or have you noticed it on others? I believe this patch is the issue. It has been reverted in an upcoming release of Approved Revs. --Jamesmontalvo3 (talk) 20:32, 21 July 2014 (UTC)


 * Oops, I was not very clear about this. It is only happening in the list of pages that have an approved revision. The list with all pages whose approved revision is not their latest revision, and the list of all pages that do not have an approved revision are ok. Let's see what happens in the next release. Thank you for your feedback. --&#91;&#91;kgh&#93;&#93; (talk) 07:28, 22 July 2014 (UTC)


 * Well, just found out that this duplication causes a serious issue in combination with the Semantic Forms extension. Due to the duplication the pages now believe that two forms are defined for it thus making it uneditable. Just had a look at the repo. Apart from translation updates, version 0.7 is the latest version. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 20:42, 24 July 2014 (UTC) PS Hmm, this is pretty weird: The pages contain pictures embedded like e.g. Filename.jpg which were themselves uploaded using Semantic Forms and adding them directly to namespace File (not via the form used to edit the page - uploadable). So if one wants to edit the page it tries to edit it with the form used for uploading the picture. However the existence of the picture does not involve adding a category which uses the form used for uploading the picture. --&#91;&#91;kgh&#93;&#93; (talk) 20:53, 24 July 2014 (UTC)


 * Oh man, just found the issue with the duplicate form assignment. The template of the page included a semantic query searching for a picture within the category which itself is using the form for uploading files. So this was actually the only file not embedded the classic way. So I am glad that this is sorted out now. Still the issue with the duplicate listing remains. I have to note that this only started to be a problem after the page was approved. Before that the query did not cause the "form duplication" issue. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 21:14, 24 July 2014 (UTC)


 * Yeah...that sounds like the issue. Sometimes I encounter similar issues when a there is a conflict between categories defining which form a page should use with Has default form::form-name and templates defining which form the page should use via Page has default form::form-name . See Extension:Semantic Forms/The "edit with form" tab. Also, the new version of Approved Revs is still being reviewed...hopefully released any day now. --Jamesmontalvo3 (talk) 21:22, 24 July 2014 (UTC)


 * Ah, there is still an unmerged commit on the way. Now I get it. :) Still wondering why Approved Revs causes the issue to appear in the first place. Semantic Forms on itself was happy with the query containing the "evil" category. However, I should avoid unnecessary code in my queries right from the start. --&#91;&#91;kgh&#93;&#93; (talk) 21:40, 24 July 2014 (UTC) PS Will move the new version is as soon as its ready to go. :)


 * The changes are pretty substantial. Most notably you can now define specifically who can approve what content (by NS, category, page, SMW property) and files are approvable (approved version of images are displayed on pages). --Jamesmontalvo3 (talk) 22:02, 24 July 2014 (UTC)


 * WOW, this sounds indeed like substantial changes are in the making. :) This will definitively widen the use cases for this extension. --&#91;&#91;kgh&#93;&#93; (talk) 17:47, 26 July 2014 (UTC)

Sent Yaron my modification of ApprovedRevs
I modified your code with the following features my group required For all features to work a couple of scheduled jobs are required. One to mark old documents as expired and another to periodically send emails to owners of expired, rejected, and force-reviewed documents. I hope you find it useful. Please let me know if sending Yaron the code is the best way to contribute or if you have any questions.
 * Email notifications
 * Document expiration
 * Group ownership of categories (for email notifications)
 * Ability to restrict approval privs for members of specific mediawiki groups to specific categories
 * Ability to restrict approvers of specific categories to members of specific mediawiki groups.
 * Ability to reject document edits
 * Ability to "force-review" documents


 * @User:134.134.137.75: Is there any way to look at your modifications? need them for my intranet wiki Ibutakov.smartec (talk) 12:45, 8 April 2016 (UTC)

ShowNotApprovedMessage on excluded Namespaces (Bug?)
Hi,

I've come across a strange behavior when using $egApprovedRevsShowNotApprovedMessage = true. The message, that a certain page has no approved revision is shown on all wiki pages, also on pages which are not part of the $egApprovedRevsNamespaces[]. Is this an intender behavior or how can I turn this off. I am using the latest version 0.7 (May 2014).

What I would like to achieve is, that the Approved Revs extension is only active for a specific namespace. Pages on other namespaces should not be affected.

Thank you!


 * Good point! That was indeed a bug. I just checked in what I think is a fix; if you get the latest code from Git, the problem should hopefully go away. Yaron Koren (talk) 02:07, 20 August 2014 (UTC)

How to implement for the few initial edits of new users?
Is there some way to use Approved Revs to moderate (the first few edits of) newly registered users? It might also be useful to be able to revert a user back onto moderation. This would be used by bureaucrats for manually preventing spam. -- Rob Kam (talk) 08:24, 25 August 2014 (UTC)


 * I don't know if I understand the question - under Approved Revs, every (non-admin) user's edits are "moderated", regardless of whether they're newly-registered. Yaron Koren (talk) 12:39, 25 August 2014 (UTC)


 * Okay thanks, it would work like this: The approverevisions permission is not given by default to new users of the wiki. That's like they're on moderation, unless a sysop changes their user rights to be a member of the approverevisions group. -- Rob Kam (talk) 14:49, 25 August 2014 (UTC)


 * Sure, that's how it works now. Yaron Koren (talk) 23:40, 25 August 2014 (UTC)

Regarding Approved Revs extension installation
Installed “Extension:Approved Revs” to prevent publishing changes to a page until approval. For that, I did the below changes but still I could not see the (approve) link on history page. Also, the changes made on the pages are published directly to all the users.

1. Created a folder “ApprovedRevs” inside extension folder and copied all the files. 2. Executed the DB scripts to create the DB objects 3. Added the below configuration in the LocalSettings PHP file

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

Also, I could not find the "special:version" page to know whether the extension is correctly installed or not.

Am I missing anything? Appreciate your help. Thanks


 * Hi again. When you go to the main page of your wiki, does the URL have "Main_Page" at the end of it? If so, replace that "Main_Page" with "Special:Version". Yaron Koren (talk) 23:27, 4 November 2014 (UTC)

Thanks, We can see special:version page, it shows the below details. what we need to do now ? Installed software

Product

Version

MediaWiki 1.23.5 PHP 5.6.0 (cgi-fcgi) MySQL 5.6.21-log

Entry point URLs

Entry point

URL

Article path /index.php?title=$1 Script path / index.php /index.php api.php /api.php load.php /load.php

Parser extension tags &lt;gallery&gt;, &lt;nowiki&gt; and &lt;pre&gt;


 * Does "Approved Revs" show up in there? If not, it means you don't have the extension installed. Yaron Koren (talk) 16:04, 21 November 2014 (UTC)

How do I disable the extension for some namespaces?
I just can't figure this out. I have a namespace called Portal, I don't really think that the extension should be enable for that namespace, I want to disable for that namespace, how do I do that?


 * If you have a custom namespace, Approved Revs will not be enabled for that namespace unless you configure it to. If you're seeing Approved Revs stuff for "Portal:" pages, it could be that you don't actually have a "Portal:" namespace - in other words, that those are just pages in the main namespace whose name starts with "Portal:". When you click on the "talk" page for one of those pages, does it look like "Portal talk:" or like "Talk:Portal:"? Yaron Koren (talk) 16:09, 21 November 2014 (UTC)


 * In case the question is actually, "How do I disable the extension for the default namespaces?", then the answer is to $egApprovedRevsNamespaces equal to a new array that contains only the namespaces you want. For example,   Lsilverman (talk) 21:45, 25 February 2015 (UTC)

Publication of changes after approval
Hi,

How can i do publication of changes after approval?


 * What do you mean by that? Yaron Koren (talk) 23:44, 8 December 2014 (UTC)


 * How to do for user/guest, who edit/create article could be (before published) approved by the administrator. Edits not approved by the administrator can't be seen by visitors or users. In the same way it works on wikipedia.


 * That is already what Approved Revs does, no? Yaron Koren (talk) 21:44, 9 December 2014 (UTC)

Approval from "Special:ApprovedRevs&show=notlatest"
The item ===Special:ApprovedRevs page===, says "Approved Revs defines a special page, " " which can show three separate lists: all pages that have an approved revision, all pages whose approved revision is not their latest revision, and all pages that do not have an approved revision. For the third list, of pages with no approved revision, you can optionally include a link for each page to mark that page's latest revision as approved. To include such links, add the following to :

Is there a similar setting for the list of all pages that do not have an approved revision ("Special:ApprovedRevs&show=notlatest"), i.e. to approve straight from that page? At the moment, there's only "diff from latest", and if I click on that, I still cannot approve the page, but have to click through to history. It would be good to have an approve link on Is that possible? Bjoern (talk) 11:40, 7 January 2015 (UTC)
 * the list itself ("Special:ApprovedRevs&show=notlatest"), as well as
 * on the page diff that you reach from that list.

As a second suggestion, it would also be good if Special:ApprovedRevs linked to the approval log (Special:Log/approval), and vice versa.


 * No, it's not possible at the moment, but it's a good idea - as is the second one. Yaron Koren (talk) 14:52, 7 January 2015 (UTC)

BlankIfUnapproved hides category links in 1.24.1
We discovered this today when upgrading our wiki from 1.20 to 1.24.1. When BlankIfUnapproved is turned on, the list of links in category pages is blank. This is true even if none of the linked pages are subject to ApprovedRevs. Turning off BlankIfUnapproved fixes the issue. We tried using the master, REL1_24, and REL1_23 branches, all of which have the same result. We're running nginx with FastCGI using PHP 5.4.36. --69.174.87.60 18:01, 21 January 2015 (UTC)

approveAllPages.php doesn't work as indicated
In the documentation for the approveAllPages.php script it's indicated that "this script approves the latest revision of all pages that can be approved but do not have an approved revision". Is there anyway to approve all pages regardless of whether they have an approved revision or not?

My Use Case here is that I just turned on Approved Revisions again, after having disabled it for a short time every page in the wiki requires approval for the latest page revision to be the active revision.

Is there a way to mark every page's latest revision as approved?

Thanks --Wmat (talk) 17:43, 9 February 2015 (UTC)


 * I assume you mean that the script doesn't work as desired. I think the easiest solution would be to go into the database and manually delete everything from the "approved_revs" table, with a "DELETE FROM approved_revs" or some such; then call that script again. Yaron Koren (talk) 19:21, 9 February 2015 (UTC)


 * OK, that's what I'll do. Thanks. --Wmat (talk) 19:40, 9 February 2015 (UTC)

Where can I find the name of the user who did the approval?
It seems this extension doesn't capture the ID of the user who approved the revision. Is that correct? I'm looking at the schema of the approved_revs table and it seems like it's not tracking the user. There's no accountability behind approving a revision? Lsilverman (talk) 21:50, 25 February 2015 (UTC)


 * Approval information is stored in the "Revision approval" log, which you can find at Special:Log. You can also see recent approvals in the recent changes page. Yaron Koren (talk) 23:58, 25 February 2015 (UTC)


 * Awesome, thank you! I'm going to update the extension wiki page to mention these things. Lsilverman (talk) 16:52, 26 February 2015 (UTC)

Unexpected blanking for pages in File: namespace
I enabled ApprovedRevs for just one namespace by setting a new array to $egApprovedRevsNamespaces. I'm also using the feature to show a blank page instead of an unapproved version.

I'm getting an unintended consequence that the content of pages in the "File:" namespace are blanked.

This is my config.

require_once( "$IP/extensions/ApprovedRevs/ApprovedRevs.php" ); $wgGroupPermissions['qms-approvers']['approverevisions'] = true; $egApprovedRevsNamespaces = array(NS_QMS); $egApprovedRevsAutomaticApprovals = false; $egApprovedRevsBlankIfUnapproved = true;
 * 1) Grant members of the AD group "qms-approvers" the rights to approve revisions in the QMS namespace.
 * 1) Here we use the array syntax to wipe out the 5 default namespaces, which includes NS_MAIN,
 * 2) the main namespace. Currently, we only want to deal with approvals in the QMS namespace.
 * 1) Do not automatically approve revisions when edited by approvers.
 * 1) Show blank pages instead of unapproved initial drafts.

Commenting out the $egApprovedRevsBlankIfUnapproved line makes it work again.

Any ideas? Lsilverman (talk) 15:32, 2 March 2015 (UTC)


 * Could it be that the ID you picked for NS_QMS is the one already in use for NS_FILE? Also, what versions of MediaWiki and Approved Revs are you using? Yaron Koren (talk) 16:03, 2 March 2015 (UTC)


 * No, we use IDs in the 5000 range to avoid problems. I chose 5116 for NS_QMS and 5117 for NS_QMS_TALK. Versions: MW 1.23.8, ApprovedRevs pulled fresh from master github last week, Version page says 0.7 (1b98bf7) 21:00, 18 February 2015. Lsilverman (talk) 16:08, 2 March 2015 (UTC)


 * Very strange... do you know for sure if the "File:" namespace is the only one behaving incorrectly out of all of them (including "QMS")? Yaron Koren (talk) 16:20, 2 March 2015 (UTC)


 * I agree, strange. I just ran some quick tests with other base namespaces, and everything I tried worked: Special, User, Template, MediaWiki and our own custom namespaces are all fine. Lsilverman (talk) 16:39, 2 March 2015 (UTC)


 * I just want to clarify that, by "blank", you mean it looks like a wiki page with no text, as opposed to a blank browser screen. Is that true? And if so - if you go to the history for a file/image page, do you see "Approve" links? Yaron Koren (talk) 17:09, 2 March 2015 (UTC)


 * Maybe this will help. The metadata about the file (such as file history, file usage, Link to download file, warning about file possibly containing malicious code, all the boilerplate stuff) disappears BUT anything written in normal wiki markup about the file is still visible. There are no Approve links on the View History page, and no evidence whatsoever that ApprovedRevs is enabled. I did a side-by-side before and after view of the history page, no differences. Lsilverman (talk) 17:25, 2 March 2015 (UTC)


 * Oh. That's not really a blank page at all, then - just a bug in which file-only data doesn't get displayed. I don't know what would cause that; it might require direct debugging. Yaron Koren (talk) 17:57, 2 March 2015 (UTC)


 * I didn't notice at first that wiki markup was showing, as the file on which I discovered the issue didn't have any wiki text in it. So for all intents and purposes, it looked like a blank page .Lsilverman (talk) 18:00, 2 March 2015 (UTC)


 * Ah, that makes sense. Yaron Koren (talk) 18:09, 2 March 2015 (UTC)


 * Yaron, do I need to log a bug somewhere? What's the next step? Lsilverman (talk) 15:51, 3 March 2015 (UTC)


 * Sure, if you want to - this would be the place to do it. But this may require debugging on your specific server, since I haven't heard of it happening anywhere else. Yaron Koren (talk) 16:25, 3 March 2015 (UTC)


 * I was hitting the same issue, I'm thinking the problem may be caused by calling $article = new Article( $title, $revisionID ) against the file namespace in showApprovedRevision. I was able to resolve the issue by modifying the following:


 * There may be a better way to do this, but my knowledge of wiki and PHP in general is limited, and it works :D.Amnesia1187 (talk) 15:57, 14 March 2015 (UTC)


 * Nicely done! I tried your code in my instance, and it appears to solve the problem. Thanks! Lsilverman (talk) 17:22, 25 March 2015 (UTC)


 * That's great to hear! I was hoping to hear some confirmation that the fix worked. Amnesia1187, I just checked in your patch verbatim. Thank you| Yaron Koren (talk) 20:20, 25 March 2015 (UTC)

Redirect to latest version instead of the latest approved version upon save?
A suggestion. Upon saving an edit, I'm redirected to the current approved revision, or, in the case where a blank page is to be shown when there is no approved revision, I end up looking at a blank page. I then need to click a link to view the most recently edited version.

It's a small thing, but it would be (in my opinion) more convenient and intuitive as an author who just saved an edit to be redirected to my new version so that I can immediately view my changes. Lsilverman (talk) 21:20, 1 April 2015 (UTC)

Email Notifications and how they work with ApprovedRevs
Hello, we use this extension in our company wiki and it works great. One thing we noticed is that we also have set up email notifications for when pages are changed. If the page is on someones' watchlist they get notified of the change. However since we implemented your extension that notification doesn't get sent until after the change has been approved. Is there a way to have notifications sent prior to approval that a change was made and awaiting approval? Am I missing something or setting?

Thank You

May 11, 2015 18:41 UTC


 * Are you saying that Approved Revs changes the standard watchlist notification behavior? If so, that's a major bug - I just want to confirm that that is in fact what you are saying. Yaron Koren (talk) 20:00, 11 May 2015 (UTC)

I guess, we have it installed and if the page is on your watchlist and another person makes a change, then we expected to receive a notification. However testing it out we did not get the notification until the actual change was approved by an Approver. Since we were hoping to have the Approvers set up wathclists for pages they were going to approve recommended changes to, it kind of defeats the purpose of how we intended to use both. Our Mediawiki install is 1.22.2 if that helps.

Thank You

01:45 AM 2015 May 12

Update 19:02 2015 May 12th I did some testing on our dev site. I went ahead and commented out any reference to this extension in LocalSettings.php and then set up a few pages on my watchlist. Then using a different browser and user account I went ahead and modified those pages. I received an email notification within a few minutes of the changes going through.

Then I re-enabled the extension, made some changes to pages on my watchlist using a generic account again and hit save. I did not receive any email notifications even after I approved the page changes. However if I made changes and someone else with approver rights did the apprvoing then I did get the email notification. I hope this helps explain the issue better.

Thanks


 * Okay, thanks - this information is quite helpful. I'll look into this issue. Yaron Koren (talk) 14:33, 13 May 2015 (UTC)

Getting rid of approval necessity
One of my co-admins "accidentially" hit the approve link in history. Now every upcoming edit to that page needs to get approved (works as designed). BUT he hit the wrong line so the page that always needs to be approved was intended to have no approval mechanism on it. How can we get that page to behave like all the other (never approved) pages. Tbh the addon is currently not used in our wiki but uninstall is impossible due to company-internal restrictions. Ciannicay (talk) 12:27, 8 July 2015 (UTC)


 * Just go to the page history and hit "unapprove" for that revision. Yaron Koren (talk) 13:16, 8 July 2015 (UTC)

If you don't have command line access for approveAllPages.php
Hello,

I had a problem to execute the approveAllPages.php, because I have no command line access. I looked up into the php file and saw the logic behind this file. If you have the same probblem as i had and you have access to your database you can do the same thing that the script does for you with the following mysql code:

INSERT INTO `approved_revs` (  `page_id`,  `rev_id` ) SELECT page_id, page_latest FROM page

Take care if you use a prefix for your wikidatabase, the "approved_revs" and the "page" table should be changed in the code.

Adding custom namespace to $egApprovedRevsNamespace causes DB error.
After adding a custom namespace to egApprovedRevsNamespaces[] = NS_MYNEWSAMESPACE; and turning on error reporting, I get:

Notice: Use of undefined constant NS_MYNEWNAMESPACE- assumed 'NS_MYNEWNAMESPACE' in /u1/MediaWiki/LocalSettings.php on line 162

And on Special Pages: Approved Revisions, I get:

A database query error has occurred. This may indicate a bug in the software.

This is MW 1.25.2 and Approved Revisions branch REL1_25.

Thanks Bill


 * It sounds like you didn't define the namespace ID in LocalSettings.php. Yaron Koren (talk) 19:44, 1 September 2015 (UTC)


 * You were right, the call to Approved Revisions was prior to the namespace definition in LocalSetting.php. Thanks! --Wmat (talk) 20:14, 1 September 2015 (UTC)

Approve/Unapprove fails for pages using Semantic Maps
The approve and unapproved actions utilise a local parser object however if you have say a Semantic Map ask output in the page content then there is a fatal exception since the global parser $wgParser is not unstub before getMapHTML in SM_MapPrinter.php

Changing the parser to global object $wgParser in unsetApproval and setApprovedRevID in ApprovedRevs_body.php partially solves the problem maybe but then there is a still a strange intermittent issue where most times the content needs to be purged again after?

This issue may affect Widgets in page too?

Approve/Unapprove fails for pages using the Comments extension
If a page has the "comments" tag it cannot be approved (or un-approved for that sake) - a server error 500 is thrown. After deleting the "comments" tag the page can be approved again. This was observed in MW version 1.25.3, ApprovedRevs version 0.7, and Comments version 4.1.0.

How to set..
Hi, How to set up this extension that the latest aproved (by admin) version was public? And to the administrator had to approve the new version until public viev? — Preceding unsigned comment added by Azot944 (talk • contribs) 20:05, 3 December 2015


 * Add "$egApprovedRevsBlankIfUnapproved = true;" in LocalSettings.php? I'm not sure I understand the question. Yaron Koren (talk) 21:19, 3 December 2015 (UTC)Add
 * Add As long as the administrator didn't approve of my editing, everyone sees only the last approved by the administrator edition. That function should work like in the wikipedia
 * I still don't understand - isn't that how Approved Revs works now? Yaron Koren (talk) 19:45, 14 January 2016 (UTC)

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:

to  and accordingly deleted the second. 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)

line 48-49 of ApprovedRevs.php line 90 of ApprovedRevs.hooks.php
 * 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:
 * The respective functions can be found in ApprovedRevs.hooks.php. I simply changed the function parameters from the original code
 * to
 * as demanded by Manual:Hooks/ArticleSaveComplete. The same procedure has to be done with  (line 123).
 * As it seems right now, the ApprovedRevs extension seem to work with PHP7! --TheFamilyBusiness (talk) 13:31, 22 February 2016 (UTC)
 * 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: replace by after that original code replace by Now when viewing latest revision you will have button to approve current revision

and on more inside displayNotApprovedHeader function at the end

after  add

instead of

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   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.


 * 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)  (depends on selected language). So my code goes after that, inside   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  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  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


 * 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)