Extension talk:FlaggedRevs/archive 1

Initial thoughts

Here are my initial thoughts.

The contribution list for a user could include the reviews done.

The text of the box on a non-reviewed page when there is a reviewed revision could be:

 This version has not been reviewed. The latest reviewed version is
 available here.

There could also be no mention of any review notes on a non-reviewed page.

When I log in, I get the latest version. I would normally like to see the reviewed version. Perhaps there should be a user preference option to say which version is initially displayed.

Thats on the wishlist - see the specs.txt file --Jhb 19:00, 2 April 2007 (UTC)

I protected the main page but there was no message indicating that it was protected.

Also, after protection, it would not be possible for many users to edit the page which goes against the text

 The current revision is editable

These comments are pretty cosmetic.

I found no bugs. Well done. Eiler7 21:58, 30 March 2007 (UTC)

Hmm. Just found a bug.

If you visit the main page, you get one version. Click on Permanent Link you get another. Eiler7 22:42, 30 March 2007 (UTC)

This was fixed by a small change to trunk but brion reverted it. Ideally, there will be a Special:Stableversions page with an oldid= param to parse it as a stable page, as even giving the right perma-link Id can still be a tad misleading (old rev, current images and templates). Voice of All 00:36, 31 March 2007 (UTC)

I have noticed something else. If you do a change when not logged in, you arrived at the reviewed page, not the version you just created. This is unnatural. In my view, neither of these issues should hold up deployment on the English wikipedia.

I wonder if we need a requirements document. Certainly, the current interface meets my main requirement. Namely, it allows people to avoid seeing a vandalised version of a page, which happened with the Tony Blair page in an external review. See this link w:en:Wikipedia:External_peer_review Eiler7 18:57, 31 March 2007 (UTC)

When editing a page that has a stable version, the tag should probably be clear about this and suggesting the use of preview. Voice of All 23:45, 1 April 2007 (UTC)

Another thought. If reviewed versions use the current images, then this might not be a good thing. Perhaps reviewing a page should cascade to reviewing all images and templates which have no reviewed version. Eiler7 22:29, 31 March 2007 (UTC)

Reviewed pages clone the images and place them in the /stable directory.Voice of All 23:02, 31 March 2007 (UTC)

OK, that is no longer the case, they can be called directly. Aaron 19:14, 24 June 2007 (UTC)

BLP concerns

Will the threshold for displaying versions (i.e., non-vandalized, checked for accuracy, etc.) be a universal namespace setting, or can it be set for individual articles and/or classes of articles? It will be useful if this feature could support a "living person" tag for biographies of living people, and all articles with that tag have a higher threshold for public display than simply "non-vandalized". Will it be able to work that way? -- ragesoss

I understand what you are saying. I suggest that BLP pages have a different definition of vandalised. So, if the George Bush page were changed to say that he was involved in the Kennedy assassination without proof, that would count as vandalism in my book. Eiler7 11:24, 1 April 2007 (UTC)

The main issue is that it may be desirable to have a more select group of editors who can review BsLP (and things like the main page, if it becomes open to editing) than those who can review other articles. --ragesoss

I've set up two review groups, editor and review. By configuring what tags they can set to what level and what tags/levels are needed for page overriding (by the latest stable version), this can be dealt with. Voice of All 23:44, 1 April 2007 (UTC)

No reviewed revisions

I just created a page Eric Clapton and reviewed it. However, clicking on the page now, we find it says "There are no reviewed revisions of this page". This is a bad bug. Eiler7 12:14, 1 April 2007 (UTC)

Not sure why that is, but that site is still running an older version. Voice of All 17:04, 1 April 2007 (UTC)

Latest revision

I have tried the test wiki again. The Clapton page now displays with correct information. However, I think the wiki should show the reviewed version by default. Currently, it does not. The same will, I hope, apply to en.wikipedia.org when the changes are applied there. The logic is that the average viewer and the researcher will both want to do a non-vandalised version. So, this will give a better impression of the quality available through the wiki process.Eiler7 20:11, 5 April 2007 (UTC)

That only happens if the flagged rev meets "stable" critera. Depending on how it is set, "draft level" may not be good enough. This useful if one revision is featured, and one newer one is somehow "draft level", in which case we would likely want the feauted one.Voice of All 06:32, 6 April 2007 (UTC)

Well, currently the Clapton page shows the latest revision when there is a draft revision available. I think that the draft revision (read unvandalised) should be shown. Is that a setting change on the Clapton page or is this a bug? Eiler7 13:17, 6 April 2007 (UTC)

Baach.de test wiki

