Extension talk:Approved Revs

Approved revs+ Translate extension=not working?
Hi, I am using Mediaiwki ver 1.19.2 with both Approved revs and Translate extension installed. I am having problem that unapproved changes are being published. All changes made on source page are being published regardless if its approved or not. It seems like Translate extension "blocks" Approved revs functionality. Anyone having the same problem? Can you use these two extensions together?


 * Do things definitely work correctly if the Translate extension is temporarily un-installed? Yaron Koren (talk) 17:35, 22 January 2013 (UTC)


 * After a lot of testing I come to this conlusion:

If adding Semantic Bundle require_once.. etc -statements for Approved revs before Translate-extension in my Localsettings.php the approve function is blocked out somehow and always shows latest revision even if not approved. If adding Translate first and Approved revs after the function "mark this page for translation" is blocked out on page. But approved version is working. So there is some kind of mismatching :/


 * Alright. But to re-ask my question: does Approved Revs work for you if Translate is not there? Yaron Koren (talk) 14:01, 24 January 2013 (UTC)

-Yes, only a problem when together with Translate.


 * Okay - and are you using the latest versions of both Approved Revs and Translate? Yaron Koren (talk) 15:47, 25 January 2013 (UTC)

Wrong page cached when saves made (1.19+)
I encountered what appears to be a bug when using ApprovedRevs in 1.19+.

When you save a page, the *APPROVED* page is the one that is cached for the current revision, instead of the current revision. This results in any attempt to view the current revision as seing the approved revision. Very confusing.

It appears this happens because of the behavior of ApprovedRevsHooks::setApprovedRevForParsing, since that function (erroneously, I believe) returns the approved revision text as the page save text (to make sure links and properties are saved).

(I've elided the patch provided by the OP, which is still available in the archive. --66.162.23.2 20:50, 11 February 2013 (UTC))


 * Sorry for the long delay on this. I finally tested this out, and I couldn't see a problem. Assuming you're still reading this - can this be reproduced consistently, or does it only happen sometimes? Yaron Koren (talk) 01:00, 4 January 2013 (UTC)


 * I'm not the OP, but I've just started using this extension and I can consistently reproduce it on MW 1.19.2 with ApprovedRevs 0.6.4. My ApprovedRevs are set up to apply to just one namespace. If you create a page in this namespace, then approve that revision, the latest revision is the approved revision and everything works as expected. However, if you then create one or more unapproved revisions, the "latest revision" link always shows the approved revision instead of the latest revision. However, if you use the revision browsing links to move back one revision, then forward one, the correct revision is displayed. The problem doesn't seem to consistently happen when the latest approved revision isn't the first revision for the page. --66.162.23.2 17:43, 6 February 2013 (UTC)
 * The problem persists in MW 1.20.2. Also, further testing indicates that this seems to consistently occur; it doesn't matter if the latest approved revision is the first revision or not. A notable feature about my wiki is that I use PHP wincache (via $wgMainCacheType = CACHE_ACCEL) and the file cache; this bug may not replicate without those on. I also cache load.php through IIS's dynamic output cache, though I don't really see how that would have any effect. --66.162.23.2 23:13, 6 February 2013 (UTC)


 * Okay. If it's not too much work, could you try temporarily disabling wincache (I doubt the other caches are involved) and see if the problem still happens? Yaron Koren (talk) 23:20, 6 February 2013 (UTC)


 * Interestingly, the problem seems to persist even with $wgMainCacheType = CACHE_NONE. --66.162.23.2 16:20, 7 February 2013 (UTC)


 * Reviving this discussion from the archive, as the problem still persists despite disabling the cache... which is rather odd. --66.162.23.2 20:50, 11 February 2013 (UTC)