Extension talk:Approved Revs

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)

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

Add to ApprovedRevs_body.php: &darr;

later add something like

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


 * This is an interesting idea. You can already see who approved the latest revision by going to the history page, then clicking on "View logs for this page" at the top - unless there has been a huge amount of activity related to that page, the latest approval should be viewable there. I admit that that's obscure - although putting the approver's name right at the top of the page seems like the opposite: a little too conspicuous.


 * This is all complicated by the fact that auto-approvals make the concept of "approved by" a little blurry. If an administrator makes an edit to a page and that latest revision gets automatically approved, does that administrator deserve to be listed as the approver? After all, they didn't actively do anything to approve that revision. But listing anyone else as the approver would also be strange.


 * What about listing the approver's username on the history page, right near the star in the approved revision's entry - and only if the approval was not an auto-approval?


 * I guess this is really two or more questions: where (if anywhere) to display the approver information, and whether to display it in all cases. Any thoughts on this? Yaron Koren (talk) 16:55, 25 November 2016 (UTC)


 * @Yaron_Koren: I think approver's name near revision in page history (+not auto approved) would be great. I proposed my version above because I created that solution for my company and we need to see approver's name right away when viewing page. Yeah, that's just in my case, but for everyone, it would be great to see that name easier than looking into log. So, username after revision in history page seems great idea to me. And, btw, we do not use auto approvals, so I didn't even think of how my idea will work with that. Sorry for my poor english :) 217.108.170.8 10:20, 28 November 2016 (UTC)

1.28.0 Warnings
Getting a lot of PHP Warnings since upgrading to 1.28.0 2016/12/01 01:14:43 [error] 22933#22933: *1021790 FastCGI sent in stderr: "PHP message: PHP Warning: Attempt to modify property of non-object in / /extensions/ApprovedRevs/ApprovedRevs.hooks.php on line 239 Debian 8.1, nginx 1.10.2, PHP-FPM 7.0.13, MariaDB 10.1.19, Mediawiki 1.28.0, REL1_28 extensions --FoXFTW (talk) 00:22, 1 December 2016 (UTC)


 * This may or may not be the issue, but: you shouldn't use the MediaWiki version branch (i.e., REL1_28) for Approved Revs, or most other non-Wikimedia extensions, since it just represents a random snapshot. Instead, you should get the latest version of the code, if at all possible. If you can't do that - what code do you see on that line of that file? Yaron Koren (talk) 03:24, 1 December 2016 (UTC)


 * @Yaron_Koren: Hi, I have the same error on 1.28.0 (stable release) but I turned off errors viev and everythings working very vell. http://i.imgur.com/a51YYTU.png (Top of the page)


 * What code do you have on that line? Yaron Koren (talk) 04:32, 1 December 2016 (UTC)


 * @Yaron_Koren I cloned the master branch from github, still getting the warnings for line 239 Line 239: return self::showBlankIfUnapproved( $article, $contentObject->mText );
 * By removing ->mText in Line 239 the warning seems to be fixed. $contentObject isn't an object but a string --FoXFTW (talk) 21:42, 1 December 2016 (UTC)


 * Okay, that's the same code I have for that line. It's just very strange that it's producing that error... FoXFTW - are you sure $contentObject is a string? Maybe it's null? And if it is a string, what does it hold - the page contents? Yaron Koren (talk) 05:02, 2 December 2016 (UTC)


 * $contentObject is not null, I tested that. I'm pretty sure that $contentObject is a string since it only holds the complete pages content. (is_object returns false) --FoXFTW (talk) 11:10, 2 December 2016 (UTC)


 * Alright, that's very good to know. This may possibly be a bug in MW 1.28, but in any case, I just added in a check to the code, using is_object; so this warning message will hopefully go away. Yaron Koren (talk) 13:14, 2 December 2016 (UTC)

redirect to page after approval
@Yaron_Koren:

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

