User talk:Lupin/Anti-vandal tool

This page is for discussing Navigation popups and reporting bugs you encounter with it. Please be aware that the original author of Lupin Anti Vandal Tool (Lupin) is no longer active on Wikipedia. As such this tool is currently unmaintained. All issues are handled at the discretion of other experienced editors.

Not sure how to explain your problem clearly? Read How to Report Bugs Effectively for some general pointers. If you have trouble with the script, please mention your browser, browser version and operating system.

Archives

1, 2, 3, 4, 5, 6

Filter recent changes works in FF again

So, I'm not sure if it's due to the changes mentioned above, or whether Mozilla redid the Firefox regex engine again, but Filter Recent Changes now works in Firefox as of FF 10.0.2. —Darkwind (talk) 16:38, 9 March 2012 (UTC)[reply]

Red coloring in diff display

So for a while now, the diff display in AVT has not been coloring the added/removed text in red. Turns out this is because MediaWiki moved the CSS for diff display to a separate call to load.php, which is not loaded unless you're viewing an actual diff page.

To resolve this, and restore the red coloring in diffs in AVT, you can add the following CSS code to your common.css (or vector.css or whatever), with no linebreaks:

table.diff,td.diff-otitle,td.diff-ntitle{background-color:white}td.diff-otitle,td.diff-ntitle{text-align:center}td.diff-marker{text-align:right}td.diff-lineno{font-weight:bold}td.diff-addedline{background:#cfc;font-size:smaller}td.diff-deletedline{background:#ffa;font-size:smaller}td.diff-context{background:#eee;font-size:smaller}.diffchange{color:red;font-weight:bold;white-space:-moz-pre-wrap;white-space:pre-wrap;text-decoration:none}table.diff{border:none;width:98%;border-spacing:4px; table-layout:fixed}table.diff td{padding:0}table.diff col.diff-marker{width:2%}table.diff col.diff-content{width:48%}table.diff td div{ word-wrap:break-word; overflow:auto}

—Darkwind (talk) 01:55, 10 March 2012 (UTC)[reply]

While adapting the script for Portuguese Wikipedia, I found some bugs in the MediaWiki code which formats the RSS feeds (~~34798~~ [fixed] and 34800) which I believe may be affecting the coloring of the diffs used by this script. I think it should be migrated as soon as possible, to stop using something like

en.wikipedia.org/w/index.php ?title=Special:Recentchanges &feed=rss &action=purge

to get the list of recent changes, and start to use the API to get lists (in JSON) such as these:

Helder 00:21, 11 March 2012 (UTC)[reply]

I absolutely agree that the script should be converted to use the API as soon as possible -- it will be more responsive, less resource intensive, and so on. However, that's not the cause of the diff problem (although the problem might go away after conversion, it probably won't as long as the script is run by viewing a User: page).

The current problem is that although the diffs are already being returned with the correct <span> wrappings with the right CSS classes to display the diff colors (i.e. span.diffchange.diffchange-inline), there's no CSS style information included on the page for those classes.

There is specific CSS styling in the MediaWiki software for diff color display. In the past, this CSS was downloaded for every page request. However, at some point, the decision was apparently made to stop providing that particular stylesheet unless the URL being requested contains a &diff= argument. To be more specific, the following HTML tag only appears when you actually view a diff by using a (diff) link: <link rel="stylesheet" href="/en.wikipedia.org/load.php?debug=false&lang=en&modules=mediawiki.action.history.diff&only=styles&skin=vector&*" type="text/css" media="all" />. That tag does not appear on User:Lupin/Filter recent changes because the server thinks it's not actually a diff page, which means the diff-specific stylesheet never gets loaded.

The workaround is to force the issue by copying the CSS style information from that sheet to your common.css (or $skin.css, whatever). Doing this means the CSS classes already being used by AVT would now have the corresponding style information, and the diffs are magically red again. It's probably possible to trim down that style info from what I provided (I just pasted the whole of the stylesheet in question), but it's an effective workaround. —Darkwind (talk) 10:08, 11 March 2012 (UTC)[reply]