I have just been playing around with the test wiki again and it seems that the Main Page link in the navigation box takes one to the page Wikiversity:Main_Page. Was this intended? Eiler7 20:30, 18 April 2007 (UTC)

That is an unrelated bug. Aaron 07:39, 16 June 2007 (UTC)

Multiple flagged revisions

I haven't had the chance to play around with the extension, but I have several questions:

1. Will the extension allow for several types of revision flags? (E.g. "vandalized", "reviewed", "assessed", "featured", etc...)

   Yes. Voice of All 06:34, 4 May 2007 (UTC)

2. Will the extension allow flag sub-types (e.g. "assessed: quality: B-Class", "assessed: importance: Top", "featured: FAC: promoted", etc.)

   No pretty way to do this. Voice of All 06:34, 4 May 2007 (UTC)

   How about a couple of null fields on the table? Titoxd^(?!?) 07:13, 4 May 2007 (UTC)

3. Is this essentially stable versions?

   I guess. Voice of All 06:34, 4 May 2007 (UTC)

4. Will the extension produce a way to query articles with certain properties? (e.g. w:en:WP:1.0/I)

   The stable revisions and their overall level (stable,quality,featured) can be found at Special:Stableversions. Voice of All 06:34, 4 May 2007 (UTC)

5. Will revisions be able to be tagged retroactively?

   Yes. Voice of All 06:34, 4 May 2007 (UTC)

6. Will revisions be able to hold more than one tag simultaneously?

   Yes. Voice of All 06:34, 4 May 2007 (UTC)

7. Will pages be able to hold more than one revision tagged in a particular way?

   Yes. Voice of All 06:34, 4 May 2007 (UTC)

Titoxd^(?!?) 03:16, 3 May 2007 (UTC)

Changes submitted to trunk?

I think this is a great feature! Just 2 questions:

1. When do you think the changes will be submitted to trunk, so that this extension can be used without using a forked codebase ?
2. Are there chances this feature makes it for MW 1.11 ?

--Y.combarnous 16:48, 23 May 2007 (UTC)

Another dev will merge in FileRepo work, I'll reconcile with that and submit the revision delete code along with the parser hook stuff needed for this extension to work. This will definitetly be done by the time 1.11 is out. Aaron 02:14, 25 May 2007 (UTC)

• Great news, thanks for the quick answer.--Y.combarnous 07:25, 25 May 2007 (UTC)

Questions

1. What exactly are the differences between "editor" and "reviewer" privileges? One can be given automatically and one needs a bureaucrat so I assume they are significant differences.

   Reviewers are more trusted and can rate revisions higher. Aaron 00:32, 1 June 2007 (UTC)

   So in a really basic sense, an editor could rate a revision as "stable" but only a reviewer could rate one as "featured"? Mr.Z-man 06:48, 1 June 2007 (UTC)

2. What exactly are all the "tagging levels"?

   Customized, by default, there are four. I'll probably get an up to date demo site up soon. Aaron 00:32, 1 June 2007 (UTC)

3. Which version will be the version seen by search engines? Mr.Z-man 22:29, 31 May 2007 (UTC)

   The stable version. Aaron 00:32, 1 June 2007 (UTC)

Templates and images

How would one go about updating a template or image transcluded into many articles? Would the new version of the template have to be approved for each article? Audacity 02:14, 1 June 2007 (UTC)

Currently, each page would have to be re-reviewed. Updating images/templates in masse could case problems such as the template params/format change and break some pages or the new image version makes the caption no longer make sense (say it says "picture of east Munich, and the new version if from the west). Nevertheless, the way the schema is set up, it is possible to run an UPDATE query WHERE tmp_rev_id=x and replace it with Y, same with images, a feature that could perhaps be added later. Aaron 16:49, 1 June 2007 (UTC)

It would require an extra INDEX on the tables. Aaron 03:42, 4 June 2007 (UTC)

Error with namespaces

• Another question: I would like to cut out the links in description above in the print version, because this makes it less good viewable. But I would like to have the revision number there. Will you change this? --Wissenslogistiker 15:42, 5 June 2007 (UTC)
  • Hmm...what are you using it for? What wiki is this and where is it? </curiousness>. Aaron 16:19, 5 June 2007 (UTC)
  • I've removed tags from printable versions altogether. Aaron 16:37, 5 June 2007 (UTC)
    • Thank you, this is much better. I use wiki as organisational memory system and for creating docs for the company where i am working in. Thatswhy approved article versions have a high interest. ;-) --Wissenslogistiker 08:01, 6 June 2007 (UTC)

First I have to say that this is great stuff and an absolutly 'must have extension'. :-) Then I think that I found a bug:

