Extension talk:Approved Revs

Bug in combination with PageForms

When a regular user creates a page for the first time, it is unapproved. If the user follows the link to the newest, but unapproved version of the page, there is not formedit button, just the source edit.

The same procedure for an admin user (with autoapprove rights) is working fine. After creating a page, you are redirected to the form immediately when hitting edit.

These are the settings:

$egApprovedRevsAutomaticApprovals = true;
$egApprovedRevsShowApproveLatest = true;
$egApprovedRevsBlankIfUnapproved = true;

I don't know if this has to be taken care of in PageForms or ApprovedRevs (or both). Krabina (talk) 09:39, 6 July 2022 (UTC)

Since the link to an unapproved page is &oldid= this is probably more a PF issue?

Are you basically saying that, if "oldid" is in the URL query string, "edit with form" doesn't show up? Yaron Koren (talk) 13:33, 6 July 2022 (UTC)

Yes, I guess this is what is happening. Krabina (talk) 10:44, 15 July 2022 (UTC)

Okay, actually, looking at this again, I think the issue is the "blank if unapproved" setting. If the page is unapproved and thus blank, it doesn't belong to any categories or officially contain any templates. So, unless you are doing namespace-based forms, there will be no form attached to the page - could that be it? Yaron Koren (talk) 13:45, 15 July 2022 (UTC)

No. The users use PageForms to create a page, the resulting page also belongs to a category. However, unless someone else approves the page, the second "edit" will not lead to the form again, but to the source view. Once a page is approved, the form is working as it should. For users with autoapprove rights, also creating a new page and then editing is working as expected. --Krabina (talk) 10:15, 19 July 2022 (UTC)

I don't understand - you have "blank if unapproved" set, and this is an unapproved page, so won't this page be blank, and thus belong to no categories? Yaron Koren (talk) 13:19, 19 July 2022 (UTC)

I see what you mean. So a user would have to click on "view latest version" first and then on edit to come back to the form. This is not very intuitive. If a regular user creates a new page, saves it and clicks on edit, he/she should be brougt back to the form. For other users, this page might not be shown, because it has no approved version (yet). But for the user who created it, I guess it is not intuitive to first click on the most recent version.

I don't think going to the latest revision would work either - the issue is that, officially, the page is blank and thus belongs to no categories. Thus Page Forms has no way to know that this page is form-editable, let alone which form to use. If this is a big problem, maybe you should undo the "blank if unapproved" setting? It can help in preventing bad page creation, but on the other hand sometimes you clearly do want unapproved pages to function normally. Yaron Koren (talk) 21:12, 19 July 2022 (UTC)

I tested this again. If you create the page, a blank page is shown indicating that there is a newer (unapproved) pagege. Clicking here leads to the editor as you described. Fine. But when you click on the link to the latest version, you look at the data you just entered and the page has a category assigned. However, there is only an edit link that again leads to the source editor instead of the designated form. Since the URL I am seeing is showing the &oldid, this is probably related to https://phabricator.wikimedia.org/T252525 and could be solved by page forms being able to handle this. Btw it does not help to set $egApprovedRevsBlankIfUnapproved = false; If this is set, I can see the page, but still editing of the unapproved page does not lead to the associated form.

Going to the latest revision will indeed show that category, but the page doesn't actually belong to that category - I think that's the issue. As for setting "blank if unapproved" to false - you need to re-save any page after making this setting change, for its category data to take effect. Yaron Koren (talk) 14:48, 24 August 2022 (UTC)

Bug with file upload with disabled file namespace

With

$egApprovedRevsAutomaticApprovals = false;
$egApprovedRevsEnabledNamespaces[NS_FILE] = false;

Files should not be getting approved. However on creation files are getting automatically approved (on their initial revision). This initial approval then counts against it in fileIsApprovable (via getApprovedFileInfo) as the initial approval in the database, meaning that all subsequent revisions are approvable as well.

The fix I've put in place is to (in setLatestAsApproved) wrap self::setOriginalFileRevAsApproved with if ( ApprovedRevs::fileIsApprovable( $title ) ) { } - then if files are not approvable generally, it never sets the initial approval and all is well, as far as I can tell.

