Extension talk:MassEditRegex/Archive

Overviews and tutorials
Overviews:


 * Regular expression (Wikipedia)

Tutorials:


 * Using Regular Expressions by Stephen Ramsay, Electronic Text Center, University of Virginia]


 * The 30 Minute Regex Tutorial By Jim Hollenhorst

PHP implementation (to understand how this extension is implemented):
 * preg-replace.php PHP function (part of the Regular Expressions (Perl-Compatible))

Removing a category
To the left (input regexp): /\[\[Category:.?[tT]echnologies\]\]/

To the right:
 * (hit return)

Note:
 * Enclose the regexp in '/.../'
 * '.?' will test for an empty space between the ":" and the category
 * '[tT]' means that the "t" character can be either lower or upper case

I tested this regexp (and extension) in my MW version 1.15.0 with about 250 articles, it works :) - Daniel K. Schneider 17:56, 8 July 2009 (UTC)

Interaction with $wgSpamRegex
Not a bug really, but a feature request. You get a fairly ugly (and useless) error message if you happen to have the standard MW anti-spam filter on and it finds a positive. Would be cool to ignore the error, print out the name of the non-editable page instead, and move on to the next page. Unexpected non-MediaWiki exception encountered, of type "UsageException" spamdetected: Your edit was refused because it contained a spam fragment: ``cialis''


 * 1) 0 /data/portails/mediawiki/includes/api/ApiBase.php(830): ApiBase->dieUsage('Your edit was r...', 'spamdetected')
 * 2) 1 /data/portails/mediawiki/includes/api/ApiEditPage.php(220): ApiBase->dieUsageMsg(Array)
 * 3) 2 /data/portails/mediawiki/includes/api/ApiMain.php(420): ApiEditPage->execute
 * 4) 3 /data/portails/mediawiki/includes/api/ApiMain.php(220): ApiMain->executeAction
 * 5) 4 /data/portails/mediawiki/extensions/MassEditRegex/MassEditRegex.class.php(301): ApiMain->execute
 * 6) 5 /data/portails/mediawiki/extensions/MassEditRegex/MassEditRegex.class.php(41): MassEditRegexForm->execute
 * 7) 6 /data/portails/mediawiki/includes/SpecialPage.php(559): MassEditRegex->execute(NULL)
 * 8) 7 /data/portails/mediawiki/includes/Wiki.php(229): SpecialPage::executePath(Object(Title))
 * 9) 8 /data/portails/mediawiki/includes/Wiki.php(59): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
 * 10) 9 /data/portails/mediawiki/index.php(116): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
 * 11) 10 {main}

Btw, the bad word was "Specialist" and not "cialis"... had to fix the regexp variable :)

- Daniel K. Schneider 14:05, 9 July 2009 (UTC)

Error with MW 1.15
When the last version (r4), my MW 1.15 in Windows broke with some internal error related to the aliases in the extension. Returning to the version 67467 of MassEditRegex.alias.php instead of the 73322 solved the problem.
 * Alberto --62.87.120.116 11:57, 26 October 2010 (UTC)

Problems with MW 1.16
The edits do not show up as "Bot" edits, they just swamp the recent changes list with regular edits (and you can't make them minor). I'm guessing this is a change with the call to FauxRequest, but, unfortunately, I can't find the right documentation to know how to just fix this myself. Anyone have any pointers?

Also, the preview limit of 10 combined with an edit limit of 1000 makes no sense. I set them both to 500, and all seems well. Now the preview in this tool is actually the best search I've seen for MW. :)

- Steaphan Greene 22:30, 5 April 2011 (UTC)


 * I will test it with MW 1.16 and see if I can reproduce the problem. Are you editing with a normal user or a bot-only user?  I'm not sure what you mean by the preview limit being lower than the edit limit as making no sense - the preview is designed to give you a quick idea whether the regex is working correctly (you are 'previewing the regex'), it is not supposed to preview every possible change (you are not 'previewing the final edits') as there could be a large number of them and it will put a heavy load on the server.  It should be clear within 10 or so previews whether the regex is doing the job correctly. -- Malvineous 12:45, 7 April 2011 (UTC)


 * I am using a normal user (who, incidentally, is actually not even in the Bots group, now that I look into it - is that the problem here?) to perform these regex edits.


 * Yes, adding my user to the Bot group fixed this problem. I presumed I was already in the group, as the docs say only members of that group can use this extension.  So it seems the problem is actually that it doesn't require this group membership as claimed. - Steaphan Greene 18:55, 9 April 2011 (UTC)


 * Indeed. To be clearer, what I meant was that the preview seems to be lightning fast, while the actual edits take forever.  So, I didn't think it made sense to so greatly limit the speedy preview, while allowing such a large max to the slower edits.  Sorry for the confusion.  Of course, I can see why having only a small preview limit is useful when used for just that (and not a power-search, as I now use it for).
 * - Steaphan Greene 16:55, 9 April 2011 (UTC)