217.108.170.8 09:23, 19 December 2016 (UTC)


 * What do you mean by "more convenient"? What's inconvenient about the current approach? Yaron Koren (talk) 03:46, 20 December 2016 (UTC)


 * @Yaron_Koren: Right now when you approve some page you will see at the top of that page message that page was successfully approved AND another one, saying that this version is not approved. A little bit misleading. Another minus - no edit section links after approve action. Just IMHO, no offence :) 217.108.170.8 09:00, 20 December 2016 (UTC)


 * Do you really see a "this version is not approved" message, on the screen right after approving a revision? I don't see that part. Yaron Koren (talk) 14:41, 20 December 2016 (UTC)

DBQueryError
Tables are not correctly aliased in userCanApprove, query fails

results in bad query

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

should be


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

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

SpecialApprovedRevs.php: &darr;

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

approveAllRedirects.php: &darr; 217.108.170.8 09:38, 16 February 2017 (UTC)


 * This is interesting. Why do you want special handling for redirects - do you have a lot of them? Yaron Koren (talk) 14:34, 16 February 2017 (UTC)


 * @Yaron_Koren:Yeah, lots of people here creating many pages and links them to each other. And I don't want to loose that links. but our company has rules for some page names and lots of times I have to move pages. But even if you have just some small amount of redirects, to approve one you need to open special page->tap on name->tap on name of page you were redirected from->.... lots of actions. and if you have link to approve redirects right in list its very convenient and time saving :). You could make that thing optional and it won't bother someone who don't need that functionality. 217.108.170.8 08:17, 17 February 2017 (UTC)


 * Ah, okay. Why do you need redirect pages approved in the first place - do you have the "blank if unapproved" setting turned on? Yaron Koren (talk) 15:48, 17 February 2017 (UTC)


 * @Yaron_Koren: I need redirect handling because all pages here must be approved as fast as possible. All technical information needs to be double checked before usage. Thats why our technical experts must not loose time checking and approving redirects. We often use special page to check info about new unapproved and changed pages. Yeah, I know, this situation s very special, but IMO redirect pages must be somehow highlighted in list. No harm from that - thats for sure :) 217.108.170.8 07:29, 28 February 2017 (UTC)


 * Every additional feature does have a cost in terms of greater complexity of the software. Of course, many features are worth that extra cost. I'm still wondering, though, why you need redirects to be approved. What happens with redirects that are not approved - do they not work? Or are you just trying to keep that "List of unapproved pages" as short as possible? Yaron Koren (talk) 16:36, 28 February 2017 (UTC)


 * @Yaron_Koren: Trying to keep that "List of unapproved pages" as short as possible - exactly my situation. I just want to see there pages that really need to be checked.
 * Another way is to simple hide redirects from special page by adding few code lines below. Easy as pie and fully user controllable
 * 217.108.170.8 10:56, 6 March 2017 (UTC)
 * 217.108.170.8 10:56, 6 March 2017 (UTC)

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

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

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


 * *Phew* That's great that you think this would be enough of a solution for you. I'll add this in soon. Yaron Koren (talk) 14:26, 10 March 2017 (UTC)
 * @Yaron_Koren: already done by myself ;) Just proposing solutions that could be useful for someone else 217.108.170.8 14:37, 10 March 2017 (UTC)


 * Okay, I just checked in this change to redirect pages' display - and also set their names to be shown in italics. Hopefully this is a good enough solution... let me know if you think more should be done. Yaron Koren (talk) 18:01, 13 March 2017 (UTC)

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

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


 * Midgethoen (talk) 10:25, 14 March 2017 (UTC) I might be wrong assuming that bots inherit permissions from the person creating them, so I testen by letting the script create pages as a real user, this yields the same results: so it seems to be related to API edits


 * I tried to reproduce this, but unfortunately the script I'm using to try to edit pages is not working, for some reason. On the wiki, do the edits you make via the API script show up just like edits made via the web interface? Or is there some difference between them, like that these edits show up as minor or bot edits or something else? Yaron Koren (talk) 01:21, 17 March 2017 (UTC)


 * @Yaron Koren, No, from the history page I can not make a distinction between an API edit or a manual edit.. Midgethoen (talk) 10:02, 20 March 2017 (UTC)