• When you have an article in the standard namespace - at my wiki it is called 'Meta:Test' and it is the same as {{SITENAME}} - the rating fields are not shown below the article (error 1).
• When you have an article with no namespace the rating fields are shown. If you set it to a higher review level all is fine, but if you set it not for publishing (=lowest review level) I get: "Internal error. This action can not be used on this page.(error 2)". If you first set it to a higher and later to the lowest I get the following error message: "Fatal error: Call to a member function getNamespace() on a non-object in meta\includes\WatchedItem.php on line 26. (error 3)"

The cause can probably be that I have a wiki which is viewable only by members. --Wissenslogistiker 13:09, 5 June 2007 (UTC)

Is the meta namespace in $wgContentNamespaces? Aaron 15:10, 5 June 2007 (UTC)

OK, the getNamespace() error was fixed. Aaron 15:15, 5 June 2007 (UTC)

I reloaded Extension via SVN, did update.php. For error 1: Yes, meta namespace is as default in Defaultsettings.php part of it: '$wgContentNamespaces = array( NS_MAIN );' and '$wgSitename = "Meta";'. I did not change $wgContentNamespaces in Localsettings.php. The other ones (error 1 and 2) are solved, but I have now a different behavior: When I create the page, then approve this version, make an edit and set the prove to the lowest level it says "Internal error. This action can not be used on this page." --Wissenslogistiker 15:57, 5 June 2007 (UTC)

I can't repeat any of these errors. If you reviewed the first revision, then made a new one, you can't "unreview" the new one, only the one that was reviewed. If you try to unreview a revision that was not reviewed, it gives the error message. Aaron 22:27, 5 June 2007 (UTC)

I think this this ok, but still error 1 is there. I found out that it shows register 'project page' in Meta:Test and register 'article' in Test (=the article without namespace). Perhaps knowing these differences helps? In Special:Allpages I can select 'Meta' namespace and '(Main)' so i think namespace has been created correctly. In namespace 'Help' it does not work either. --Wissenslogistiker 08:01, 6 June 2007 (UTC)

Do you have any news about error 1? --Wissenslogistiker 11:31, 11 June 2007 (UTC)

If "meta" and "(main)" are options, then Meta is not the mainspace, and probably is not in the content namespaces array. Aaron 05:03, 13 June 2007 (UTC)

I understood now what you meant and set $wgContentNamespaces = array('Meta'); in LocalSettings.php. But the problem stays the same. I uploaded a screenshot of article Test without Namespace, Special:Allpages and article Meta:Test here. Isn't it possible to set a flag for project namespaces to have this feature too? Or do you have another suggestion what I could try to get this to work? --Wissenslogistiker 12:37, 14 June 2007 (UTC)

Haha, $wgContentNamespaces should be an array of numbers. For example NS_MAIN is a constant variable with value '0'. You need the number that corresponds to Meta. Aaron 07:37, 16 June 2007 (UTC)

Cool, that worked. Thank you for your assistance. Perhaps you can build a special page to manage the namespaces for revision in the future. :-) --Wissenslogistiker 10:44, 21 June 2007 (UTC)

Blocked users

If a user with editor rights is blocked, would editor rights be automatically stripped or would this have to be done as a separate action? Mr.Z-man 19:38, 8 June 2007 (UTC)

It would have to be manually removed, however, blocked users cannot review revisions while they are blocked, so their flag is useless while blocked. Aaron 23:17, 8 June 2007 (UTC)

1.11

Where can I get MW 1.11 to make this work? 66.31.209.239 00:25, 12 June 2007 (UTC)

You will have to use the current development version from SVN, read here: Download from SVN --Wissenslogistiker 09:16, 12 June 2007 (UTC)

Test wiki

Where is the test wiki for this feature? Thanks in advance for a link. Dovi 06:19, 14 June 2007 (UTC)

There is one here. Aaron 07:38, 16 June 2007 (UTC)

List of reviewed pages with changes

If articles have been reviewed but there are newer and unreviewed revisions, is there a way to list these articles - similar to the page Special:Unreviewedpages? --217.5.218.98 13:42, 9 July 2007 (UTC)

Note that by default, patrolled edits are enabled, and reviewed revision count as patrolled, so if you are watching the pages, you can get a good idea of this information (a watch checkbox appears on the review form). Aaron 11:47, 10 July 2007 (UTC)

Doesn't work

Hi,

Error message :

Warning: require(/home/xxx/xxx/extensions/FlaggedRevs/../ExtensionFunctions.php) [function.require]: failed to open stream: No such file or directory in /home/xxx/xxx/extensions/FlaggedRevs/FlaggedRevs.php on line 13