Hopefully that's vaguely coherent... Lord Aro (talk) 16:38, 25 November 2022 (UTC)

The fact that that second setting doesn't disable file approvals does seem like a bug. But that first setting looks incorrect - it should be $egApprovedRevsAutomaticApprovals = false;. Could that solve the problem? Yaron Koren (talk) 17:43, 27 November 2022 (UTC)

Am I missing something, or is that not identical to the setting I posted? Lord Aro (talk) 18:01, 28 November 2022 (UTC)

Sorry! I got confused as well. I meant $egApprovedRevsFileAutomaticApprovals =false;. Yaron Koren (talk) 22:46, 28 November 2022 (UTC)

OK, looks like that setting does indeed fix the issue as well. But the documentation for it is confusing, and I still feel like it shouldn't be necessary along with the combination of my original settings. (Why are files special cased like this anyway?) Lord Aro (talk) 16:01, 2 December 2022 (UTC)

Suggestion for changes regarding clarity

Hi! I think this is an amazing tool, great work. I just set it up for myself and I wanted to call out some things that I think might make this process easier for future people who stumble upon this guide.

The "Indicating unapproved pages" section has a sentence which I really think belongs higher up. The sentence says: "By default, pages with no approved revision simply show up normally, with no indication of their status."

I think this is important information to call out early and perhaps be more clear about. I was running around like crazy trying to figure out why my test edits were were publicly viewable even though it was not approved AND I had the two lines of code to disable automatic approvals. I read this in the guide but it didn't quite click how all of the moving parts worked together.

It might also be helpful to revise this bit of information as follows:

• When a new article is created or when an article with no existing approvals is updated, the article will display the latest unapproved revision by default. Once an approval has been made, only the approved revision will display.

I feel like this belongs in the "Usage" section, maybe before (or after) the part that says: "You can eliminate automatic approvals..." because even with those codes provided, the behavior is the same - until the first approval is made. Sadgrlonline (talk) 18:51, 30 November 2022 (UTC)

Layout of page information

Where can i define the layout of the revision information?

I would like to put the information to the left side or to the bottom of the page. Thank you for your help! Goliath2m (talk) 13:53, 20 March 2023 (UTC)

Do you mean the note at the top saying "This is the approved revision", or that sort of thing? That's known as the "subtitle" of the page. I don't think there's any standard way to move it, although you may be able to move it via CSS in one way or another. Yaron Koren (talk) 17:33, 20 March 2023 (UTC)

Hello Yaron,

thank you for your answer! Yes, "This is the approved revision" or "This is the latest revision of this page; it has no approved revision." I'd like to move. As far as I got I see the only way via CSS, too.

Goliath2m (talk) 13:04, 21 March 2023 (UTC)

Exception on saving a page with an approved revision

This exception does not make it to the UI but is logged:

LogicException: The revision provided has mismatching content!
 
# 0 /var/www/html/includes/page/WikiPage.php(2012): MediaWiki\Storage\DerivedPageDataUpdater->prepareUpdate(MediaWiki\Revision\RevisionStoreRecord, array)
 
wikimedia#1 /var/www/html/extensions/ApprovedRevs/includes/ApprovedRevsHooks.php(163): WikiPage->prepareContentForEdit(WikitextContent, MediaWiki\Revision\RevisionStoreRecord, User)

wikimedia#2 /var/www/html/extensions/ApprovedRevs/includes/ApprovedRevsHooks.php(178): ApprovedRevsHooks::getUpdateForTitle(Title, MediaWiki\Revision\RevisionStoreRecord)

wikimedia#3 /var/www/html/includes/HookContainer/HookContainer.php(338): ApprovedRevsHooks::updateLinksAfterEdit(Title, MediaWiki\Revision\RenderedRevision, array)

$renderedRevision in updateLinksAfterEdit contains the revision just being saved; passing it to WikiPage::prepareContentForEdit will result in the exception when comparing its content to the approved revision.

For a fix see

https://github.com/gesinn-it-pub/mediawiki-extensions-ApprovedRevs/commit/5deb27295b55eb8fd5d0732d86fdd1cd91cc3ea4

Would be great, if someone could merge this with upstream. Planetenxin (talk) 07:11, 24 March 2023 (UTC)

