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)


 * To summarize my babel, and my further results, I now see that the way the Bots group works (I'd never used it before), all edits by any user in that group are all marked as Bot. So, the only way to use this plugin without swamping the Recent Changes is to either have a separate Bots user, or continually add and remove my regular user from the Bots group.  From the documentation of this plugin, I had assumed this extension could be used by a normal user to make edits that would be shown as "bot", but that seems to be wrong.  Am I missing something?


 * Also, my comment above about the 10/1000 limit making no sense was unclear, I meant that when I saw how useful this plugin was for doing regex content searches, upping the preview limit to 500 makes it really handy. Also, the limit of 1000 for edits seemed odd right after the note in the same code that the max is 500 for normal users (which, at the time, I thought I could use).


 * - Steaphan Greene 15:14, 15 April 2011 (UTC)


 * Ok, the way it works is as you have discovered. Either all your edits are marked Bot, or you have to switch between two different users.  This isn't the way I wanted it to work, but it's due to limitations in the MW API at the time of writing.  I still do not know if there is a way around it - the way I would like it to work is that normal edits are unchanged, but any edits done using MassEditRegex are marked as Bot.  If you know of a way this can be done, let me know.  Re the preview and edit limits, these are set to (hopefully) avoid any unpleasant surprises for unsuspecting wiki admins.  I should make them $wg variables so they can be more easily changed in LocalSettings.php, as this may be desirable when you either have a small number of admins using it, or you are able to monitor your server load and tweak appropriately. -- Malvineous 00:15, 25 April 2011 (UTC)


 * I have this working in my own wikis, but (as you say) it required modifications to the actual wiki code. Specifically, in includes/api/ApiEditPage.php, I changed the line:
 * To this:
 * And I re-activated the permission check in this extension, but to search for the new "botedit" privilege instead of just "bot". I also made a few other changes to the wiki code so this new privilege would work more cleanly.  This works great, but, of course, this is not portable just as an extension.
 * I also modified the other settings (and a few others) to use $wg variables. Would you like me to post these changes here as a patch?  If so, I could also modify my group test changes to use a $wg variable.  That way, the extension would still work as it does normally (no check), but could be changed with just a $wg variable to support a custom group, for those who choose to make this change to the api code.  Then, at least, no code mods would be required for the extension to be used in either the default way, nor the hackish way in which I am using it.  All of my changes would still default to the current behavior if $wg vars are not set in LocalSettings.php.
 * Steaphan Greene 00:06, 29 April 2011 (UTC)
 * I also modified the other settings (and a few others) to use $wg variables. Would you like me to post these changes here as a patch?  If so, I could also modify my group test changes to use a $wg variable.  That way, the extension would still work as it does normally (no check), but could be changed with just a $wg variable to support a custom group, for those who choose to make this change to the api code.  Then, at least, no code mods would be required for the extension to be used in either the default way, nor the hackish way in which I am using it.  All of my changes would still default to the current behavior if $wg vars are not set in LocalSettings.php.
 * Steaphan Greene 00:06, 29 April 2011 (UTC)


 * Any new about this issue ? For me the problem is above all that any user (even not belonging to bot group) is able to use this dangerous extension. So I'm very interesting in any solution. --Varlin 21:11, 7 June 2011 (UTC)