Fatal error: require() [function.require]: Failed opening required '/home/xxx/xxx/extensions/FlaggedRevs/../ExtensionFunctions.php' (include_path='/home/xxx/xxx:/home/xxx/xxx/includes:/home/xxx/xxx/languages:.:/usr/lib/php:/usr/local/lib/php') in /home/xxx/xxx/extensions/FlaggedRevs/FlaggedRevs.php on line 13

And it could be good to explain for beginners how to Run maintenance/archives/populateSha1.php.

Thanks. 81.53.23.145 13:58, 2 September 2007 (UTC)

Download ExtensionFunctions.php from SVN and place it under extensions/ - simple. Running maintenance/archives/populateSha1.php is just like that: you open your SSH client (like PuTTY), type in cd your-wiki-directory/maintenance/archives/ and then type php populateSha1.php. Very simple. --Sayuri 14:06, 2 September 2007 (UTC)

Thanks. But I'm sorry to tell that for beginners it's very hard to find the good informations. That's not simple at all... 81.53.23.145 14:27, 2 September 2007 (UTC)

Lastly, it is still in testing, so things may change. I wouldn't yet download for production use. But the instructions above are fairly standard for most extensions around here. Aaron 14:35, 2 September 2007 (UTC)

Ok, Works fine, thanks for your help ! 81.53.23.145 14:44, 2 September 2007 (UTC)

Any news on implementation?

Now that Wikimedia 1.11 is out, is this on the way to actually being implemented at the Wikimedia projects? Any news or updates on this? Dovi 11:29, 11 September 2007 (UTC)

Brion may do code review this week and put it up on a hidden (to be publicized site). Aaron 12:51, 12 September 2007 (UTC)

I see that this extension is still listed as experimental. I'm about to attempt implementation for an internal wiki were we need to review all changes made to articles before they go live for versioning purposes. Is this now considered stable, or what will it take to go from experimental to stable? Would you recommend implementing it as an extension, or once with Wiki code goes live? And if the second, any idea when that will be? Thanks in advance.

-Marc 10/02/07 06:35PM EST.

NM. My Bad: Lastly, it is still in testing, so things may change. I wouldn't yet download for production use. But the instructions above are fairly standard for most extensions around here. Aaron 14:35, 2 September 2007 (UTC)

Any update? 18:32, 13 October 2007 (UTC)

Tim Starling is now reviewing it. Aaron 21:38, 7 November 2007 (UTC)

Showing empty pages insteat of not reviewed page

I upgraded my wiki from 1.9.3 to 1.11, which means that all my articles ain't review yet. Now, when I load an article, a message is shown, that the article ain't reviewed yet but is shown anyway. I wanna hide the content of any not reviewed article exept for the editors or reviewers. --213.214.18.64 06:06, 28 September 2007 (UTC)

Why? Either your editors are trusted, and thus non-reviewed content should be decent, or they are not all trusted, in which case they need review...however how can you submit edits to a page you can't see? Aaron 14:05, 28 September 2007 (UTC)

Adding a parameter to only show current version of an article to editor/reviewer classes

We have a private wiki, so all users have to log-in to get into it. We would like them to only see the current stable version of an article, and that the editor/reviewer see the latest revision. Would it be possible to add a parameter to do so?

For instance a permission could do the trick: $wgGroupPermissions['editor']['seestable'] = false;

barns 14:05, 02 October 2007 (UTC)

It's funny you should mention this because this is exactly what I need as well. For the exact same purpose too. I hope this is possible. BTW, great extension. This is exactly the type of thing I needed. However, rather than go through 3 different flags, I just need an "Approved" and the ability to add comments. What would I remove with disturbing the whole extension. - Marc 10/02/07 07:43PM EST.

By default, logged in users always see the current revision, whereas outsiders see the stable one. The number of tags can be reduced to just one, like "accuracy". Aaron 00:52, 3 October 2007 (UTC)

Actually, I will change the code a tad so that the tag array can be set to "array()" (blank). Aaron 01:01, 3 October 2007 (UTC)

• Fantastic, I look forward to seeing that change.
• I think I might have misstated what I was attempting to convey. We have an internal private wiki that requires each user to log-in. Everyone who visits is a 'user'. However, only a handful of users, a 'docsteam' group, have edit/create page/etc access so they will be the editors/reviewers. In order to maintain ISO, whenever editors make multiple changes, I want to keep the stable version live, and the only version visible, for 'users' and only have the 'reviewer' be the only ones who are able to see the current version until a reviewer makes it stable. Then it goes live so all users can see it. Is that possible, or too restrictive to implement?

I've removed the "anononly" option and generalized it to a new variable to list usergroups for which members will see the current by default. Aaron 21:51, 16 October 2007 (UTC)