Actually, this is just a dependency issue: any gadget or user script which depends on a module (e.g. "mediawiki.action.history.diff") should indicate this explicitly in order to allow the Resource Loader to make sure that the content of the module (in this case, mediawiki.action.history.diff.css) is available. You can check this by typing the following on Google Chrome console (other browser may have similar tools):

mw.loader.load('mediawiki.action.history.diff');

(it will insert the <link> tag you have mentioned). Since the AVT is not a gadget, some part of it should be wrapped in

mw.loader.using('mediawiki.action.history.diff', function(){
    /* Here goes the AVT code */
});

Helder 22:51, 11 March 2012 (UTC)[reply]

Actually, the above will not work, because the Mediawiki RSS feeds for some reason contain hard-coded "style=" attributes instead of using the CSS classes to format the diffs; even if the correct CSS stylesheet is loaded, the hard-coded font colors and other styles will still be used. The only real solution seems to be to convert to using the API instead of the RSS feed. --R'n'B (call me Russ) 16:21, 17 May 2012 (UTC)[reply]

Filter IP Edits

Is it possible to include an option to filter edits only made by IP users? Thanks. FrigidNinja (talk) 12:20, 7 February 2013 (UTC)[reply]

Yes, there is. User:Lupin/Recent IP edits is what your looking for. However, Lupin doesn't seem to have been active since September 2009... jcc (tea and biscuits) 19:52, 1 June 2013 (UTC)[reply]

"Recent IP edits" is not filtered using the regexes a la "Filter recent changes". I think FrigidNinja (t c) was asking for an option that combines "Filter recent changes" with "Recent IP edits", which does not presently exist. TBQH, I doubt there will ever be any future substantial changes to this tool, because if it gets reworked to any degree, it should be converted to API, and that's just more effort than it's probably worth. —Darkwind (talk) 00:25, 2 June 2013 (UTC)[reply]

Updating Lupin??

I noticed today that occasionally when I do a 'rollback' on Lupin the edit appears to save. I then leave a warning on the editors page if necessary. However today I found several times that my edit rollback wasn't the one that went through - it didn't report an edit conflict but it was another editor who made the correction and also left a warning on the users page. So there were 2 warnings for the single edit. I have since then taken to checking that it was my edit before leaving the warning but it seemed to be a new situation, not one there a few days ago... Can anyone comment?-- 🍺 Antiqueight ^confer 18:34, 20 October 2013 (UTC)[reply]

Are you using the "non-admin rollback" option in the tool? —Darkwind (talk) 06:55, 23 October 2013 (UTC)[reply]

Yes - I started using the tool before I had rollback. If I turn off non-admin rollback will that make the difference? I'll try it out later -- 🍺 Antiqueight ^confer 08:48, 23 October 2013 (UTC)[reply]

Well - that certainly worked quickly. I'll have to pay lots of attention not to rollback in error!! But thanks - I hadn't thought of that.-- 🍺 Antiqueight ^confer 11:18, 23 October 2013 (UTC)[reply]

Also, if you use TW, if you open the vandal's talk page from the rollback success window, the Warn window will pre-populate with the vandalized article/page name. It doesn't automatically populate if you open the talk page directly from the anti-vandal tool. —Darkwind (talk) 19:58, 23 October 2013 (UTC)[reply]

Yeah - I have discovered I prefer to use TW for warnings rather than the Lupin tool - it lets me do the various levels as well. But I only discovered the tool prepopulates yesterday or today....Yesterday I think. Some of these tools are very clever and I just wish I had the skill to put all my favourite bits together into one! I am currently overdosing on tools :-)-- 🍺 Antiqueight ^confer 20:27, 23 October 2013 (UTC)[reply]

