Extension talk:Replace Text/Archive 2022

replaceAll.php replace text with text+EOL

Hi all, Yaron,

I would like to add an end-of-line (EOL) symbol in the replacement text using a file (--replacements=) in the replaceAll.php function, without that symbol ending up in the text (so <br> is not an option). Is that possible?

Just added a return to the replacement text won't do it, and added something like "\n" doesn't either. Adding a return doesn't successfully execute the replaceAll.php, and adding "\n" will include this in the actual text.

Suggestions welcome, thanks!

Albert Kettner2 (talk) 15:50, 9 January 2022 (UTC)

Try the $ end-of-string anchor. 「ディノ奴千？！」^{☎ Dinoguy1000} 16:38, 9 January 2022 (UTC)

Thanks for the prompt response Dinoguy1000,

Unfortunately $ or $\n in the replacement text, is entered as such ( so will show up on the wiki page as $ or $\n )

Thanks though!

Albert Kettner2 (talk) 16:55, 9 January 2022 (UTC)

Aah, sorry about that, I somehow overlooked the "replacements" bit. Unfortunately I don't have any suggestions for how to do that. 「ディノ奴千？！」^{☎ Dinoguy1000} 17:12, 9 January 2022 (UTC)

"Notice : Undefined offset" in SpecialReplaceText.php on line 297

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

When error reporting is turned on, this notice appears after a find/replace:

Notice : Undefined offset: 1 in /.../extensions/ReplaceText/src/SpecialReplaceText.php on line 297

Everything still works though. Jonathan3 (talk) 11:58, 17 January 2022 (UTC)

Thanks for pointing out that problem - I believe it's fixed now, in the latest code. Yaron Koren (talk) 04:00, 27 January 2022 (UTC)

Thanks. I've got the latest code now and haven't seen that message again. Jonathan3 (talk) 18:06, 27 January 2022 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

RE vs non-RE search feedback on result page.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I think it would be useful to have some sort of feedback in the search result page if a search used RE or not.

Background reasoning:

I made a little script(Py) that turns a saved html-search-result page into a wiki-table. To potentially post it on request of other users.

Although there are some general ways to identify RE related search strings. It unfortunately can't be made full-proof.

One reason to need to know if it was a RE search, is to be able to fix the highlighted text in the search result. (As "replace Text"'s highlighting has a tendency to not be there. Wich seems related to having a linebreak in the matched string.)

Note: Practically its not needed to have this RE-tag displayed at the result page. If its just some hidden tag in the saved html result page it would do the job too.

Waves at @Kghbln. Your "ray of sunshine" here. Which you blocked from SMW github, and at the same time from SMW-wiki (including the wiki personal page) ... without any warning or any time limit. I guess general blocking rules don't apply to those that are above approach (nothing new under the sun of course, giving current world affairs). MvGulik (talk) 06:48, 23 January 2022 (UTC)

O yea. In my final generated result I'm using "↵"(↵) to display line-breaks.

Which I think would be a nice visual improvement to 'Replace Text's output.

(this would also works fine in 'Replace Text's edit-summaries text btw) MvGulik (talk) 06:58, 28 January 2022 (UTC)

That "enter" character is a good idea; this was just added to the Replace Text code. As for the hidden tag - there is already a hidden tag created, with "name=use_regex"; is that good enough? Yaron Koren (talk) 15:50, 16 February 2022 (UTC)

> That "enter" character is a good idea; this was just added to the Replace Text code.

Cool. :-)

> there is already a hidden tag created, with "name=use_regex"; is that good enough?

Oops, I see it now. Yea, that will definitely do the trick. Thanks. MvGulik (talk) 18:37, 17 February 2022 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Consequences of too high $wgReplaceTextResultsLimit

I set it to 3000 and the command line replaceAll.php seemed to run fine, for ages (I don't know how many pages). I tried it at 1000 for Special:ReplaceText and it found 1000 pages all right, but the confirmation page said that some lower number (in the 900s) of pages would be affected. There was no warning (the documentation suggests there might be: see below). Is the only negative consequence that fewer than $wgReplaceTextResultsLimit pages are affected? If so, I'd happily just keep it at 1000. Thanks.

ReplaceText only processes 250 pages at a time by default. To change this, you can set $wgReplaceTextResultsLimit to a larger value in your LocalSettings.php. However, you may be limited by PHP's max_input_vars; if the extension reports such a warning, you may need to change it.

Jonathan3 (talk) 18:06, 27 January 2022 (UTC)

ReplaceText edits by admin user are marked as needing to be patrolled

Ordinarily my edits don't have the red exclamation mark, but edits via ReplaceText do. I'd like the exclamation marks not to appear. Is there a setting I've missed? Thanks. I'm using ReplaceText 1.7-alpha (27657b7) 21:16, 2 December 2021 and MW 1.35.4. Jonathan3 (talk) 14:51, 4 February 2022 (UTC)

What are these red exclamation marks? Is that from some extension? Yaron Koren (talk) 22:57, 8 February 2022 (UTC)

"Changes which are not patrolled display with a red exclamation mark (!)." (Help:Patrolled_edits). Jonathan3 (talk) 23:20, 8 February 2022 (UTC)

I should probably have known about that before. :) Anyway, I think this is fixed now. Yaron Koren (talk) 01:14, 22 February 2022 (UTC)