• Also, for keeping the document in an ISO format, we were hoping to use this tool for some additional versioning control. I've been playing around with the auto-increment in the templates, but so far the only method is every save updates the date/time it occurred. Would it be possible to add an incremental counter that could increase when an article becomes a stable version? Specifically, minor changes go up by v+.1 and major changes go by v+1.

Not sure what you mean. Aaron 21:51, 16 October 2007 (UTC)

• All-in-all, this is a fantastic extension and cannot thank you enough for making it. Please keep up the good work. - Marc 10/03/07 10:37AM EST

Weird changes on $wgFlaggedRevTabs, $wgFlaggedRevsAnonOnly and $WgFlaggedRevsOverride

If I change my LocalSettings.php like this

$WgFlaggedRevsOverride = true;
$wgFlaggedRevsAnonOnly = false;
$wgFlaggedRevTabs = true;

and visit an article, I'll see the current version of a page and an extra Tab, which directs me to the current version too.

If I change the settings to

$WgFlaggedRevsOverride = true;
$wgFlaggedRevsAnonOnly = true;
$wgFlaggedRevTabs = true;

and visit an article, I'll see the current version of a page and an extra Tab, which directs me to the stable version. This one makes more sence but i want it invers. That means:

If I visit a page, I'll see the stable version of it and an extra tab, which directs me to the current. The tab is optional but everybody that visits a page should see the stable version first instead of the current.

Is this possible with the aviable options?

Excuse my confusing description ^^ --GKittlaus 10:45, 12 October 2007 (UTC)

Before i forgot,

$WgFlaggedRevsOverride = false;
$wgFlaggedRevsAnonOnly = true;
$wgFlaggedRevTabs = true;

has the same effect like the second example. --GKittlaus 11:29, 12 October 2007 (UTC)

Do you have the latest version from SVN? There were issues with that a while ago. The first config should be right. Aaron 01:39, 14 October 2007 (UTC)

OK, the upgrade does it. thx :) --GKittlaus 05:47, 15 October 2007 (UTC)

Validate reviewed pages?

Hi, is it possible to validate a reviewed page? If I validate a page, it is stable but not validated. --213.214.18.64 12:01, 16 October 2007 (UTC)

Compatibility with other extensions live at Wikisource

Hi, I saw some discussion on the mailing lists regarding whether this extension would work properly with Extension:Labeled Section Transclusion. The latter is installed on Wikisource and heavily used.

I think FlaggedRevs is of extraordinary importance for all Wikimedia projects including Wikisource, and I would be very disappointed if it didn't work there. Can the developers of this great feature say if they anticipate any conflict, or if and where this might be tested? Dovi 20:23, 18 October 2007 (UTC)

Ask Tim to get these both set on testwiki. Aaron 02:25, 17 November 2007 (UTC)

Individual trust model?

Hi there! Maybe this is being implemented in another extension, just one that I haven't been able to locate, but I'll describe my idea here anyway ;)

So how about individual users, or groups of users, flagging revisions independently? For example, I'd like to default to revisions flagged as quality by "Scientific American" and "The Lancet" (provided these organizations were interested in flagging articles, that is). This would be in addition to the Wikipedia approved reviewers of course, as per the current FlaggedRevs.

What benefits would this system have that the current FlaggedRevs does not? First and foremost - As a user I select whom to trust myself, it is not up to any administrator on Wikipedia. Secondly - There needs be less administration on elevating people to reviewers or editors: Anyone may flag an article. Thirdly - Organizations such as universities, scientific publications, publishers and even special interest groups could create their own "issues" of Wikipedia and still offer the readers access to the bleeding edge articles. Heck, even Encyclopedia Britannica might become a set of flagged revisions :D

What drawbacks would it have? As there will be plenty of flags on many articles, database space might be an issue. For a new user, it might be hard to know who to trust (an initial set of known reviewers might be offered). Anonymous users would only be using the default Wikipedia-review flags.

Now, all this might be old stuff here, and in that case I apologize. In any case, the idea is out there and I hope something good might come off it. --90.227.100.115 09:03, 27 November 2007 (UTC)

Showing only approved pages in a compendium page

We have a number of separate articles pages, from which we then use transclusion to build a compendium page using

====[[page 1]]====
{{:page 1}}
====[[page 2]]====
{{:page 2}}
====[[page 3]]====
{{:page 3}}
====[[page 4]]====
{{:page 4}}

is there anyway to configure flaggedrevs so that the compendium page is built up from the approved versions of the four pages rather than their latest oversion.

I could obviously do it by approving the compendium page after I have approved any changes to the underlying pages but I'm wondering if there is any way to this 'automatically' so we don't have to approved the compendium pages, they are in different namespace than the articles .

