Extension talk:Approved Revs

"Approval status" SMW property lags when using SESP
Please help me determine if the following behavior is a result of Semantic Extra Special Properties (SESP) [1] or Approved Revs (AR) [2].

I'm running:
 * MediaWiki 1.30.0 (830bb58) 16:58, 8 December 2017
 * Approved Revs 0.8.0 (28c6ce0) 17:46, 10 August 2018
 * Semantic Extra Special Properties 2.1.0-alpha (6deea72) 03:01, 17 December 2018

The behavior is:
 * 1) The "Approval status" property does not appear in the "Browse Properties" list of properties for new pages or any page that has no approval history.
 * 2) The "Approval status" property does not appear in the "Browse Properties" list of properties for new pages with only the creation edit that have been approved.
 * 3) The "Approval status" property only appears in the "Browse Properties" list of properties after an edit has been made after approving the page.
 * 4) The "Approval status" property does not update to the current approval status until after an edit has been made after approving or disapproving the page.

'''In general. the "Approval status" of pages in SESP relies on subsequent edits to "push" the new approval status to SESP.'''

How can this be made to respond correctly? Thank you, User:revansx

[1] https://www.mediawiki.org/wiki/Extension:Approved_Revs

[2] https://www.mediawiki.org/wiki/Extension:Semantic_Extra_Special_Properties


 * Sounds like a SESP issue. Yaron Koren (talk) 03:36, 15 February 2019 (UTC)