Error at Replace Text special page

Hi! I have updated my wiki to MW 1.37.1 and extension itself. After that I see following error at Replace Text special page:

Deprecated: Use of MWNamespace::getSubject was deprecated in MediaWiki 1.34. [Called from MediaWiki\Extension\ReplaceText\SpecialReplaceText::namespaceTables in /var/www/u1406315/data/www/wikireshebnik.org/extensions/ReplaceText/src/SpecialReplaceText.php at line 601] in /var/www/u1406315/data/www/wikireshebnik.org/includes/debug/MWDebug.php on line 375

How can I fix this problem? Fokebox (talk) 06:46, 18 March 2022 (UTC)

Unless you're a developer, you should disable E_DEPRECATED and E_USER_DEPRECATED notices on production websites Ciencia Al Poder (talk) 08:40, 18 March 2022 (UTC)

I have asked my hosting provider switch off such kinds of mistake, despite it was done I still see this error. Fokebox (talk) 13:58, 18 March 2022 (UTC)

You should upgrade to the latest version of Replace Text, and then this problem will go away. Don't use the REL1_37 branch (or any other "REL" branch) of Replace Text - it will lead to problems like this. Yaron Koren (talk) 02:37, 20 March 2022 (UTC)

Bug in the replaceAll.php script using the --replacements option

MW1.37.2 / ReplaceText 1.7

If one of the lines in the file entered as a parameter to the --replacements option does not result in a replacement, the following lines are ignored even if they potentially result in replacements. Megajoule (talk) 09:18, 22 April 2022 (UTC)

Missing --category option in command-line script

A very useful feature is to replace strings in pages belonging to a given category. This feature exists in Special:Replace text page, but it does not in the command-line script. Why not?

Would it be possible to get a --category parameter for replaceAll.php? Manu.wikidebats (talk) 09:57, 30 April 2022 (UTC)

Change to ""

Hi, How I change "<ref>*</ref>" to ""?? SimcaCZE (talk) 18:06, 7 May 2022 (UTC)

I see you're looking for the regex that matches any text inside <ref> tags, which also includes both the opening and closing tags.

It's /<ref>[\s\S]*?<\/ref>/ (without the leading or trailing slashes):

• \/ is intepreted as a literal /
• [\s\S]* is intepreted as at least 0 characters, including newlines. ? makes the * quantifier lazy (so it matches as least characters as possible). C.Ezra.M (talk) 07:42, 8 May 2022 (UTC)

Thansk, but it is not working. <ref>*</ref> I have more in article. This sequense delete text in first <ref> and last </ref> SimcaCZE (talk) 19:40, 8 May 2022 (UTC)

That's what the ? modifier to make the * quantifier ungreedy is for. Remove the question mark just in case, I think this uses PCRE's U flag, which makes quantifiers ungreedy by default. C.Ezra.M (talk) 09:33, 9 May 2022 (UTC)

Hi, I correct code. It is Ok. It is making, what I want. Thanks for help. SimcaCZE (talk) 11:45, 10 May 2022 (UTC)

Regular expression and special characters

In general support for using complex regular expressions seems a bit lacking. I'm trying to do a replacement for <data table="Games">[\s\S]*?<\/data> which utterly fails. But even simpler things don't work as expected. As a simple example, I tried to replace a string with special characters, namely </data> with |}}. However, no replacement I try works. If I escape the special characters, i.e. replace <\/data> with \|\}\}, I end up literally having \|\}\} in the text. If I don't escape the special characters I keep getting the awful Wikimedia\Rdbms\DBQueryError message. Any idea what's wrong?

MW 1.30.1, PHP 7.1.33, MySQL 5.7.38, ReplaceText 1.2 (REL1_30) 109.253.216.196 07:09, 25 July 2022 (UTC)

Have you tried escaping the < and >? I don't remember for sure if it was S:ReplaceText, but I know I've had some trouble with these characters in some flavor of regex, so that'd be the first thing I'd try. 「ディノ奴千？！」^{☎ Dinoguy1000} 07:54, 25 July 2022 (UTC)

~~ I did. That was not the problem. I verified it by using AAA as the replacement string, which worked. 109.253.216.196 (talk) 08:31, 25 July 2022 (UTC)

