Extension talk:FlaggedRevs

Jump to navigation Jump to search

About this board

Archives 


Silkwood (talkcontribs)

MediaWiki1.34.0 (ae6e0c0)

Flagged Revision – (784dad


Hi,

can someone explain to me what does this mean?

Undefined index: excludeLastDays in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 78

It appears every time I run the update maintenance script (and other related stuff).


Thanks.

Ciencia Al Poder (talkcontribs)

Looks like $wgFlaggedRevsAutopromote doesn't contain the 'excludeLastDays' key.

If you've defined $wgFlaggedRevsAutopromote in LocalSettings.php be sure you define it correctly and without clearing the entire array

Silkwood (talkcontribs)

Hi,

for the benefit of complete and detailed information, the warnings were all these:

PHP Notice:  Undefined index: excludeLastDays in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 78

PHP Notice:  Undefined index: excludeLastDays in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 93

PHP Notice:  Undefined index: totalCheckedEdits in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 97

PHP Notice:  Undefined index: excludeLastDays in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 98

PHP Notice:  Undefined index: maxRevertedEditRatio in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 101

PHP Notice:  Undefined index: neverBlocked in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 104


but thanks to your clue, I found out that in /var/www/w/extensions/FlaggedRevs/ there is beautiful README file that reads like this:


In 1.34 the autopromote config was removed from the default. If you want to keep the same config

add the following to your LocalSettings.php

<source lang="php">

$wgFlaggedRevsAutopromote = [

        'days'                  => 60, # days since registration

        'edits'                 => 250, # total edit count

        'excludeLastDays'       => 1, # exclude the last X days of edits from below edit counts

        'benchmarks'            => 15, # number of "spread out" edits

        'spacing'               => 3, # number of days between these edits (the "spread")

        'totalContentEdits'     => 300, # edits to pages in $wgContentNamespaces

        'totalCheckedEdits'     => 200, # edits before the stable version of pages

        'uniqueContentPages'    => 14, # unique pages in $wgContentNamespaces edited

        'editComments'          => 50, # number of manual edit summaries used

        'userpageBytes'         => 0, # size of userpage (use 0 to not require a userpage)

        'neverBlocked'          => true, # username was never blocked before?

        'maxRevertedEditRatio'  => 0.03, # max fraction of edits reverted via "rollback"/"undo"

];

</source>

I did changed my LocalSettings.php and now everything is fine with FR.

Perhaps the installation/configuration instructions deserve some attention and some updates.

Thank you so much @Ciencia Al Poder

Ciencia Al Poder (talkcontribs)

I find funny to see a README file with wiki syntax (that can't be rendered nicely in any text editor btw) but then devs fail to update that documentation on the wiki page... Maybe @Reedy can check if the instructions are correct, since it seems he was the author of those changes in the README

Reply to "What does it mean?"

Remove tags from $wgFlaggedRevsTags

1
Zagy (talkcontribs)

Hi,

it used to be possible to set $wgFlaggedRevsTags to some value and that would be used for the tags. Since some release arrays defined in LocalSettings are merged with the array defined in extension.json and there seems to be no way to remove a value anymore.

FlaggedRevs itself does even support an empty $wgFlaggedRevsTags, but there seems no way to set this anymore.

Any hints?

Reply to "Remove tags from $wgFlaggedRevsTags"

Move FlaggedRev staus via XML-Dump into another wiki

2
Heinrich krebs (talkcontribs)

I tried to dump my wiki into an XML and import it into a fresh installation. But FlaggedRevs weren moved too.

I used mediawiki's onboard maintenance scripts.


How would I fix that...?

Osnard (talkcontribs)

Unfortunately the out-of-the-box tools of MediaWiki allow only to export "the lastest stable version", but not "all revisions with their flags". Additionally, the import does not know anything about flags.

Reply to "Move FlaggedRev staus via XML-Dump into another wiki"

Any way to get the review status of a page via API?

2
Dalba (talkcontribs)

I want to protect some pages using `action = stabilize`, but I need to check for their current status (expiray, reason, level, etc.). Is there any way to get these info using API?

Dalba (talkcontribs)

How do I $wgFlaggedRevsExceptions = [ '*' ]; works?

2
181.55.114.245 (talkcontribs)

I've set $wgFlaggedRevsExceptions = [ '*' ]; for everyone see the latest edit. But this doesn't work.

181.55.114.245 (talkcontribs)

I've resolved this. I used $wgFlaggedRevsOverride and I set this to false.

$wgFlaggedRevsOverride = false;

Reply to "How do I $wgFlaggedRevsExceptions = [ '*' ]; works?"

How to make stable version by default ?

4
201.217.152.82 (talkcontribs)
84.253.4.90 (talkcontribs)

actually it should be enough to simply set

 $wgDefaultUserOptions['flaggedrevsstable'] = false; 

to true; found in \extensions\FlaggedRevs\FlaggedRevs.php

The bad thing about this solution is, that the users could change this behaviour in their preferences.

Dadai12 (talkcontribs)

In case someone runs into the same problem with MW 1.20 or 1.21.

I set the default user options like described above:

$wgDefaultUserOptions['flaggedrevsstable'] = true; 

It worked, but I got an error when I tried to access the preferences with some users (they had the default settings for FlaggedRevs):

Fatal exception of type MWException 

My solution was to set the default options to this:

$wgDefaultUserOptions['flaggedrevsstable'] = 1;

Maybe there was a change since the above solution was written. Hope this helps. :-)

64.251.40.242 (talkcontribs)

Apologize if I am reviving the old question but want to check if there is a better way than changing the default user option for this question...

Reply to "How to make stable version by default ?"

Pages automatically become "unchecked" after some time

3
RheingoldRiver (talkcontribs)

Is this a feature of FlaggedRevs? Is there any way I can disable it? Generally on my wiki if pages aren't edited for a long time it means they don't need to be updated, not that they need to be checked again. I'm not 100% sure things are being marked unchecked but it seems like they are.

Tacsipacsi (talkcontribs)

It’s certainly not a feature, I don’t face with it on Wikimedia sites (mostly Hungarian Wikipedia). Is your wiki public? If yes, could you cite a specific page which has become unchecked?

RheingoldRiver (talkcontribs)

It is public, mostly there have been some category pages which I'm pretty sure were checked & later on aren't checked. That said I don't have a page that I'm 100% certain this is happening to so I will reply again if I'm certain.

Reply to "Pages automatically become "unchecked" after some time"

Show non-checked page version until review = quality or higher

5
198.214.211.107 (talkcontribs)

This extension could be very useful to my agency, if I can get the configuration set to meet our requirements. I followed the instructions for restricting unapproved revisions, which almost works for my purposes. I have multiple tags, and my wgFlaggedRevsTags array is set such that each tag requires a level 2 in order to be considered "quality". The behavior I'd like to see is that each tag is controlled by a different reviewer, and only when all reviewers have set level 2, and we have "quality" achieved, is the revised page shown to anonymous users. Instead, what I see is that when any of the tags reaches level 2, putting the page into a "checked" state, the page is then displayed to anonymous users prior to the "quality" state being reached. How might I go about fixing this?

198.214.211.106 (talkcontribs)

It looks as though there is not an available configuration option that I can set to modify the default behavior from accepting draft revisions (i.e. less than quality) as reviewed/stable. I can work around the need for having each reviewer control different levels on different tags, but I really need the viewable versions for anonymous users to only show once quality or pristine levels are reached. Having pages viewable after they have just been checked, but not yet reached quality will not work for my purposes. Can anyone help suggest what modifications I might try to this extension in order to get what I'm after? Many thanks.

Aaron Schulz (talkcontribs)
Bruno Spy (talkcontribs)

In fact the issue is not "how to not show unstable versions" but how to have stable versions only if a tag has reach a certain level.

For exemple, with only one tag with 3 levels Draft-Verified-Approved : how to tell the extension to consider that "Verified" is not a stable state and thus not shown by default (with $wgFlaggedRevsOverride = true)

193.5.216.100 (talkcontribs)

Is there any update to this? I have the same question:

3 Levels: Draft - Verified - Approved. Only Approved shall be considered as stable, how to achieve this?

Setting is "status" => array('levels' => 2, 'quality' => 3, 'pristine'=3).

Currently all pages having status "Verified" are considered as "stable".

Reply to "Show non-checked page version until review = quality or higher"

Is there any attempt, to improve the usability in the next time?

1
RichardHeigl (talkcontribs)

FlaggedRevs is a powerfull tool, but for users beyond Wikipedia you easy lost the orientation. This starts with the fact that when comparing versions I only come back to the page via the article tab, this goes on with unclear labels and missing design. It's a pity that this great and popular expansion on the surface is still so weak. Can we help to move the issue forward? Is there a roadmap?

Reply to "Is there any attempt, to improve the usability in the next time?"

How to disable "template/file changes in this version are pending review"

6
RheingoldRiver (talkcontribs)

Is there any way to do this? If the template/file itself has been reviewed already or was done by someone with Editor permission, I don't need to review the change again on the page where it's transcluded/embedded.

Tacsipacsi (talkcontribs)

And this message shouldn’t appear in that case, only if a non-trusted user edited a used template or file, and that edit hasn’t been reviewed yet. If it’s not the case, please report the bug on Phabricator.

RheingoldRiver (talkcontribs)
Tacsipacsi (talkcontribs)

I know this problem (though I have never reported it as a bug). To be honest, I think there’s no good solution for this problem – I see three possible options: the current one, where you have to mark each page using images from the central image repository as checked, another one is the ability to mark individual images stored in the central repo as checked, including ones that are never actually used on this wiki, and the third is to not require flagging for images of the central repo, which means that not all content will be checked, and vandals can overwrite images with anything with a lower risk of being reverted before anyone could see it.

RheingoldRiver (talkcontribs)

Could I just totally disable the "pending changes for included files or templates" notice altogether? I know that's not a good option in general but it would work for my wiki - we have Pending Changes more to protect against well-intentioned but incorrect content page updates and rarely have to deal with vandalism or any template edits at all.

Osnard (talkcontribs)
Reply to "How to disable "template/file changes in this version are pending review""