Extension talk:Approved Revs

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!