Extension talk:Approved Revs/Archive 2014 to 2015

'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:

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

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)

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:

# Extension: ApprovedRevs
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;

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 [[Category:Story]] 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.

1. "Main Page" (Version 2)
2. "Main Page" (Version 2)

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

Cheers --[[kgh]] (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. --[[kgh]] (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 --[[kgh]] (talk) 20:42, 24 July 2014 (UTC) PS Hmm, this is pretty weird: The pages contain pictures embedded like e.g. [[File:Filename.jpg|caption]] 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. --[[kgh]] (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 --[[kgh]] (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. --[[kgh]] (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. --[[kgh]] (talk) 17:47, 26 July 2014 (UTC)

Sent Yaron my modification of ApprovedRevs

I modified your code with the following features my group required

• 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

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.

@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 <gallery>, <nowiki> and <pre>

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, $egApprovedRevsNamespaces = array(NS_MYNAMESPACE); 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, "Special:ApprovedRevs" 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 LocalSettings.php:

$egApprovedRevsShowApproveLatest = true;

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

• the list itself ("Special:ApprovedRevs&show=notlatest"), as well as
• on the page diff that you reach from that list.

Is that possible? Bjoern (talk) 11:40, 7 January 2015 (UTC)

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

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)

@Lsilverman and Yaron Koren: 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:

static function showApprovedRevision( &$title, &$article ) {
	if ( ! ApprovedRevs::isDefaultPageRequest() ) {
		return true;
	}
		
	$namespace = $title->getNamespace();
	global $egApprovedRevsNamespaces;
	
	if ( ! in_array ( $namespace, $egApprovedRevsNamespaces ) ) {
		return true;
	}

	global $egApprovedRevsBlankIfUnapproved;
	$revisionID = ApprovedRevs::getApprovedRevID( $title );

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)