Extension talk:MassEditRegex/Archive

Examples and regexp tutorials

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))

How to write at the beginning of the article?

In the examples, there is "/$/" to write at the end of an article (I can't find that in regex documentations, is it built in MessEditRegex ?) But how to write at the beginning of an article ? Edit : with "/^/" --Varlin 20:16, 31 July 2011 (UTC)

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)

Bugs

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''

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

$retval = $ep->internalAttemptSave( $result, $wgUser->isAllowed( 'bot' ) && $params['bot'] );

To this:

$retval = $ep->internalAttemptSave( $result, ( $wgUser->isAllowed( 'bot' ) || $wgUser->isAllowed( 'botedit' ) ) && $params['bot'] );

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)

small bug in German localization

There is a small bug in the German localization. In the translation for masseditregextext there is a space in front of the link, which results in the link not being shown properly. Also the sentence sounds like it is missing a fragment. So in MassEditRegex.i18n.php: in the segment $messages['de'] = array( the line.

'masseditregextext' => 'Gib einen oder mehrere reguläre Ausdrücke (eine pro Zeile) für die Suche an, und einen oder mehrere Ausdrücke um einen jeweiligen Treffer zu ersetzen. Der erste Such-Ausdruck wird bei Übereinstimmung durch den ersten Ersatz-Ausdruck ersetzt, und so weiter. Siehe [ http://php.net/manual/de/function.preg-replace.php der PHP-Funktion preg_replace ()] für Details.',

should become

'masseditregextext' => 'Gib einen oder mehrere reguläre Ausdrücke (eine pro Zeile) für die Suche an, und einen oder mehrere Ausdrücke um einen jeweiligen Treffer zu ersetzen. Der erste Such-Ausdruck wird bei Übereinstimmung durch den ersten Ersatz-Ausdruck ersetzt, und so weiter. Siehe [http://php.net/manual/de/function.preg-replace.php die Dokumentation der PHP-Funktion preg_replace ()] für Details.',

Link to the translatewiki for those who have sufficient rights to edit the label: http://translatewiki.net/w/i.php?title=MediaWiki:Masseditregextext/de&action=edit&loadgroup=ext-masseditregex&loadtask=view --Frog23 11:38, 10 August 2011 (UTC)

Hi Frog23. Thanks for your reference. I've taken your correction. If you want in future to translate system messages, at best you requesting translator rights. The first steps might help you. Regards, SVG 17:27, 22 September 2011 (UTC)

Solution of permissions problem in 1.16/1.17

I've fixed the permissions problem to access "Special:MassEditRegex". The permission masseditregex must now be given to access this special page. Blocked users are also not allowed to access Special:MassEditRegex (if a sysop is blocked the access for Special:MassEditRegex is denied). Use this code in MassEditRegex.class.php. A translation of 'right-masseditregex' should be created.

[code removed for brevity -- Malvineous]

Regards, SVG 09:38, 2 August 2011 (UTC)

In addendum: The following text should be added in MassEditRegex.php

// Needed to use Special:MassEditRegex
$wgAvailableRights[] = 'masseditregex';

SVG 09:45, 2 August 2011 (UTC)

Thanks for the fix - could you post a diff instead? (preferably e-mailed to malvineous@shikadi.net) Otherwise I can't merge it in with the existing code! -- Malvineous 11:03, 2 August 2011 (UTC)

Problem with Backreferences

The example substitution suggests that backreferences should work: substituting /hello (.*)\n/ with goodbye \1 should replace "hello Fred\n" with "goodbye Fred", right? But it actually replaces it with "goodbye \1". Can this be fixed? -- RBK 15:47, 25 May 2012 (UTC)

• $1 works.

PHP Error

I'm getting the following error when attempting to execute, nothing found on google.

Fatal error: Class 'DerivativeRequest' not found in C:\xampp\htdocs\wiki\extensions\MassEditRegex\MassEditRegex.class.php on line 445

MediaWiki 1.18.1
PHP 5.3.8 (apache2handler)
MySQL 5.5.16

I rolled back to r4 and just get a blank white screen, no changes made.

Any suggestions would be great. Thanks
-Luke, 28 November 2012

Obsolete or will this be moved to git?

Presently the extension seems to be only on the wikimedia svn, which I understand will be retired (see: Git/Conversion/status: "The MediaWiki SVN repository was made read-only on January 25, 2013").

Will this extension be moved to git or not? --194.94.56.11 09:49, 10 May 2013 (UTC)