Thanks for letting me know about that! I just checked in this fix. Yaron Koren (talk) 16:05, 24 March 2023 (UTC)

ApprovedRevs::getRevApprover() returns null if approver is cached

Discovered this one because SemanticExtraSpecialProperties didn't set "Approved by".

For a fix see

https://github.com/gesinn-it-pub/mediawiki-extensions-ApprovedRevs/commit/4df35dd8e1f1ac6fd5f72ae4316864787cb025e4

Mwgit (talk) 13:02, 28 March 2023 (UTC)

Ping Yaron. Would be great, if you could merge this with upstream. --Planetenxin (talk) 09:28, 18 April 2023 (UTC)

Sorry about the delay, and thanks for the patch! This is now merged in. Yaron Koren (talk) 14:29, 24 April 2023 (UTC)

ApprovedRevs::deleteRevisionApproval() should clear cache

Also discovered when working on SemanticExtraSpecialProperties.

Fixed here

https://github.com/gesinn-it-pub/mediawiki-extensions-ApprovedRevs/commit/91ba0dc3694fd6860fa65adb01964c74797964fe

Mwgit (talk) 16:23, 31 March 2023 (UTC)

Ping Yaron. Would be great, if you could merge this with upstream. --Planetenxin (talk) 09:28, 18 April 2023 (UTC)

Sorry about the delay, and thanks! This is now merged in. Yaron Koren (talk) 14:29, 24 April 2023 (UTC)

What are the Mediawiki namespace pages associated with this extension?

For example, if someone makes an edit that needs approval before going live, which Mediawiki page(s) contain(s) the messages they receive regarding the edit's need for approval before becoming live? Thanks! -- 日本穣 Nihonjoe (talk) 20:44, 24 April 2023 (UTC)

If you add "?uselang=qqx" (or "&uselang=qqx", depending on the URL structure) to any wiki page, you can see the name of any message that is displayed. You can then see the page for that message at MediaWiki:<message name>. Yaron Koren (talk) 14:16, 25 April 2023 (UTC)

Namespace filter for approveAllPages.php

I'm heavily using namespaces. I was always missing an option to mass approve existing pages only for specific namespaces.

Here's a solution: https://github.com/gesinn-it-pub/mediawiki-extensions-ApprovedRevs/commit/12e7eb30a7b0ace0c6574a649faf596d722bde8b

Multiple namespaces can be applied with pipe separated:

php maintenance/approveAllPages.php --namespaces "News|Team"

@Yaron Koren please have a look and merge it with upstream if you like it. Planetenxin (talk) 09:33, 28 April 2023 (UTC)

Thanks! I just checked in a patch based on this. I decided to limit it to just namespace numbers, instead of names, even though it might be less convenient, for the sake of consistency with MediaWiki's own scripts, like dumpBackup.php. And I changed to comma-separated instead of pipe-separated, for the same reason. But hopefully the benefit is more or less the same. Yaron Koren (talk) 20:54, 28 April 2023 (UTC)

Option to show last revision instead of last approved, Namespace support and magicword

Hi, I send you an email about a year ago but never received an answer (maybe it went to spam). In my current wiki I've changed the extension in a way to show always the last revision instead of the last approved one but with a warning on the top of the page that the content is not reviewed. But changing the extension is always bad regarding installing updates. So would it be possible to get an optional switch in LocalProperties which will create this behavior and show the last revision with a warning instead of the last approved? Default behavior should stay the same as it is.

Another topic is the support of different NS in the special pages. In my Wiki there are different people responsible for approval of pages in different NS. For this it would be great to either have one ApprovedRevs special page per enabled Namespace (currently i realised this via an additional extention on my own) or to have a kind of filter posibility to only get pages from a specific namespace.

Also i created a new magic word wich will return 0 instead of NULL for approvaltimestamp in case the page is not approved. I use this to compare the approval timestamp against the last revision timestamp to check if the page is reviewed or not (also to display this state on other pages). Maybe it would be great to have a magicword which will return the state if the last revision is approved or not.

Thanks in advance Role-end (talk) 08:06, 26 May 2023 (UTC)