One of the modifications I added to PILT was to report the names of articles where my revert had been successful, so that I don't end up warning vandals I hadn't reverted myself. I think Antiqueight will find that although switching to MediaWiki rollback speeds things up, so that he has more chance of winning the race, the problem of someone else having got there first will remain. Philip Trueman (talk) 09:40, 24 October 2013 (UTC)[reply]

Idea for Anti-Vandal tool!

Hey Lupin,

I have an idea for your amazing Anti-Vandal tool: Verify that different things are closed off, like quotations, apostrophes, perentheses, brackets, etc. For example, if you were quoting Homer (the Greek poet):

Homer is a Greek poet, who is well-known for writing poems. One of his poems (The Iliad starts off, "Sing, O goddess, the anger of Achilles son of Peleus, that brought countless ills upon the Achaeans.

People using your Anti-Vandal tool would receive a message on your Anti-Vandal page saying that there are an odd number of parentheses and quotations. The user would add a closed parenthesis after "Iliad" and add a quotation mark after "Achaeans".

Regarding possession (for example, "Newyorkadam's") there is correctly a single apostrophe. If you were to implement this idea, the checker would ignore apostrophes before or after an 's'.

Thanks! Newyorkadam (talk) 23:41, 21 October 2013 (UTC)Newyorkadam[reply]

This would require a new mode of the tool to be written, since the "filter recent changes" mode uses regular expressions, which are computationally incapable of matching brackets/braces/parentheses. If someone wanted to go to the effort of making a new mode of the tool, I think the effort would be better spent converting the script to use the MediaWiki API instead.

Also, for well-meaning editors, there is already a bot which checks for unbalanced {, [, and ('s. If it finds an edit that results in unbalanced brackets of some kind, it leaves a message on the talk page of the user who made the edit. It doesn't do quotes, but it still lets people know if they accidentally make such a change. If you want to get a live feed of the bad edits BracketBot finds, there's apparently an IRC channel it streams to. —Darkwind (talk) 20:10, 23 October 2013 (UTC)[reply]

Thank you very much for the information! :) Newyorkadam (talk) 03:19, 7 November 2013 (UTC)Newyorkadam[reply]

Lupin's tool rewrite (sort of)

As per some of the discussions above, I tried my hand at updating Lupin's tool to use the API instead of the RSS feed, but ran into several difficulties. Lupin wasn't very reliable at commenting his code, so it's hard to follow in places. Also, unlike the RSS feed, the API doesn't provide a mode that provides a list of recent changes along with diffs for each edit -- you have to download the list of changes, then download each diff individually to match against the badwords list, which completely screws with the flow of Lupin's code.

I decided it's basically easier to start over again, so I've re-implemented the basic functionality as Darkwind's Anti-Vandal Tool. It's still in a very early stage of development (the only mode currently is equivalent to "filter recent changes"), but it's usable, and I'd appreciate any feedback and/or suggestions you all may have. You can read more about it and get installation instructions at User:Darkwind/DAVT. —Darkwind (talk) 05:45, 1 November 2013 (UTC)[reply]

Not working

Recently, I see no pages when I start the Anti-vandal Tool. I have to refresh the tool over and over to get it working. What could be going on? Cache problem? I tried Control + F5 but that doesn't help.- Gilliam (talk) 13:09, 29 January 2014 (UTC)[reply]

Same. I just discovered that on the revision history page of the tool, at the bottom the filter works and runs fine. It obviously isn't optimal, but it works for now. -Newyorkadam (talk) 13:32, 29 January 2014 (UTC)Newyorkadam[reply]

Thanks! I would not have thought to look there.- Gilliam (talk) 13:46, 29 January 2014 (UTC)[reply]

It seems to be working fine now. -Newyorkadam (talk) 20:00, 30 January 2014 (UTC)Newyorkadam[reply]

Suggestion

Hello, I have a easy suggestion for Your Anti-Vandal tool, Could you add a option to ignore words that are put in between Reference Tags? There have been a lot of instances where I look into a word and i see that it is in A reference. Thanks,

Happy Attack Dog (Bark! Bark!) 13:47, 13 May 2014 (UTC)[reply]