John

In fact, yes it would be possible to program efficiently enough. I'll add that feature to my todo list. Basically, it would check for the stable version of templates it uses, if there are none, it would fall back to the one specified at review time. Aaron 05:56, 5 December 2007 (UTC)

Many thanks, just to complicate things, the compendium pages are in a separate namespace all:, would it work if the all: is not one of the namespaces defined in $wgFlaggedRevsNamespaces, not a serious issue as if I have to include it and review the compendium pages when they are created / edited then fine Tarlachmoorhouse 14:58, 5 December 2007 (UTC)

It will work only for reviewable pages, other pages will just be selected based on how they where when the "compendium" page was reviewed. Aaron 16:32, 5 December 2007 (UTC)

OK, did this in my last few commits. Aaron 21:32, 8 December 2007 (UTC)

Downloaded the latest version (FlaggedArticle rev 28485 etc) but it doesn't seem to work, all in one pages still show latest content rather than stable version, however I'm running MW1.11 on my test site (1.12 broke everything) would this be making a difference ?

The software does not do this by default. You will have to enable $wgUseStableTemplates. Look in flaggedrevs.php for the info on this as well as $wgUseCurrentTemplates. Aaron 18:48, 13 December 2007 (UTC)

Thanks Aaron working beautifully on my test 1.11 environment Tarlachmoorhouse 14:02, 14 December 2007 (UTC)

Watched email

I've not played so this may be the default behaviour, if a user adds a watch to a page then if it is edited then they can opt to receive an email notification, is it possible that this could be liked to the revision process, so that if the wiki is configured so that non editors can only see a default revision rather than the latest one, if they are watching a page they only get the email when the new version has been rated to the level that would make it the default revision to be viewed

Ta Tarlachmoorhouse 15:13, 5 December 2007 (UTC)

So for pages you watch, you want to know when the stable version changes? Aaron 22:40, 11 December 2007 (UTC)

Yes, rather then when an edit is done. Tarlachmoorhouse 16:21, 12 December 2007 (UTC)

Possible conflicts with other extensions

I hope this is clear when I describe it if not I'll try to set up an externally accessible wiki as an example.

Our wiki is used by people with little or no IT skills so I liked the look of 'ArticleComments' Extension:ArticleComments as it would allow me to have a small web form on the article pages that allows users to post comments to the discussion page without using the wiki editing system.

However ArticleComments requires a tag <comments /> to be added to pages that you want the form to appear on, not wanting to have to do this manually on each page, I solved this using an extension HeaderFooter Extension:Header_Footer that will add a standard header / footer to any page within a name space.

I also wanted the ability to add comments, be available only to people who have logged in, we display the following on each page if users are not logged in:-

• Log In at the top of the page to add your own comments or suggestions about this topic for other staff to read on the 'Discussion' page.

(Use the Submit Feedback link on the left it you want to contact the policy officers)

To do this I used the extension ConditionalShow Extension:ConditionalShow so I have a template :-

<cshow Logged="1" InGroup="user" >*<comments /></cshow>
<cshow Logged="0" InGroup="" >* '''Log In at the top of the page''' to add your own comments or suggestions about this topic for other staff to read on the 'Discussion' page. <br />(Use the '''[[Submit Feedback]]''' link on the left it you want to contact the policy officers)</cshow>

So basically conditional show is used to decide what to display in the footer either the comments form or the login message, based on whether the user has logged in, HeaderFooter adds this as a footer to the relevant pages, and if it's the tag <comment /> then the user gets the comments form.

Much to my surprise this all works much the same as before with two exceptions:-

1. The second condition <cshow Logged="0" InGroup="" >* '''Log In at the top of the page'''...etc doesn't seem to work any more, no message is displayed for none logged in users
2. There is a magic word __NOFOOTER__ that you add to a page in the namespace if you don't want a footer added, flaggedrevs appears to stop this being parsed. Tarlachmoorhouse 14:39, 14 December 2007 (UTC)

SVN up and try now. Some general fixes to things where done after another developer looked at it. Aaron 03:01, 21 December 2007 (UTC)

Apologies not had a chance to test since you posted - system in in work and not accessible from outside, will try in the new year Tarlachmoorhouse 18:42, 30 December 2007 (UTC)

SNVed up and still have the same problem but it appears only to be a problem when you are not logged in so the system displays the 'approved' version

Installation without populateSha1.php

Is there a way to install the extension without running the maintenance/archives/populateSha1.php script? I do not have a ssh access to the server to execute this command. --DCLXVI 00:52, 29 December 2007 (UTC)

You can install it, and it will run fine, but in the distant future, you may have to make a script to retroactively populate them if image moves are implemented. Aaron 00:11, 30 December 2007 (UTC)