The first and second are interesting ideas; that third idea, the magic word, seems unnecessary, since, as far as I know, you can already compare APPROVALTIMESTAMP to REVISIONTIMESTAMP to see if the latest revision is the approved one. Yaron Koren (talk) 17:13, 26 May 2023 (UTC)

Hi, for the first two topics it would be nice to know if they are interesting enough to become part of the extension. Otherwise I have to think about further workarounds. The code for the shown revision was not that much but the switch in LocalSettings was missing in my version. For the Special Pages I was not able to dynamically create them so I had to copy paste the whole source for every namespace. Maybe you have any idea how to resolve that.

For the magicword (which is not an important topic) I recreated the issue I had in case the the page has no approval timestamp.

The comparison function I use is:

{{#ifexpr: {{APPROVALTIMESTAMP}} < {{REVISIONTIMESTAMP}} | no |yes}}

• APPROVALTIMESTAMP:
• APPROVALTIMESTAMPN (my own word which returns 0 instead of NULL): 0
• REVISIONTIMESTAMP: 20230530121249
• APPROVALTIMESTAMP < REVISIONTIMESTAMP: Fehler im Ausdruck: Unerwarteter Operator <
• APPROVALTIMESTAMPN < REVISIONTIMESTAMP: no

Maybe there is another way to compare those values without getting this error.

Regards Role-end (talk) 10:24, 30 May 2023 (UTC)

I'm not sure I understood all the examples, but I would think something like this could work, no?

{{#ifeq:{{APPROVALTIMESTAMP}} | {{REVISIONTIMESTAMP}} | yes | no}}

As for the other two features: they both seem useful, in their own ways. I'm not planning to develop either feature myself, but if someone else were to create a patch for either one, I'd be happy to check it in. Yaron Koren (talk) 13:19, 30 May 2023 (UTC)

How do you add pages to the approval mechanism on a per-edit base?

I have installed this extension and set

wfLoadExtension( 'ApprovedRevs' );
$egApprovedRevsShowApproveLatest = true;

I was expecting that every newly edited page edited by a person without the approvervision right would require approval in the future and get listed on the special page for approval. Instead, to my great surprise, nothing happened.

I only want to approve some pages by default with the script since this does not make sense. Instead, only newly edited pages should be added to the approval mechanism.

Setting

$egApprovedRevsShowNotApprovedMessage = true;

does not help either. It just displays a message indicating an unapproved page; however, it does not trigger the page to be added to the approval mechanism.

I must have overlooked something in the documentation of this extension... 2003:F1:C742:600:8695:3F6E:52E9:3364 05:27, 6 February 2024 (UTC)

The standard way to add all relevant pages into the approval mechanism is to call the script approveAllPages.php. It sounds like, instead of doing that, what you want is that, when someone without approval permission edits a page with no approval, the second-to-last revision of the page automatically gets approved. Is that true? If so, unfortunately there's no way to do that. Yaron Koren (talk) 14:01, 6 February 2024 (UTC)

No, if someone without the approval permission edits any page, it should end up on the list of pages to be approved, with all the other pages and versions of that specific page untouched. It looks like this extension cannot incrementally start with page approvals like this. Thank you for clarifying this. 2003:F1:C742:600:8695:3F6E:52E9:3364 15:15, 6 February 2024 (UTC)

Bug when moving pages

When a user with approval rights is moving a page, the page still has to be approved. I think this is a bug. If I move an approved page as someone with approval rights, neither the new page nor the old page (carryin a redirect in case I checkt the option) should have to be approved. Tested in in MW 1.39 with the latest ApprovedRevs version. Krabina (talk) 15:02, 20 February 2024 (UTC)

I thought this was fixed already, with this change. What version of Approved Revs are you using specifically? Yaron Koren (talk) 16:43, 20 February 2024 (UTC)

yes, this change is in. Strangely, I cannot reproduce the problem anymore. So I guess it is working. Krabina (talk) 19:29, 18 April 2024 (UTC)

API for file approvals

as far as I can see, there is no mechanism to approve files using the API, is this correct 91.64.64.183 13:04, 24 October 2024 (UTC)

No, there is - it's with "action=approve". Yaron Koren (talk) 16:17, 24 October 2024 (UTC)