Extension talk:Replace Text

Jump to navigation Jump to search

About this board

Issiegainsley (talkcontribs)

Could you help me diagnose this error?

I have run the update.php script.

[5d452609228b03e4bc6380de] /index.php?title=Special:ReplaceText Wikimedia\Rdbms\DBQueryError from line 1699 of D:\inetpub\wwwroot\BDD\includes\libs\rdbms\database\Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?

Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'INTEGER) = old_id) ORDER BY page_namespace, page_title LIMIT 250' at line 1 (localhost) Function: ReplaceTextSearch::doSearchQuery Query: SELECT page_id,page_namespace,page_title,old_text FROM `page`,`revision`,`text`,`slots`,`content` WHERE (old_text LIKE '%business%' ESCAPE '`' ) AND page_namespace = 0 AND (rev_id = page_latest) AND (rev_id = slot_revision_id) AND (slot_content_id = content_id) AND (CAST(SUBSTRING(content_address, 4) AS INTEGER) = old_id) ORDER BY page_namespace, page_title LIMIT 250 Backtrace:

  1. 0 D:\inetpub\wwwroot\BDD\includes\libs\rdbms\database\Database.php(1683): Wikimedia\Rdbms\Database->getQueryException(string, integer, string, string)
  2. 1 D:\inetpub\wwwroot\BDD\includes\libs\rdbms\database\Database.php(1658): Wikimedia\Rdbms\Database->getQueryExceptionAndLog(string, integer, string, string)
  3. 2 D:\inetpub\wwwroot\BDD\includes\libs\rdbms\database\Database.php(1227): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)
  4. 3 D:\inetpub\wwwroot\BDD\includes\libs\rdbms\database\Database.php(1907): Wikimedia\Rdbms\Database->query(string, string, integer)
  5. 4 D:\inetpub\wwwroot\BDD\includes\libs\rdbms\database\DBConnRef.php(68): Wikimedia\Rdbms\Database->select(array, array, array, string, array)
  6. 5 D:\inetpub\wwwroot\BDD\includes\libs\rdbms\database\DBConnRef.php(313): Wikimedia\Rdbms\DBConnRef->__call(string, array)
  7. 6 D:\inetpub\wwwroot\BDD\extensions\ReplaceText\src\ReplaceTextSearch.php(64): Wikimedia\Rdbms\DBConnRef->select(array, array, array, string, array)
  8. 7 D:\inetpub\wwwroot\BDD\extensions\ReplaceText\src\SpecialReplaceText.php(303): ReplaceTextSearch::doSearchQuery(string, array, string, string, boolean)
  9. 8 D:\inetpub\wwwroot\BDD\extensions\ReplaceText\src\SpecialReplaceText.php(172): SpecialReplaceText->getTitlesForEditingWithContext()
  10. 9 D:\inetpub\wwwroot\BDD\extensions\ReplaceText\src\SpecialReplaceText.php(73): SpecialReplaceText->doSpecialReplaceText()
  11. 10 D:\inetpub\wwwroot\BDD\includes\specialpage\SpecialPage.php(600): SpecialReplaceText->execute(NULL)
  12. 11 D:\inetpub\wwwroot\BDD\includes\specialpage\SpecialPageFactory.php(635): SpecialPage->run(NULL)
  13. 12 D:\inetpub\wwwroot\BDD\includes\MediaWiki.php(307): MediaWiki\SpecialPage\SpecialPageFactory->executePath(Title, RequestContext)
  14. 13 D:\inetpub\wwwroot\BDD\includes\MediaWiki.php(940): MediaWiki->performRequest()
  15. 14 D:\inetpub\wwwroot\BDD\includes\MediaWiki.php(543): MediaWiki->main()
  16. 15 D:\inetpub\wwwroot\BDD\index.php(53): MediaWiki->run()
  17. 16 D:\inetpub\wwwroot\BDD\index.php(46): wfIndexMain()
  18. 17 {main}
Jonathan3 (talkcontribs)

I don't know.

Maybe just comment out the wfLoadExtension( 'ReplaceText' ); line while running update.php.

If it works all right, reintroduce the line and check again.

If it still doesn't work, get the latest extension code and see if that works.

I've not upgraded to MW1.35 yet as it seems that quite a few things don't work with it.