FlaggedRevs + LabeledSectionTransclusion report

Playing with FR and LST on test.wikipedia I've discovered a issue:

• testwiki:PWLSTFR:Dom Casmurro (2) have one stable edition and one unreviewed edit;
• testwiki:PWLSTFR:Dom Casmurro (1) have only one unreviwed edit;
• testwiki:PWLSTFR:Dom Casmurro trancludes the two above using {{#lst|etc}} and have only one stable edition;

The result: testwiki:PWLSTFR:Dom Casmurro always render the latest edit, not the most stable one. May it is a issue on LST, not on FR, but I don't known, I've only tested it :-) 555 20:43, 31 December 2007 (UTC)

Er... if I log-out, the rendered page contains the unstable "(1)" and the stable "(2)". If I log-in, the rendered page contaisn the unstable "(1)" and unstable "(2)". Is that expected, according to the config selected on test.wp? 555 20:49, 31 December 2007 (UTC)

The behavior for the current revision of PWLSTFR:Dom_Casmurro is like how pages normally are, which is as it should be. The stable version shows as it was when reviewed, which is how it should. To get templates to be the latest stable one for that page, the site configuration would have to be changed to do so. Aaron 20:54, 31 December 2007 (UTC)

Great, thanks :) 555 21:00, 31 December 2007 (UTC)

Academic Wiki - anonymous users should see warning instead of current content

We are building up an academic wiki. Groups of students will write wiki pages. Once the entries are finished, they will be reviewed by a lecturer and marked as stable. Our problem now is that we don't want anonymous users to see the articles in the process of being written. Instead they should see a warning page like "The desired page/article is not complete yet but will be finished soon". Only logged in users should be able to see the current version. Has anyone any idea how I could achieve this? I guess I will have to modify the FlaggedRevs-Extension?!

We already had the idea that first we could write a revision of the page which reads like the warning. We then could flag this revision as stable and then begin to work on the article. The problem with this is, that the students will not be able to just start writing and creating wiki pages as they need them; instead we would have to create them for them. --StefanGrossmann 17:15, 14 January 2008 (UTC)

All pages without reviewed revisions have a disclaimer shown on them, which you can customize. If you actually want the current revision to be invisible to outsiders, then MediaWiki is not the software you should be using. Aaron 00:37, 15 January 2008 (UTC)

FlaggedRevs.pg.sql appearantly broken with PostgreSQL 8.2.6

I get this error when trying to import the PG.sql:

[Sun Jan 27 - 12:05:09] [deploy @ enterwiki] [/srv/sites/ddowiki.net/ddowiki.net/wiki/extensions/FlaggedRevs/]
-- psql ddowiki < FlaggedRevs.pg.sql
BEGIN
ERROR:  syntax error at or near "("
LINE 4:   fr_user int(5)  INTEGER      NULL REFERENCES mwuser(user_i...
                     ^
ERROR:  current transaction is aborted, commands ignored until end of transaction block
ERROR:  syntax error at or near "CREATE"
LINE 6: CREATE TABLE flaggedtemplates (
        ^
ERROR:  current transaction is aborted, commands ignored until end of transaction block
ERROR:  current transaction is aborted, commands ignored until end of transaction block
ERROR:  current transaction is aborted, commands ignored until end of transaction block
ERROR:  current transaction is aborted, commands ignored until end of transaction block
ROLLBACK

The syntax seems fine to me, but I'm not a DBA. Or even know SQL for that matter. Elliottcable 17:39, 27 January 2008 (UTC)

Got help from #postgresql, great guys in there - here's the diff to make it work with the latest SVN mediawiki: Elliottcable 17:56, 27 January 2008 (UTC)

--- FlaggedRevs.pg.sql (saved version)
+++ (current document)
@@ -6,7 +6,7 @@
 CREATE TABLE flaggedrevs (
   fr_page_id      INTEGER  NOT NULL DEFAULT 0 ,
   fr_rev_id       INTEGER  NOT NULL DEFAULT 0 ,
-  fr_user int(5)  INTEGER      NULL REFERENCES mwuser(user_id) ON DELETE SET NULL,
+  fr_user         INTEGER      NULL REFERENCES mwuser(user_id) ON DELETE SET NULL,
   fr_timestamp    TIMESTAMPTZ,
   fr_comment      TEXT     NOT NULL DEFAULT '',
   fr_quality      SMALLINT NOT NULL DEFAULT 0,
@@ -21,7 +21,7 @@
   fpc_page_id   INTEGER NOT NULL PRIMARY KEY DEFAULT 0,
   fpc_select    INTEGER NOT NULL DEFAULT 0,
   fpc_override  bool NOT NULL
-)
+);
 
 CREATE TABLE flaggedtemplates (
   ft_rev_id      INTEGER  NOT NULL DEFAULT 0 ,
@@ -33,7 +33,7 @@
 
 CREATE TABLE flaggedimages (
   fi_rev_id         INTEGER   NOT NULL DEFAULT 0 ,
-  fi_name           TEXT      NOT NULL PRIMARY KEY,
+  fi_name           TEXT      NOT NULL,
   fi_img_timestamp  TIMESTAMPTZ,
   fi_img_sha1       CHAR(64),
   PRIMARY KEY (fi_rev_id,fi_name)

... I lied. I got it installed, but I get the following error anytime I save a page, in my PHP log:

[27-Jan-2008 13:32:35] PHP Warning:  pg_query() [<a href='function.pg-query'>function.pg-query</a>]: Query failed: ERROR:  operator does not exist: character & integer
LINE 1: ...y >= 1) AND (fr_rev_id = rev_id) AND (rev_deleted & 1 = 0)  ...
                                                             ^
HINT:  No operator matches the given name and argument type(s). You may need to add explicit type casts. in /srv/sites/ddowiki.net/ddowiki.net/wiki/includes/DatabasePostgres.php on line 542

I'm pretty sure it has to do with FlaggedRevs, because of the error being around fr_rev_id. Elliottcable 18:35, 27 January 2008 (UTC)

The schema is fixed now. The problem is a bitwise operator on rev_deleted. It only works for MySQL. I'll see what I can use for PG. Aaron 19:10, 27 January 2008 (UTC)

OK, the revision table's schema needs a change. rev_deleted should be an "INTEGER NOT NULL default 0". Aaron 19:21, 27 January 2008 (UTC)

Changelog

Hi, do you have a changelog or something like that? I've updated your Extension three times on my Mediawiki, and every time I do, I have to reconfigure my SQL-Database because some Column-Names has changed, or a Variable became an array instead of a string and so on. That's frustrating! Could you please create some kind of changelog? That would do it. --213.214.18.64 10:21, 28 January 2008 (UTC)

The extension hasn't been "beta" for long. Before then, sudden changes occurred. PG support is still being cleaned up. MySQL however, will not have any random schema changes after this. Future ones will be hooked to update.php. Aaron 19:55, 28 January 2008 (UTC)

I'm looking forward to :) --213.214.18.64 13:27, 30 January 2008 (UTC)

Heh, I just added an expiration column just now in this way. Just remember to always run update.php after SVNing up. Aaron 03:58, 31 January 2008 (UTC)

different groups for different namespaces

At your personal discussion page someone asked for that topic link. This one is exactly a requirement for business wiki with different projects inside and i was searching for this. Together with the extension Lockdown it is possible. It's a little bit confusing to set up the usergroups, but after playing around a while, i got it working on my "testwiki". A short example will follow.

Sven Schneider 15:54, 1 February 2008 (UTC)

Feature?

Is it possible to revisions that was not approved by sysop be hidden, waiting sysop approval? The same thing for articles creating? If no i think it's a good feature request Lleoliveirabr 21:07, 1 February 2008 (UTC)

This is very hard do cleanly, and MW is generally not designed for partial visibility of pages of the website. Aaron 18:20, 3 February 2008 (UTC)

Ok, you can play around with $wgFlaggedRevsVisible. Aaron 02:45, 19 February 2008 (UTC)

What do non-logged in people see by default

Maybe this was answered and I'm just blind, but if "all logged-in users, even new users, are shown the most recent version", what do people who are not logged in see by default; the current version or the last tagged one? The vast majority of people reading sites like Wikipedia will not be reading it from an account. I don't like it when we pay so much attention to what logged-in people see, like Wikipedia does with date stamps.

It depends on site and page configuration. Aaron 03:42, 11 February 2008 (UTC)

Bug: PHP Fatal error: Only variables can be passed by reference

The current version of FlaggedRevs arise the following bug on PHP 5:

PHP Fatal error: Only variables can be passed by reference in /var/www/allpinouts/website/extensions/FlaggedRevs/FlaggedRevs.php on line 427

To fix this bug you have to change the line 427 of FlaggedRevs.php:

$currentOutput = $wgParser->parse($text, $article->getTitle(), ParserOptions::newFromUser($wgUser));

with:

$rtitle = $article->getTitle();
$rparseopt = ParserOptions::newFromUser($wgUser);
$currentOutput = $wgParser->parse($text, $rtitle, $rparseopt);

Nicola Asuni 217.133.31.201 10:00, 21 March 2008 (UTC)