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)