2601:446:4400:700:91F9:3433:1352:6C25 (talkcontribs)

Good to know about 1.35. I will abandon for now.

2601:446:4400:700:91F9:3433:1352:6C25 (talkcontribs)

Thank you!!

Jonathan3 (talkcontribs)

P.S. When I moved my wiki (MW 1.34.1) to a new server (using MW 1.34.4) I had to comment out a few extensions to avoid errors in the update script. Can't remember which. It all worked again fine in the end.

Ciencia Al Poder (talkcontribs)
Peculiar Investor (talkcontribs) (talkcontribs)

We are using MySQL 8 (talkcontribs)

8.0.17 to be exact.

Gunnar.offel (talkcontribs)
Ciencia Al Poder (talkcontribs)

The problem is, it won't be fixed if it's not reported properly...

Michele.Fella (talkcontribs)

For MW 1.35, on <yourwikipath> /extensions/ReplaceText/src/ReplaceTextSearch.php

replace the following:

                 $conds = [


                         'page_namespace' => $namespaces,

                         'rev_id = page_latest',

                         'rev_id = slot_revision_id',

                         'slot_content_id = content_id',

                         'CAST(SUBSTRING(content_address, 4) AS INTEGER) = old_id'



                 $conds = [


                         'page_namespace' => $namespaces,

                         'rev_id = page_latest',

                         'rev_id = slot_revision_id',

                         'slot_content_id = content_id',

                         'CAST(SUBSTRING(content_address, 4) AS SIGNED) = old_id'


Gunnar.offel (talkcontribs)

yeah, this change is what i linked before.

Henryfunk (talkcontribs)

The patch works beautifully, thanks.

For what it is worth, this is not an issue with MW1.35 as such, for on my local test installation (MW 1.35 / PHP 7.4.12 / MariaDB 10.4.16), the bug doesn't occur. However, it did occur on my live wiki (MW 1.35 / PHP 7.4.11 / MySQL 5.7.31-0ubuntu0.18.04.1) before I patched it.

MyWikis-JeffreyWang (talkcontribs)

Looks like this is an issue with MySQL 8 then? Got the same issue on MW 1.35.0, PHP 7.4.3, MySQL 8.

Henryfunk (talkcontribs)

No, for it also occurs with MySQL 5.7.31.

Peculiar Investor (talkcontribs)
Reply to "MW 1.35 Replace Text 1.4.1"
YOUR1 (talkcontribs)

When you got the following text on a page

{{#ask|?=#=Foobar da}}

and use search/replace values with regex enabled: ((\?=#=([a-zA-Z0-9_ ]*))) => ?=$3#

the text becomes

{{#ask|?=#Foobar da}}

instead expected text:

{{#ask|?=Foobar da#}}

Any workaround for this?

MvGulik (talkcontribs)

It seems to me your running into the sames issue I explored here

Ciencia Al Poder (talkcontribs)

Because [a-zA-Z0-9_ ]* ends in an *, it means zero or more. Apparently, the regexp is lazy and blindly stops at "zero" matches, meaning it matches only ?=#= and not any more text.

You should add another character after that expression that must be present, for example |:

((\?=#=([a-zA-Z0-9_ ]*\|)))
Reply to "Possible bug"

How to remove lines starting with pipe symbol "|" on Wiki pages?

Sochin67 (talkcontribs)

Dear all,

I have some redundant information in my Wiki which I would like to clean up and remove.

I'm talking about an SMW attribute named "Titel". Each page in my wiki has this attribute.

So my task is to remove a line as follows on each page:

|Titel=Some individual text...

So the search string should be something like: |Titel.*

which I would then replace with an empty string.

Unfortunately this search gives me a database error:


[X@287-FSfWJq11TyEbd5ZgAADQA] /index.php?title=Spezial:Text_ersetzen Wikimedia\Rdbms\DBQueryError from line 1603 of /www/htdocs/w00997ce/hvg-wiki-2020-03/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?

Query: SELECT page_id,page_namespace,page_title,old_text FROM `page`,`revision`,`text`,`slots`,`content` WHERE (old_text REGEXP '|Titel=.*') AND page_namespace = '0' AND (rev_id = page_latest) AND (rev_id = slot_revision_id) AND (slot_content_id = content_id) AND (SUBSTRING(content_address, 4) = old_id) ORDER BY page_namespace, page_title LIMIT 250

Function: ReplaceTextSearch::doSearchQuery

Error: 1139 Got error 'empty (sub)expression' from regexp (localhost)



Root cause of this issue seems to be the pipe symbol, if I leave this out it seems to work.

However, I need to remove the entire line incl. the pipe symbol on each page.

Does anybody have a hint how to overcome this problem?

Many thanks!

Tenbergen (talkcontribs)

You need to "escape" the pipe. I think it's done as \| in regular expressions but have not tested it with ReplaceText right now. Tenbergen (talk) 14:31, 31 December 2020 (UTC)

Sochin67 (talkcontribs)

Dear Tina,

thanks for your feedback!

I tried it with a search for the following string:


The DB error is gone.

However, unfortunately only the string from the search field ("|Titel=") is removed but the rest of the line remains.

I also tried this without the escape + pipe (just "Titel=.*") and the result is the same.

So for some reason the wildcard functionality is not working correctly.

Do you have any idea concerning this issue?

Many thanks!

Dinoguy1000 (talkcontribs)

You need some character or string which is guaranteed to be after the wildcard, to force the regex to match the whole line. Probably the simplest, if you're certain the parameter will have an entire line to itself, would be something like \|Titel=.*\n. Another suggestion would be if it's always followed by another parameter, in which case you could match a second pipe: \|Titel=.*\|, though note that this will require you to replace with a pipe instead of an empty string, and will also not work correctly if piped links can appear in the "Titel" parameter.

Sochin67 (talkcontribs)

It worked with \|Titel=.*\n - thank you very much!!

MvGulik (talkcontribs)

Cool. Did not know missing support for \n was added/fixed.

Two other cents, to find any and all variations. (assuming one template parameter per line)
Search: "(?i)(\n) *\| *tItEl *=.*\n"
Replace: "$1"

Reply to "How to remove lines starting with pipe symbol "|" on Wiki pages?"

Suggestion: adding an option to the replaceAll.php script to add changes to job queue like the special page

MyWikis-JeffreyWang (talkcontribs)

While using Replace Text to make a massive amount of changes to a wiki (25,000+ pages), the database would die often because of the massive amount of stress it's being put under.

I tried using both the CLI script and Special:ReplaceText. The problem with the CLI script is if it dies, when it's being re-run, it has to restart and do a SELECT SQL query to search for all the pages to replace again. If the CLI script keeps dying, it becomes really, really inefficient to keep doing this SQL query, especially if you increase the limit from 250 to say 1000.

The benefit of the job queue is if it dies, it can pick right up from where it left off. Furthermore, the SELECT query only needs to run once. And usually the SELECT query won't die, but if it does, it's more probable it will succeed than all 250+ changes to the database.

Perhaps it would be better to add an option in the CLI to allow the option to add the pages to be replaced to the job queue, just like the special page?

Sorry if this is the wrong place to make the suggestion, I can move it to Phabricator or somewhere else if that's preferred.

Yaron Koren (talkcontribs)

Sorry for the delay. This is certainly an option... one other option is to add some flag to replaceAll.php that would let you set a "wait" period between one replacement and the next - say, one second. (Which, for 25,000 pages, would add about 7 hours to the overall running time.) Or, the script could run replacements in batches of 100 and then wait some time between each batch and the next. Any thoughts on those different approaches?

MyWikis-JeffreyWang (talkcontribs)

Thanks Yaron for the reply! I was able to get through 25,000+ changes in less than 7 hours. Here's my experience:

  • Trying to do a SELECT for all 25,000+ changes to be made also crashed the DB. So maybe doing one big SELECT won't work either.
  • SELECT for 1000-2000 at a time worked well. The limitation here is you'd need to run the job queue before doing another SELECT, but this still works decently well.
  • The job queue would still often crash, but at least all the jobs ran beforehand did not have to be repeated.

I ended up just setting $wgReplaceTextResultsLimit to 1000 and entering the same query using the web form each time, then running through the job queue. So the most annoying part was entering the same query 10+ times into the form.

I think running replacements in smaller batches would be the most prudent approach. This is what Special:ReplaceText already does anyway, and it works really well.

Here's some pseudocode I thought of, which would've worked perfectly in my case:

  • Add a flag to specify how many (let's call this amount n) to do at a time (essentially an equivalent to $wgReplaceTextResultsLimit for the replaceAll.php script)
  • SELECTthe first n
  • run php maintenance/runJobs.php
    • if stderr returned, sleep(5) and then call php maintenance/runJobs.php again
    • keep running until exit code 0 returned and job queue finished
  • Loop back, SELECT the next n and repeat until SELECT query empty

The goal here is to minimize the number of times that php extensions/ReplaceText/replaceAll.php has to be called from the shell, or at the very least making sure it is able to handle sudden interruptions.

Yaron Koren (talkcontribs)

That's good to know that even the SELECT query by itself can crash the server. Given that, maybe the best solution is just to add a "limit" flag to the script, to let you limit each run to some number of replacements? Would using the job queue still be necessary at that point?

MyWikis-JeffreyWang (talkcontribs)

I would still prefer the job queue because let's say we SELECT 100, we run through 25 changes, and then the script crashes. If using the job queue, we can just finish the last 75 changes. Whereas if we didn't use the job queue, we would select another 100, presumably including the 75 changes, which kind of wastes the computing effort in from the first SELECT. TL;DR: Not using the job queue means more redundant SELECTing. Though I suppose it would not make too much of a difference if the limit is set at a reasonably low number, so it is probably fine to not use the job queue, since that'd be easier to code. In that case, my only hope is that the script can loop the select/replace n pages each time (n = limit flag), so there's no need to call the script 100 times.

Yaron Koren (talkcontribs)

Oh, that's very interesting - it sounds like it's really just the SELECT that's causing the problem for you. If so, that might make the solution very easy - no need for a new "limit" parameter, just have the script do, say, 100 replacements at a time, and keep going until there are no more replacements to be made, rather than trying to do them all at once. Would that work? And if so, what's a reasonable number of replacements to do each time?

Reply to "Suggestion: adding an option to the replaceAll.php script to add changes to job queue like the special page"

"Replace text in page titles" dependency on "Replace text in page contents" result. (?)

MvGulik (talkcontribs)

If "Replace text in page contents" is disabled, OR it could not find a match.

Than (if used) "Replace text in page titles, when possible" will always fail to find any matches too.

v1.4.1 (also seen with earlier versions)

Bug, or intentional ?

If intentional, I don't mind understanding why.

ReplaceText: 1.4.1
MediaWiki: 1.31.0
PHP: 7.0.30-0+deb9u1 (fpm-fcgi)
MariaDB: 10.1.26-MariaDB-0+deb9u1
Sokote zaman (talkcontribs)

As a person who has used this plugin many times and am satisfied, I say that this plugin is very sensitive. This means that if you enter a space after the text and the original text does not have the distance or line, you will be faced with the problem of finding the text. So you have to insert exactly the text you want to find, without any lots, even a lot of distance. Hopefully it will be functional my tips. best regards

MvGulik (talkcontribs)

> Hopefully it will be functional my tips.

Nope. I have no problems with "Replace Text"'s input, or with RE for that matter. It is as I stated, on this side.

Now if you have contrary data to add, I'm all ears. As it might be that there is some local(MW-site) part that plays a role in this. But I doubt that at this moment.

MvGulik (talkcontribs)

Odd. Had a case where I first did the all the target page-text replacing. And after that I did a leftover page-title change (same change as with text part). Which worked without issues. Seems there is something else also playing a role here ...

- (both actions where done with all name-spaces selected)
- (both actions where done within a short time period. (a few minutes))

MvGulik (talkcontribs)
ReplaceText: 1.4.1
MediaWiki: 1.31.0
PHP: 7.0.30-0+deb9u1 (fpm-fcgi)
MariaDB: 10.1.26-MariaDB-0+deb9u1
- "Use regular expressions" (on)
- "Replace text in page titles, when possible" (on)
-- Others: Off.
Search: "(?i)test file"
Replace: ""
Result: Target found.
Search: "(?i)test file"
Replace: "Test File"
Result: Target not found.
(Ok. Could be because there would be no effective change ...)
Search: "(?i)test file"
Replace: "foo/bar"
Result: Target not found.
(... not so in this case though)
Settings change:
- "Use regular expressions" (off)
Search: "Test File"
Replace: "foo bar"
Result: Target found.
Search: "Test File"
Replace: "foo/bar"
Result: Target not found.
(Guess that rules this particular behaviour out as a RE-only related undocumented-feature/issue)
Reply to ""Replace text in page titles" dependency on "Replace text in page contents" result. (?)"

I got "Wikimedia\Rdbms\DBQueryError" when I use "?" in regex.

Libattery (talkcontribs)

I got "Wikimedia\Rdbms\DBQueryError" when I use "?" in regex.

When I use regex, like "(<math>.*?<\/math>)" I got Error. Without "?" like "(<math>.*<\/math>) I got ok.

How can I use the lazy matching in regex without "?" ?.

I found no way to around because in Latex equation nearly every characters are used.

Please help me.

Verdy p (talkcontribs)

The regexp engine is not a full PCRE implementation. Advanced features (such as the capability to search or match newlines or make multiline searches, or use named capture groups, or to control the lazy behavior, or additional inline `(?flags: ... )` inside regexps themselves) are then not implemented/supported.

May be this extension may be tuned to use another full and modern PCRE engine (which will need to be enabled and setup properly). Note that PCRE is integrated and supported on Wikidata for its advanced reports.

So first make sure that there's a PCRE engine installed, like it is in Wikidata (also used internally by Extension:AbuseFilter on all Wikimedia public wikis). Additional works in the PHP code may be needed to setup and being able to use this alternate engine.

Unfortunately, the type and version of the regexp engine installed is not visible in Special:Version, either as an extension or library: these dependencies are hidden within each extensions that were each built and tested for their own regexp engine and there are then several separate engine instances installed (possibly in identical versions but with separate copies maintained separately); such dependencies should be documented in each extension.

If I just look at https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/ReplaceText/+/refs/heads/master/src/ReplaceTextSearch.php

I see that when regexps are enabled, the search is made in the SQL engine, using its own internal regexp engine (for example, postgresql is supported with its '~' operator in WHERE conditions, otherwise it uses the 'REGEXP' operator supported by MySQL and its variants, it may not even work at all with all DB engines not supporting any one of these two operators in their SQL dialect).

The syntax of the regexp is then dependant of the SQL backend engine used for your wiki, and you need to look at the installation of the SQL engine rather than the installation of PHP or Mediawiki itself. This also means that regexps used with Special:ReplaceText (if it's activated in the MediaWiki installation) or with the "ReplaceAll.php" script (run only from the host system's console by authorized sysadmins or via custom client programs on that host capable of doing SQL requests) are NOT portable (and no effort was made to port it): all matches are found by the SQL engine itself; then the PHP code will process these matches and will use its own syntax for replacements before submitting SQL updates or replaces.

As this can severely affect the whole database (and can use lot of resources and be very slow) it is naturally highly restricted and can explain why the extension is not even installed as Special:ReplaceText in Wikimedia wikis, for evident security and performance reasons (otherwise there's a huge risk of creating a severe denial of service attack with massive destruction of contents, and long times to restore/reload a database from a backup, and loose lot of valid works made since last backup).

But as it is very risky to use this extension, sysadmins that can use it should be clearly aware of the exact regexp syntax supported and their effect. This extension then currently targets only developers, and only those with strong knowledge of the SQL engine used and when/how it is maintained: the regexps you use and submit with this extension are NOT checked at all, they can do whatever they want, even unexpected things if you thought that your regexp was fine and harmless or should work and match what you expect! Be careful!

It's probably much less risky to use someting else, such as Pywikibot (using the standard MediaWiki API and undercontrol of bot authorizations and with limitations of change rates submitted, plus all action reversible from the history: ReplaceAll.php and Special:ReplaceText are not feeding the page history at all).

Reply to "I got "Wikimedia\Rdbms\DBQueryError" when I use "?" in regex."

doesn't work anymore with namespaces

Gunnar.offel (talkcontribs)

In 1.34 you can replace namespaces by replace the text Bastel: to DIY: for example.

In 1.35 the namespaces seems to work in another way. If you try to replace it now, the text of the namespace isn't found anymore. it simply says "no page found" / "Es wurde keine Seite gefunden". i verified, that 91 pages exist with this schematic.

Reply to "doesn't work anymore with namespaces"

Is there a better way to search wikitext than using ReplaceText?

Ahancie (talkcontribs)

I often use ReplaceText in order to search the wikitext throughout the site, but there are limitations to using this method, especially when there are thousands of search results. For example, if I want to find all pages with 'alt=' in the wikitext, using ReplaceText only shows me the number of results equal to $wgReplaceTextResultsLimit. Is there a better way to search the wikitext? I've tried to find an extension, but haven't had any luck.

FreedomFighterSparrow (talkcontribs)
Ahancie (talkcontribs)

Thank you, that helps. Prior to our current upgrade to 1.34.4, ReplaceText would list ALL pages found in a search, but only allow changes to the value of $wgReplaceTextResultsLimit. For example, if the ReplaceText showed 10,000 pages containing the text I wish to change, then I know I will need to use the ReplaceText 4 times to get all pages changed. Now, I can only see 3,000 pages (which is what we set $wgReplaceTextResultsLimit to), and I have no idea how many pages I am dealing with. Is there a way to get ReplaceText back the way it used to be, so it search ALL pages and lists them, even if only a certain number of them can be changed at a time?

Reply to "Is there a better way to search wikitext than using ReplaceText?"

ReplaceText's specific regex behaviour/limitation ?

MvGulik (talkcontribs)

I'm having a bit of a problem understanding ReplaceText's specific regex behaviour/limitations.

I'm trying to target the following two cases with a single regex.

" abc1def = 234 "
" abc5def = "

Which should not really be a problem for regex in general.
Using a regex like " *abc[0-9]def *= *[0-9]* *" on https://regexr.com/ (default setup) works fine in this respect.

But ReplaceText's regex implementation seems to not want to do this.
ReplaceText's goes for the " abc1def = " part, but skips/ignores the number part in this case.

I'm I missing something about ReplaceText's regex implementation?

ReplaceText: 1.4.1
MediaWiki: 1.31.0
PHP: 7.0.30-0+deb9u1 (fpm-fcgi)
MariaDB: 10.1.26-MariaDB-0+deb9u1

Ciencia Al Poder (talkcontribs)

The leading part of your expression is full of optional matches (asterisks). Since it doesn't need to match, it may be skipped altogether. Ideally you should add some other character at the end that is not optional (maybe a newline, a pipe, etc)

MvGulik (talkcontribs)

> "Ideally you should add some other character at the end that is not optional"

I spotted something similar happening while trying to work this out, but had not followed up on that yet. And your right, that actually works. (oddly enough)

Seems a bit of an odd constrain to me. Although using multiple optional matches can be a general source of RE hiccups, this RE is relative simple (I think).

Anyway. Thanks for the tip. Saves me some unnecessary replace runs. :)

MvGulik (talkcontribs)

After some more ReplaceText's RE testing in this case it feels to me like ReplaceText's RE switches quantifiers in some particular cases from greedy to extreme none-greedy.
(Note: My knowledge on RE's 'greedy' vs 'none greedy' is a bit rusty at the moment)

Extreme none-greedy: as in 'not matching anything even if there is something to match'.

For example "[a-c]*[0-9]*" seems to work fine. Capturing anything from "a" to "abc123". (seems: as in based on replace preview (which can be a bit iffy at times).)
But "abc[0-9]*" will not match the number part in strings like "abc123". (while "abc[0-9]+" will only match the first digit)
It will match all digits after adding a quantifier modifier "abc[0-9]*?". (or "abc[0-9]+?" in second case)

Is ReplaceText's RE by default 'none greedy'?
(Or em I looking at it from the wrong angle?)

Reply to "ReplaceText's specific regex behaviour/limitation ?"

add option for case insensitive

2601:586:581:4C80:F9F0:E0F5:6425:4227 (talkcontribs)

It would be great if there was an option to allow for case insensitive regex

2601:586:581:4C80:F9F0:E0F5:6425:4227 (talkcontribs)

also it would be great if there was an option to increase the amount of pages to effect.

Gunnar.offel (talkcontribs)

In extension page an case-insensitive option is descriped. (?i) before the string.

      Search string: (?i)iphone
      Replacement string: iPhone

  The above will unify the casing of all mentions of iPhone/iphone/IPHONE to iPhone.
Reply to "add option for case insensitive"