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  (via  ) 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 ) wrap   with   - 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 . 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 . 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:

in  contains the revision just being saved; passing it to   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)