Fatal error: Call to undefined method WikiPage::prepareTextForEdit
Fatal error: Call to undefined method WikiPage::prepareTextForEdit this is an error I am getting when editing the page as an user, but as an admin I can still see the user wanted to edit the page and can approve the page the user wanted to edit.


 * What line of code is that happening in, do you know? Also, what versions are you running of MediaWiki and Approved Revs? Yaron Koren (talk) 20:12, 28 March 2018 (UTC)


 * The latest version 0.7.3 but I just edit the codes with $editInfo = $page->prepareContentForEdit( new WikitextContent( $text )); in line 77 but now it auto approved I think because whenever the user edit the page it just saves automatically.


 * Oh, I see, you were using code from when 0.7.3 was released about a year ago, but then you just changed that line to match its current form. (I'm planning to release a new version very soon, by the way.) If you think there's a problem with approvals, let me know. Yaron Koren (talk) 17:14, 30 March 2018 (UTC)

Query Approval Data
I would like to know how to query approval data. For example, I would like to have a table display a list of pages (using #ask) and have it display the date of last approval.

I would also like to display the approval date within the body of the page similar to how you can display -- natively.

Is this possible?


 * No, there's no way to do either. Why do you want to display those? Yaron Koren (talk) 13:31, 1 May 2018 (UTC)


 * Our wiki needs to comply with some ISO requirements to show revision number and publication dates. If this could be done in a more automated fashion based on approved revisions, that would be fabulous.


 * Can't you just use REVISIONDAY, REVISIONMONTH, REVISIONYEAR and REVISIONID for those (assuming the ID is what you mean by the number)? Do those not show the correct data? Yaron Koren (talk) 13:15, 2 May 2018 (UTC)

Update to 0.8 fails on Postgres
The update to 0.8 fails on a Postgres database because the new column approver_id is of type "int unsigned", which does not exist in Postgres. Obviously a fresh installation of 0.8 would fail for the same reason.

I removed the "unsigned" from the SQL script, and everything seems to be working now.--RV1971 (talk) 11:49, 9 May 2018 (UTC)


 * Sorry about that! I removed the "unsigned" from the two SQL files. Really I should have created a new patch for the change, but hopefully this is good enough. Yaron Koren (talk) 16:22, 9 May 2018 (UTC)

Remove namespaces from ApprovedRevsNamespaces
In my wiki, some of the namespaces included by default in ApprovedRevsNamespaces should not be subject to approval because edit on these pages is limited to a small group of people distinct from those writing the actual content. The main inconvenience of having unwanted namespaces here is that they pollute the "Unapproved pages" list on the special page, making it almost useless.

Is there any means (other than patching extension.json) to remove namespaces from this variable? If not, a good solution could be to re-implement ApprovedRevsNamespaces the same way as in .--RV1971 (talk) 12:25, 9 May 2018 (UTC)


 * Yes, you can remove namespaces. The easiest way is just to reset the value - if you want only the main and "User" namespaces to be handled, for instance, you could put the following after the inclusion of Approved Revs:


 * Yaron Koren (talk) 16:25, 9 May 2018 (UTC)
 * I'm afraid this does not work because settings in LocalSettings.php are merged with those in extension.json.--RV1971 (talk) 12:50, 11 May 2018 (UTC)

Problems after CSV_Import
When I use the CSV import of the Extension:Data_Transfer then all imported pages get "unapproved" even if the person importing has admin rights. This is a bug I guess.

Furthermore we have the problem that every entry shows up in the list 4 times: https://www.geschichtewiki.wien.gv.at/Spezial:Best%C3%A4tigte_Versionen even if the resulting pages show up as approved: https://www.geschichtewiki.wien.gv.at/Gedenktafel_Heinrich_Maier

Fortunately, the approveAllPages.php script fixes that, but it is not very convenient having to run this after every import... I am using the latest version of Approved Revs on MW 1.27 --Krabina (talk) 07:25, 6 August 2018 (UTC)

How to handle transclusions?
Hi, I'm switching from FlaggedRevs to AR, and I'm wondering how config of which version of a transcluded page to use works. For example we have a News page in Project ns where I want the most recent version to be transcluded, even if it's unapproved, but for templates I want a version to be approved before it's used elsewhere. Is this possible to config based on namespace or with a parser function? Thanks --RheingoldRiver (talk) 17:26, 27 August 2018 (UTC)


 * No - if some revision of a page is approved, that approved revision is what is used everywhere, including for transclusions. Yaron Koren (talk) 22:53, 27 August 2018 (UTC)

Approved pages show up as unapproved
Hi, I am currently facing some difficulties using your Approved Revs extension. After some changes in LocalSettings.php configuration, all approved pages show up unapproved although their log histories tell otherwise. The LocalSetting changes included reimporting the SemanticBundle extension and the configuration of extra namespaces via SemanticMediaWiki extension. I know that I could run the 'approveAllPages' maintenance script, but this creates unwanted localhost entries in the log history and erases the information about the original approver and approval date. Any ideas on my problem? Thanks in advance!


 * What version of Approved Revs and MediaWiki are you running? And what were the relevant LocalSettings.php changes? Yaron Koren (talk) 15:49, 26 September 2018 (UTC)


 * I'm running Approved Revs version 0.7 and MediaWiki version 1.24.1. The LocalSettings.php changes were: Deletion of SemanticBundleSettings.php and SemanticBundle.php import (require_once) and instead importing SemanticMediaWiki.settings.php with $smwgNamespaceIndex = 200. Some pages were moved (via moveBatch.php) from Mainspace to newly created namespace Property. After that there was no possibility to approve pages at all and I reinstalled SemanticBundleSettings.php and SemanticBundle.php. The functionality is now back but the pages are marked as unapproved.


 * You really shouldn't use Semantic Bundle any more - it's very old software. (Including a very old version of Approved Revs - 0.7 is from four years ago.) My guess is that what happened is that, as part of the uninstalling of Approved Revs, the database table it uses, called "approved_revs", got deleted - and then when you re-installed it, the DB table was re-added but now empty. Which means that all record of which pages are approved was lost - other than those log entries. You can check that by checking the approved_revs table, if you have access to the database. If that's the case, then you have to re-approve all those pages in one way or another - sorry. Yaron Koren (talk) 16:38, 26 September 2018 (UTC)


 * The database is not deleted, but the page_ids have been shifted somehow, which is why the scripts are not able to find the connection via id. I'll have to figure out how to match those ids again. Thanks for helping me!

Help making "wgRevisionId" a magic word
Hi,

I'm using Extension:Approved Revisions [1] and I have a need to be able to display the revision ID of the page revision currently being viewed. From the MW Manual page on Javascript [2] I see that the variable "wgRevisionId" contains this information and is exposed to mediawiki for use, but it is not clear to me how to do so. I would like to create a "magic word" [3] called  that outputs the revision ID of the revision being viewed such that it can be used in other parser logic

For example:

Can someone please help me identify the way to make a magic word that contains the value of "wgRevisionId"?

Thank you! -Rich User:revansx

[1] https://www.mediawiki.org/wiki/Extension:Approved_Revs

[2] https://www.mediawiki.org/wiki/Manual:Interface/JavaScript

[3] https://www.mediawiki.org/wiki/Help:Magic_words

UPDATE/SOLVED - 2018-10-25 - HexMode explained to me that placing the revision id of the revision that the user is presently viewing (rather than simply the latest) would actually break the whole caching systems. He helped me realize that what I'm trying to do is best done in Mediawiki:Common.js. That said, I was able to write a simple JS line like this:  in Mediawiki:Common.js and get the information I needed into a wiki article (with a corresponding   in the page). Cool!

Is it possible to require approver to have edit right for the namespace in order to approve a page revision in that namespace?
I'm using multiple custom namespaces to organise pages for different projects. There will be different groups of people responsible for different projects. Currently, the permission 'approverevisions' grants an approver the ability to approve revisions in all namespace, regardless of whether the approver is a member of the group that has edit permission for the particular namespace that the page is in. Is there a way to control this? --theys (talk) 05:31, 6 November 2018 (UTC)

Use of deprecated method ArticleAfterFetchContentObject in MW 1.32.x
I get the following warning in debug mode in MW 1.32.x with this extension now.

Use of ArticleAfterFetchContentObject hook (used in ApprovedRevsHooks::showBlankIfUnapproved) was deprecated in MediaWiki 1.32.

Chiefgeek157 (talk) 03:19, 23 March 2019 (UTC)


 * This may be a challenge, because there's no obvious replacement for ArticleAfterFetchContentObject. The closest thing, I think, is ArticleRevisionViewCustom, which may or may not be helpful. It was only added in MW 1.32, though, and I'm not yet running that version, so this may take a while to fix. Hopefully they won't remove ArticleAfterFetchContentObject any time soon. Yaron Koren (talk) 17:35, 15 April 2019 (UTC)

Misleading Message
I’m just getting started with Approved Revs and loving it. One problem: when you are looking at an older revision, the first message below says you are looking at the latest revision. The next message indicates it’s not. This is confusing and potentially misleading.

This could lead the user to edit an out-of-date version. Although the user would get a warning that they were editing an out-of-date version, they could choose to ignore it because it conflicts with the erroneous information they have received, and they might choose to believe the erroneous information.

Is there any way to keep the conflicting messages from happening short of turning off the messages?

Thanks for a great extension, BTW.

This is the latest revision of this page; it has no approved revision.

Revision as of 11:07, 3 March 2019 by ‪Greg.Fuller‬ (talk | contribs) (diff) ← Older revision | Latest revision (diff) | Newer revision → (diff) Gregoryfu (talk) 12:32, 22 April 2019 (UTC)


 * That's a bug - sorry about that. I guess I hadn't done much testing with the $egApprovedRevsShowNotApprovedMessage setting. I just checked in what I think is a fix for this. Yaron Koren (talk) 16:07, 23 April 2019 (UTC)

If a page has an approved revision and a user selects to edit with VE or source, the user is sent to edit the approved revision instead of the current revision
I'm experiencing this on:


 * MW: 1.32.1 (8e4f995)
 * SMW: 3.0.0
 * AR: 1.0 (b2f77fb)
 * VE: 0.1.0 (e82e120)

A user navigates to a page that has an approved revision and a link to view the current revision of the page. If the user selects to edit the page with Visual Editor or source, the page loads the approved revision instead of the current revision to edit. Before the edit links would always send the user to the current revision to edit. Is there a way to select a preference for which revision to edit?

Thanks in advance,

V brooks (talk) 17:15, 24 April 2019 (UTC)


 * That's very strange... it's definitely a bug, because the user should always be sent to edit the latest revision. Does the edit page that is linked to contain "oldid=" in the URL query string? Yaron Koren (talk) 18:21, 24 April 2019 (UTC)

Data is being set from latest, unapproved page
Hi, I've come across an issue with Approved Revs 1.1 and 0.8, that wasn't present in 0.5.9.

Simplest way to reproduce on a new, otherwise clean wiki:
 * load ApprovedRevs and set
 * create page with ; it falls in category 1
 * edit to change contents to ; it falls in category 2
 * approve the first version of the page; it falls in category 1
 * edit to change contents to ; it falls in category 3.

When Semantic Mediawiki is installed, similar behaviour is seen with  and. I haven't extensively tested, but it might also appear when setting

Tested on multiple wikis, running MW 1.32.2 or MW 1.27.7

TIA for looking into this! --DWizzy (talk) 15:22, 19 June 2019 (UTC)


 * Yes, I am seeing that behavior too. Are you sure that this happens with AR 0.8 but not with AR 0.5.9, regardless of the MediaWiki version? If so, that's a still a big gap to try to narrow down, but it's a good start. Yaron Koren (talk) 17:19, 21 June 2019 (UTC)


 * Thanks for looking into it. The problem doesn't appear on MW 1.19 using AR 0.7.2 (the last version to support MW 1.19). I can't get my hands on a MW between 1.19 and MW 1.27 right now to test intermediate versions. MW 1.27 requires AR >= 0.8. --DWizzy (talk) 12:29, 25 June 2019 (UTC)


 * Any updates on this? YOUR1 (talk) 11:15, 8 July 2019 (UTC)


 * It appears this problem happens on all installs,  doesn't play a role. Even when no further configuration is set; if any user changes an approved page, the latest unapproved version's values are used. This makes the impact of this issue quite high to me. --DWizzy (talk) 10:54, 11 July 2019 (UTC)

Follow up to question about Approved Revs and email notification
I'd like to follow up on the previously-raised question about email notifications and how they work with Approved Revs, here. I'm currently running MW 1.31.1 with AR 1.0-alpha (I haven't updated to the latest version 1.1 yet), with email notifications enabled. The current behaviour is that a user watching a page will get an email notification when the page is modified, whether or not the latest revision is approved. Is that the expected behaviour? At some point in the past, the behaviour was that the user watching the page will only get an email notification AFTER the revision has been approved. What ware the changes? I'd like to go back to the previous behaviour, primarily because most of the users of our wiki are straight up "consumers" of information. They couldn't care less about unapproved changes. I'd like to make it so that they would only receive email notification of the changes to a watched page AFTER the changes have been approved. --Tommy H. (talk) 00:03, 29 June 2019 (UTC)