ReplaceText exits with "does not hold regular wikitext"

Sometimes I need to run ReplaceText on namespaces with content models other than wikitext. That used to work for me if I remember well, but the last time I ran it (a plain-text model in this case), it exited with an error message along the lines of "Wiki page ... does not hold regular wikitext". Cavila 10:20, 13 October 2022 (UTC)

At some point I was able to run replacements on pages with a plain-text content model. But guess what happened: for many of them, the content model was changed to wikitext. How can I 'mass restore' their models? Cavila 09:16, 29 June 2024 (UTC)

The original post was probably addressedd by this commit: https://github.com/wikimedia/mediawiki-extensions-ReplaceText/commit/a2b09220fee3864a6512c2e661dc6576636e1972 - I'll have a look later on to see if the other issue persists. Cavila 10:24, 29 June 2024 (UTC)

Unexpected behavior(s) - Page moving.

Somewhat unexpected behavior(s) in my view.

1) When changing some text that was in one page-case in both the title and the same (file)page content (which was a file-redirect page). The page was moved first, but the content change was skipped. (presuming the initial page move prevented the content change. Although I figure point 2 could also have something to do with it)

2) In the same replacement job(non scripted) I'm pretty sure I disable the "Save the old titles as redirects to the new titles" option. But I did end up with having old-title-redirects on all moved (file)pages. ... Which in this case, if the content change in point 1 would have succeeded would have created a redirection loop.

All in all thing worked out ok (only a few pages had to be changed), but it also leaves some concerns when it comes to doing potential complicated/troublesome changes on large sets of pages.

?) Are there some know problems, or undocumented behaviors, with the "Save the old titles as redirects to the new titles" option ?

Oops: +Local versions.
- MediaWiki 1.36.1
- Replace Text 1.4.1 MvGulik (talk) 08:55, 14 October 2022 (UTC)

{n,m} quantifier (?) Lazy vs Greedy (Default)

Did not know "Replace Text" supported the {n,m} quantifier.
...
Well at least the {n} version that is.
When trying out the {n,m} format like in "{2,}" or "{2,99}" it just matched 2 cases, while ignoring the trailing rest. (?)

In case it matters.
Tested it with leading blank-lines removal like in "^\n{2,99}(.*)"

(Not tested {n,m} with additional trailing quantifiers ... don't really see the point of that)
(to get the job done I switched back to "^\n+?(.*)".)
MvGulik (talk) 22:41, 19 October 2022 (UTC)

Hmmm ... Might be related to the fact that quantifiers in 'Replace_Text' seem to be set to be lazy by default. (which I keep generally forgetting as I learned it the other way around)

Guess I need to do some additional reading & testing on this. MvGulik (talk) 09:48, 21 October 2022 (UTC)

Yea, it is as expected.

RE: "a{4,8}" => "aaaaaabbbaaaaaacccaaaaaa" <= lazy mode.

RE: "a{4,8}?" => "aaaaaabbbaaaaaacccaaaaaa" <= greedy mode.

So far I don't know of any other RE-implementation that is doing it this way. Even the, on the main page linked, mysql page shows its greedy by default. (no mention of "greedy" or "lazy" though)

Although defaulting to RE-lazy-behavior for MW might not be a bad thing ...

(Makes testing 'Replace Text' intended RE code on sites like https://regexr.com/ a bit awkward, and error prone, though)

I do think this 'Lazy-Default vs Greedy' should be mentioned(!) on the 'Replace text' main page. MvGulik (talk) 17:00, 21 October 2022 (UTC)

I was having the same problem until I saw your solution. I wanted to capture all of the characters in this string:

String: "{{Abc | 1498}}#hist=tab%3A2"

Enabling greedy mode fixed my problem. The % char seemed to cause additional difficulty, so I included it in my group.

RE: "\{\{Abc \| (\d*)\}\}([^ ]|\%)+" => "{{Abc | 1498}}#hist=tab%3A2" <= lazy mode

RE: "\{\{Abc \| (\d*)\}\}([^ ]|\%)+?" => "{{Abc | 1498}}#hist=tab%3A2" <= greedy mode

I agree that 'Lazy-Default vs. Greedy' should be mentioned on the 'Replace text' main page. Lady G2016 (talk) 01:02, 20 June 2023 (UTC)

Caps

On the results page, every word is capitalized. This makes it very difficult to copy and paste strings that might be of interest in another text replacement. For example, if I'm looking for this misspelling, "carwach", I might get this text, "Carwach Is A Commedy Filmm". If I now want to look for "Commedy Filmm", the search might have no hits because the words in the source might be "Commedy filmm" or "commedy Filmm" or "commedy filmm" but not "Commedy Filmm" (all caps). I think it would be an improvement to the extension to display the exact format of the source. Cojoilustrado 10:03, 29 November 2022 (UTC)

The extension does display the text around matches, exactly as it appears on pages; you should double-check your pages to be sure the capitalization is not actually present on them.

To work around this, check the "Use regular expressions" box, and replace each letter that might be uppercase or lowercase with square brackets containing both letterforms (so your example would be [Cc]ommedy [Ff]ilmm) 「ディノ奴千？！」^{☎ Dinoguy1000} 11:17, 29 November 2022 (UTC)

Thank you. I'll check it out. Cojoilustrado 14:22, 29 November 2022 (UTC)

One can also enable case-Insensitive searching by starting a regex with "(?i)" MvGulik (talk) 18:48, 30 November 2022 (UTC)

Oh, that's useful, I didn't know about that one. 「ディノ奴千？！」^{☎ Dinoguy1000} 23:52, 30 November 2022 (UTC)

How do you...

Trying to replace |names=Mark|surnames=Smith for |name={{name|Mark|Smith}} but I have failed so far. The regex I used is nombres\=(.*)|apellidos\=(.*) to be replaced by nombre={{nombre|$1|$2}}, but this is obviously wrong because I get back nonsense. Anyone can help me to figure this one out? Thank you. Cojoilustrado 14:28, 29 November 2022 (UTC)

You don't need to escape the equals signs, but you do need to escape the pipe: nombres=(.*)\|apellidos=(.*)

Though this regex is also unlikely to do what you want. Unfortunately, there is no fast or easy answer for this as long as you're using regex for the replacement; you're going to have to spend some time familiarizing yourself with basic regex functionality, and depending on how the parameters you're trying to replace are used, it may not even be possible with just regex. 「ディノ奴千？！」^{☎ Dinoguy1000} 23:21, 29 November 2022 (UTC)

I'll give it run and see where I get. Do you know of any site with a regex guide I can learn from? The one from Mysql in the usage section might as well be in Mandarin to me XD. Thank you so much. It's a great and useful extension. It just has a leanring curve. Cojoilustrado 03:14, 30 November 2022 (UTC)

My go-to reference is generally regular-expressions.info, though I wouldn't be surprised if others can chime in with superior beginner-oriented materials. I know there are also sites that allow you to test regexes (including fairly advanced offerings that can syntax-highlight regexes and explain each individual component, and even walk through the matching process on sample/provided texts), but I personally don't often use these so don't have any recommendations. 「ディノ奴千？！」^{☎ Dinoguy1000} 08:37, 30 November 2022 (UTC)

Thank you!! Cojoilustrado 23:38, 5 December 2022 (UTC)

Invert selection option gone ? (invalid)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I see no 'invert selection' options anymore, at the search-result page, after the "Replace Text" extension was updated to version 1.7(8e35c8f) on the wiki I use (admin only).

Was it removed ?

Permanently ?

Why ?

It was a really useful option to quickly switch to testing some RE change on just 'one' page.

Now one has to go back to the setup page, set the limit to target only a singe page, go to search-page again, and after the change checks-out, go back to setup-page and remove the single page limiter, before the change can be applied globally. :-(

... or opening a duplicate setup-page for the test cases I guess.

(the new '\n' to '↵' display look nice btw) :-) MvGulik (talk) 13:33, 25 December 2022 (UTC)

I see the "Invert selections" button still there at the top of the page, and it works fine. What version of MediaWiki are you running?

(I'm glad you like the new newline display!) Yaron Koren (talk) 15:46, 26 December 2022 (UTC)

Right. Sorry. I should have added that by default.

MediaWiki 1.39.0 (Ergo: latest LTS. Now that I write that ... I figure some hiccups should be expected.)

Just in case:

PHP: 7.4.33 (fpm-fcgi)

MariaDB: 10.5.18-MariaDB

ICU: 50.2

+(Semantic MediaWiki: 4.0.2)

(It was an overall general wiki update. So all main stuff was upgraded at the same time) MvGulik (talk) 16:36, 26 December 2022 (UTC)

Okay - I thought you were using a too-old version of MediaWiki. I got worried, thinking that this button was no longer appearing with MW 1.39, but it works for me with 1.40-alpha (and with older versions), so I assume that's not the issue. This button only appears if the total number of pages that contain the search string is more than five - could that be the issue? Yaron Koren (talk) 17:52, 26 December 2022 (UTC)

let me recheck .... MvGulik (talk) 20:38, 26 December 2022 (UTC)

After rechecking. Your right! its there.

Local conclusion. I missed and overlooked it the first case (90+ results) as I was so accustomed that option was at the bottom.

After that I re-checked with less then 5 result. ergo: I still did not see my mistake.

Sorry about that.

(facepalm) ;-/ MvGulik (talk) 20:48, 26 December 2022 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.