Extension talk:Replace Text/Archive 2009

[RESOLVED] Undefined Variable "jobs"

This is just the extension I was looking for. However I get the following error upon execution:

Notice:  Undefined variable: jobs in /var/www/web15/html/extensions/ReplaceText/SpecialReplaceText.php on line 81

any ideas? thanks so much --77.7.251.34 16:50, 17 January 2009 (UTC) (Sebastian)

was fixed thanks to email from extension creator. --77.7.218.238 00:05, 23 January 2009 (UTC)

[RESOLVED] No replacement takes place

Very nice extension!

Two things:

1. One hint: in the readme there is missing: $wgGroupPermissions['sysop']['replacetext'] = true;

2. Installation worked fine.

a I can access the specialpage.

b write my Search - Replace

c get a list of articles

d Check two articles where replacement should happen

e and then I get the message (no error-message):

Text ersetzen
„May“ wird durch „ZYX“ in 0 Seiten ersetzt

translated maybe:

Text replacement
„May“ will be replaced by „ZYX“ in 0 Pages

It should have replaced the zwo pages.

As a test I switchted off all my other extensions.

What mistake did I make?

Regards, jan--89.52.183.168 17:36, 17 January 2009 (UTC)

I get the same thing basically, but I thought it was related to the error I posted above --77.7.251.34 17:41, 17 January 2009 (UTC) (Sebastian)

The installation requirement omission was fixed in r45859. I tested version 'trunk' of the extension on MediaWiki 1.15alpha r45851. This was my use case:

• pages A with content 'changeme', B with content 'changeme too', funnytitle with content 'rename me', and Please changeme with content 'blah'. I performed 2 replace commands: "changeme" to "changed" and "funny" to "not a funny". I could change the reported behaviour, and the notice. The problem is in line 71 (). The values checked against are (count 8): Special:ReplaceText|changeme|changed|1|1|1|Replace|on. No time to look into fixing this (if I even could)... siebrand 00:31, 18 January 2009 (UTC)

Maybe it helps.

I am using:

MediaWiki 1.13.3

PHP 5.2.6-2 (cgi-fcgi)

MySQL 5.0.51a-9

ReplaceText 0.3.1

Jan--89.52.191.30 11:02, 18 January 2009 (UTC)

It's the new version. Didn't replace although everything looked like it does now. Using the previous again ;) --Subfader 13:53, 18 January 2009 (UTC)

Now I have tried the old version ReplaceText 0.3 - it works. Hope someone will solve the problem with 0.3.1. Jan --89.52.191.30 14:33, 18 January 2009 (UTC)

This is fixed in the new version, 0.3.2. Sorry about all the problems. Yaron Koren 16:57, 18 January 2009 (UTC)

That's allowed with status beta, isn't it? Feature request: check box to (not) suppress creating a redirect when renaming a page. siebrand 17:02, 18 January 2009 (UTC)

When would you want a moved page to not redirect to its new location? Yaron Koren 17:20, 18 January 2009 (UTC)

I would at least like to have the option to suppress (like is possible when moving a page (with subpages). There is a right for this in core called 'suppressredirect'. siebrand 21:02, 19 January 2009 (UTC)

Okay, good idea - this is done in version 0.4. Yaron Koren 23:46, 22 January 2009 (UTC)

Thanx for your quick reaction. Erverthing works fine now. Jan--89.52.191.30 20:11, 18 January 2009 (UTC)

Well the new version (0.5.1), there's the same issue so I downgraded... MediaWiki 1.14 --Kronoxt 06:06, 4 May 2009 (UTC) [0.3.2] doesn't work either... what's happening?... i have the exactly same problem as 89.52.191.30. --Kronoxt 06:30, 4 May 2009 (UTC)

No it's different. Replacements ARE done, t'S just that the final page lists the filled form again as if it jumped back there. --Subfader 10:17, 4 May 2009 (UTC)

Yeah ok thx... it's just I didn't wait enough... My job queue was just full --Kronoxt 05:42, 6 May 2009 (UTC)

I'm experiencing this problem also: I try to replace the text (without the citation): "{{MIRKO-command" with "{{subst:MIRKO-command". Everything acts as if it works: pages are found, replacements reported happened, but when I check any one of the pages, nothing has changed. I run ubuntu server with wikimedia version 1.13.3-1ubuntu2, and ReplaceText installed from SVN (also tried tagged relases 0.7 and 0.6.7). User:Sorenweber 22:25, 22 September 2009.

This actually has been solved long ago. If "replacements reported happened" then trust it ;) Clear your cache maybe? Is it in the history of the page? Is it still the old when you edit the page? --Subfader 23:07, 22 September 2009 (UTC)

I've cleared the cache, the history shows no changes, when I edit the page I see the old :-( (BTW should I not change the summary to reopened?) User:Sorenweber 09:00, 23 September 2009 CET.

Hmm... I had a large number of replacements that should take place, and now it looks like it's happening (I observe the "Recent changes" page) but somewhat slowly (10-20 seconds/page). Anyways, it works now, although I don't know why it didn't replace before. User:Sorenweber 16:37:00, 24 September 2009 CET.

System message "Permission Error"

Just checked what normal users see why they try to access ReplaceText. Headline is "Permission Error" followed by MediaWiki:Badaccess-group1 which doesn't parse the wiki links. In normal permission errors (e.g. unauth. editing) I get "Permissions Erros" followed by MediaWiki:Permissionserrorstext and then MediaWiki:Badaccess-group1.
Anyway, shouldn't it be Badaccess-groups? --Subfader 22:02, 12 February 2009 (UTC)

Hm - the ReplaceText just calls "$wgOut->permissionRequired('replacetext');", so the setting of the message is up to MediaWiki. Should the code be calling something else? Yaron Koren 23:32, 12 February 2009 (UTC)

I use Badaccess-group1 for "You need to login or register to edit". But here it's for Sysops only. Badaccess-groups uses "The action you have requested is limited to users in one of the groups $1" --Subfader 09:22, 13 February 2009 (UTC)

Yes, I know, but, as I said, the ReplaceText PHP code doesn't call any specific language message directly. Yaron Koren 13:25, 13 February 2009 (UTC)

Regular expression matching - in the work?

Hi, I'd like to know if there are any plans to make this already useful extension even more useful by implementing Regular Expression matching. It's probably not an easy task. --Patrick Nagel 06:55, 5 March 2009 (UTC)

P.S.: Some more thoughts:

• mb_ereg* or preg* with the '/u' parameter should be used for the extension to be able to handle Unicode
• there will probably be issues because PHP's and MySQL's (and possibly other database server's) regexp implementations might differ

There are no plans per se, although it's something I'd like to see added as well. You're right that getting the PHP and database handling of regexps to match is a complication. Yaron Koren 14:28, 5 March 2009 (UTC)

[RESOLVED] Don't break file page links/names

I requested it before but maybe this is describing it more clearly: When some pages includes the Picture "A very nice picture.jpg" And you replace "very nice picture" with "nice picture" the file link will be broken when the page File:A very nice picture.jpg can't be moved. This happens very likely if you don't a have a very close look at the preview list.

Possible solutions:

• Don't move file pages
• Highlight the string to take manual actions
• Don't replace text if the string = a file page name is the same as a file page that couldn't be moved.

--Subfader 21:41, 18 March 2009 (UTC)

Sorry, is this for the case where the user doesn't realize that "very nice picture" is part of an image name? Or for the case where they do know it, but don't know that they're not allowed to move the image page? Or both? Yaron Koren 21:54, 18 March 2009 (UTC)

Links will be broken if people don't untick things in the preview and

• if people didn't tick to move pages: when the old text is part of existing file page names which are linked-to
• if people do tick to move pages: when same same as above and the file page cannot be moved
• if the user is trying all his best to avoid it but the link on the page is simply not displayed and highlighted in the preview because the old text appears twice or more times on a page

Am I correct that a page only not be moved if the new page name exists already? What if the new is the name of an old redirect? Mind all this would also happen if you didn't enable page moves. In fact it's even better that you enabled this :) --Subfader 20:19, 19 March 2009 (UTC)

Yes, that's correct - a move won't happen if the target exists already, even if that target is just a redirect page. Do you have any actual request/suggestion here? Yaron Koren 03:54, 1 April 2009 (UTC)

I was confused once more about the moves :) --Subfader 11:12, 28 April 2009 (UTC)

[RESOLVED] Doesn't find & amp;

I can't replace & amp; (without blank) with &. Not that & amp; is bugging me but I have & amp; on ~10k articles preloaded from an old "create article" template and i prefer having it & cos it's better readable. (& amp; is on all those articles not only in the template).
Anyway, & amp; is not found when i try to replace it, only &. --Subfader 15:36, 28 March 2009 (UTC)

Thanks for the bug report; this was fixed in the latest version, 0.4.1. Yaron Koren 19:09, 7 April 2009 (UTC)

[RESOLVED] Namespace selector

What about a namespace selector in the form? --Subfader 11:12, 28 April 2009 (UTC)

This is a tough one - it's a good idea in theory, but I don't want to add something that will overwhelm the rest of the interface. Any thoughts? Yaron Koren 04:00, 29 April 2009 (UTC)

My thoughts are it would not destroy the minimal view. Just group them in 2 columns (ns + ns_talk) or like the standard MW "advanced search" while all talk pages are unticked as well as User (this is important imo, atm I always add this manually to $exemptNS). --Subfader 05:20, 1 May 2009 (UTC)

Alright, you convinced me - there's a namespace selector in the new version, 0.6. Thanks for the suggestion. I think it looks fine, and it also removes the problem from before where namespaces where included or excluded somewhat haphazardly. Yaron Koren 20:59, 19 May 2009 (UTC)

It's a great step forward. It also speeds up the querey i guess with Main only. --Subfader 01:09, 22 June 2009 (UTC)

URL parameters

0.5 works great but I miss the URL parameters :/ I guess it's post now to pass special characeters easier? Just changig it to get doesn't owrk. The point is I have a long list of regular replacements. I use a link for each (target_str=FOO&replacement_str=BAR) so I don't neet to copy-paste each. It wasn't perfect though, still a button for "run my regular & save replacements without preview" would be better :) --Subfader 11:12, 28 April 2009 (UTC)

I didn't realize that this had happened. In 0.5.1, it works again, though the structure of the URL has changed: now the query string should look like "target=FOO&replacement=BAR&confirm=1&edit_pages=1" (and/or "move_pages=1"). Yaron Koren 19:00, 30 April 2009 (UTC)

1) Still the URL shows no parameters for me in the different steps. 2) I replaced the link parameters on my certain page. They work but I land on the form page. Since I don't see the parameters, which takes me straight to the preview? I remember my old links took me straight to the preview? I don't need to confirm the replacement. It are regular ones I'd like to automate as much as I can :) --Subfader 03:25, 1 May 2009 (UTC)

Doesn't this new URL structure take you to the "preview" page too? Yaron Koren 13:09, 1 May 2009 (UTC)

No. Maybe my page names are confusing? It takes me to the form with the textareas. Preview page = the page after confirmation with the listed results. Maybe something is wrong anyway cos the final page bug which listes the filled form? --Subfader 13:47, 1 May 2009 (UTC)

Yes, by "preview page" we mean the same thing; does your URL query string look exactly like what I wrote before? Yaron Koren 20:19, 5 May 2009 (UTC)

Hey Yaron, thanks for the change!! I don't miss the URL parameters at all: my server would block any attempt to pass a URL as replacement parameter, and I had to hack the extension to receive something as "http;//" and replace it internally with the correct string. But the new version is dealing with such strings perfectly :) Capmo 00:11, 6 May 2009 (UTC)

I finally managed to set up my links again (using a template) for regular replacements. If anyone is interested, post on my talk page.
Yaron: Is it possible to skip the form and preview via a URL like ...Special:ReplaceText?title=Special%3AReplaceText&target=foo&replacement=bar? --Subfader 01:57, 21 June 2009 (UTC)

[RESOLVED] Cannot be moved

Although "Replace text in page titles, when possible" is unticked on the form, I sometimes get the list for pages which can't be moved on the preview page. Is this intended? It makes no sense, cos I didn't want to move any pages anyway. Don't remember other examples, but I had it when I tried to replace & amp; with &. --Subfader 11:30, 28 April 2009 (UTC)

Hi, I couldn't reproduce this; this seems odd anyway - you had a page whose title contains "& amp;"? Yaron Koren 03:30, 29 April 2009 (UTC)

"& amp;" without blank ;) I can't reproduce it myself since I replaced them already and can't remember other examples. Maybe others can report the same behaviour. --Subfader 14:09, 29 April 2009 (UTC)

[RESOLVED] Multiple lines

It's archived so I ask here again. Will it be added one day? --Subfader 11:30, 28 April 2009 (UTC)

I suggest you add a feature request in bugzilla: on "MediaWiki extensions/ReplaceText" to not let the feature request go away. Would be a nice one, although I fear it's performance on wikis with a few hundred thousand pages :) siebrand 15:47, 30 April 2009 (UTC)

Good thing you asked again. :) This has now been added in version 0.5.1 - it turned out that all I needed to change was turn the two string inputs into textareas. This shouldn't lead to any big performance hit, as far as I can tell. Yaron Koren 19:02, 30 April 2009 (UTC)

Monster feature :D One thing I noticed after replacing text (multiple or single lines): The final page with "Return to form" lists the form below including the filled inputs (screenshot). --Subfader 03:25, 1 May 2009 (UTC)

Actually it could be a feature :D --Subfader 04:13, 1 May 2009 (UTC)

Yeah, that's a bug; fixed in 0.5.2. Yaron Koren 20:19, 5 May 2009 (UTC)

Thanks :) --Subfader 21:34, 5 May 2009 (UTC)

Not working anymore since 0.? - It doesn't find e.g.

]]
[[Category

or even easier things. I'm on MW 1.16alpha but imo I had it with 0.6.5 on MW 1.14 already. --Subfader 23:14, 18 July 2009 (UTC)

Thanks for the bug report. Indeed, that's a real problem that might have been there for a while... it's fixed now (I think), in version 0.6.7 - I removed some extra escaping of characters, that formerly was needed. This all leaves me more confused than ever - somehow there's extra escaping happening that wasn't there before... or maybe it all depends on one's database configuration. Yaron Koren 18:57, 20 July 2009 (UTC)

Thanks, works again. --Subfader 22:57, 20 July 2009 (UTC)

Moving issues (as of 0.5.1)

• When you move a page, "Watch these pages" should not be ticked by default.
• If the string includes the namespace it should be found anyway. "Help:General" is only found searching "General" or if linked to (but then not moved). This is not only uncomfortable but also confusing cos of the error message = "This page does not exist? Did I mistype?"

--Subfader 05:05, 1 May 2009 (UTC)

The first one is now fixed in version 0.5.2, thanks. The second one would be rather difficult to do, since the namespace is stored separately from the page title in the database. Yaron Koren 20:15, 5 May 2009 (UTC)

What about stripping out namespace prefixes in the find string? With a message on the form that you shouldn't include ns prefixes in the string. Then the user wouldn't wonder that his string was stripped and maybe other ns pages are in the preview list. Maybe a namespace selector would solve this? :) Btw: wikimsg replacetext_note (Note: this will not replace text in "Talk" pages and project pages.) should be adjusted to your new $exemptNS = ... NS_TALK, NS_USER_TALK but see my namespace selector request above. --Subfader 21:34, 5 May 2009 (UTC)

Well, there's no way to know whether the "Help:" in your example string is meant to be a namespace or not. But, as you note, a namespace selector might well resolve these issues. Yaron Koren 23:44, 6 May 2009 (UTC)

[RESOLVED] No Replacement with Backslashes (0.5.1)

I'm trying to replace a UNC file path, e.g. "\\server\sharename". I've figured out that I need to double-up the backslashes (e.g. search for "\\\\server\\sharename"), otherwise I don't even get a list of matching pages. However, even though I'm now successfully getting a list of pages to be hit, no replacement takes place. My job queue is being processed, and other test replacements work fine.

Basically, I'm attempting to replace "\\oldserver\sharename" with "\\newserver\sharename"... I'd be grateful for any pointers, if this isn't a bug! Gothick 15:31, 5 May 2009 (UTC)

That's definitely a bug; it's fixed now in version 0.5.2. Yaron Koren 20:15, 5 May 2009 (UTC)

Thanks for the quick response. I can confirm that the fix in 0.5.2 works for me. Gothick 09:29, 6 May 2009 (UTC)

Suggestions

Hi Yaron, I'd like to suggest two minor changes:

1. I noticed that the extension is no longer accepting single quotation marks. I tried to escape it using a backslash or duplicating the quotation mark but none worked as expected. The following change fixed the problem:

In line 375 of SpecialReplaceText.php, replace

$search = str_replace('\\', '\\\\',  $search);

with

$search = str_replace(array("\\", "'"), array("\\\\", "\'"),  $search);

2. In the window after confirmation, when the target and replacement strings are shown, together with the list of matching pages, both strings appear in the page after being parsed by the wiki. So, if i'm replacing "{{template}}", it shows in the page not the string "{{template}}" but the result of the template. Similarly, if replacement is "'''text'''", it's displayed as "text". The solution I found was this:

In line 237 of SpecialReplaceText.php, replace

$wgOut->addWikiMsg( 'replacetext_choosepagesforedit', $this->target, $this->replacement,

with

$wgOut->addWikiMsg( 'replacetext_choosepagesforedit', '<tt><nowiki>' . $this->target . '</nowiki></tt>', '<tt><nowiki>' . $this->replacement . '</nowiki></tt>',

In spite of these, thank you for the last improvements to the extension, I've already tested the multi-line replace and it worked as a charm. Capmo 01:45, 6 May 2009 (UTC)

Oops, I commemorated too early :) I've just received an error ("Fatal error: Call to undefined method SkinMonoBook::link() in /.../wiki/extensions/ReplaceText/SpecialReplaceText.php on line 101") after selecting all the pages in the list and confirming. I guess I should have received the replacetext_return page instead. Any idea what might have happened? Anyway, the replaces were done, as could be confirmed in the Recent Changes. Thanks, Capmo 02:02, 6 May 2009 (UTC)

I got the same problem with SkinMonoBook::link() just with some normal replacing -- I had to upgrade to MediaWiki 1.14 to work around this; it seems the latest Replace Text uses this link function, which isn't available in 1.13. Hope this helps in some way! Gothick 09:08, 6 May 2009 (UTC)

Nice improvements. But I worry it won't be added too soon cos of staying backwards compatible (although MW 1.14 gives a sh*t about it as well). --Subfader 15:11, 6 May 2009 (UTC)

Hi Subfader, could you please explain what you meant with keeping it backwards compatible? In previous versions (I used v0.3) the extension did accept strings with single quotation marks, and it wouldn't parse the target and replacement strings before presenting them on the confirmation page, so the changes I propose are exactly to restore the backwards compatibility. Is there also any chance of this SkinMonoBook::link() bug to be fixed so that the extension works well also with MW 1.13? Thanks, Capmo 17:01, 7 May 2009 (UTC)

Wrong use of the term there I guess. I ment Yaron will surely prefer keeping ReplaceText running on older MW Versions over this tweek for 1.14+ only. --Subfader 18:25, 7 May 2009 (UTC)

Yeah, that's correct. I'll try to fix it soon. Yaron Koren 20:52, 7 May 2009 (UTC)

Oh, ok! That's great, thanks! Capmo 21:42, 7 May 2009 (UTC)

Capmo - thanks a lot for the suggestions; they've all been incorporated into the latest version, 0.5.3. Development on this extension is getting easier all the time. :) Also, I changed the offending link() function back to an older function, makeKnownLinkObj(), to undo the compatibility problem. Yaron Koren 20:16, 8 May 2009 (UTC)

More suggestions

Hi Yaron! Thanks for having incorporated the suggestions and for removing the call to link(), now it works well again for MW 1.13 users. :) Making some more tests with it, I noticed that there remained two minor issues that if changed will make the extension perfecly compatible with the ealiest versions:

1. Apply the "<tt><nowiki>{$this->target/replacement}</nowiki></tt>" trick also for 'replacetext_warning' (lines 132 & 138 of SpecialReplaceText.php) and 'replacetext_success' (line 97) system messages;
2. Reintroduce the sort key in the results list; this was a very nice feature of version 0.3: sometimes we want to replace text in just the main namespace, and with the sorted list it was easy to spot other namespaces to exclude. I added a parameter $sort to the query (last lines of SpecialReplaceText.php) and it seems to be working fine:

	$sort = array( 'ORDER BY' => 'page_namespace, page_title' );
	return $dbr->select( $tables, $vars, $conds, __METHOD__ , $sort );

As I said, these are really minor changes. Thanks again for all your work, this extension is tremendously useful. Capmo 19:42, 12 May 2009 (UTC)

Thanks again for your contributions. These changes are both now in version 0.6. Yaron Koren 20:57, 19 May 2009 (UTC)

Optional cap instead of all instances?

Is it currently possible (or perhaps via a minor change in the code) to place a cap on how many replace actions will occur? The problem I am having is what I want to replace has so many occurrences (which is why I really don't want to have to do the edits manually) that it always times out trying to parse all of them. If instead of going after every single one, it could just stop after it had found X number of instances to replace, then you could do it a couple of times, knocking off X each time until you get through them all? --Tlosk 17:50, 13 May 2009 (UTC)

Interesting, I didn't know that it could time out. Do you have a sense for around what number it times out at? Yaron Koren 18:10, 13 May 2009 (UTC)

Yes, version 0.3 used to time out a lot, but then it would go on the second attempt. Version 0.5.* no longer times out for me, but when the query result is too large (in my case, a query returned ~10.000 pages), then the selection list is not displayed, just a blank page. Capmo 20:52, 13 May 2009 (UTC)

Thanks for the replies, I had been testing this on a local machine that's a little older, and it would give a PHP 60 second timeout and nothing more, however after experimenting with some rarer cases that worked ok I went ahead and tried it on the production server and it came up fine (it was around 6,000 uses). I guess I just didn't have enough horsepower on my test machine. --Tlosk 21:25, 13 May 2009 (UTC)

Wow, okay - I never imagined Replace Text would be used for numbers that big. In that case, a default limit (set via a global variable) makes a lot of sense. Yaron Koren 21:57, 13 May 2009 (UTC)

Yeah, if implented, then please via manual settings. I never experienced timeouts in newer versions on the server. No such settings as default to please wikis on local machines please. --Subfader 00:49, 14 May 2009 (UTC)

Subfader, the question is not to please wikis on local machines, but to be able to present the results in a reasonable way. It's simply impractical (sometimes impossible) to display a list of, say, a thousand or more items to select/unselect; a default maximum value makes all the sense here. Yaron could add a feature so that if the results returned by the query are > $wgReplaceTextMaxDisplayResults, then the list is not displayed, just the confirmation buttons. I suppose the query itself can not be limited for MySQL users, because it lacks such a feature, as far as I know. —Capmo 02:28, 14 May 2009 (UTC)

I should qualify my comment above, I've gotten about 900 edits to successfully load, at some number above that the page will simply blank. Also in my particular case it may be exacerbated as there can be 100+ replaces on a single page, and there are thousands of pages (most pages will only have a couple though). If I narrow the number down more through experimentation I will post again (I'd mistaken the number of edits that cannot be undone that's displayed for the number of edits that were going to take place, instead I should have been looking at the job cue after it loaded). And I agree that a default shouldn't interfere with people that have no problem, just that it would be nice if a manual option were available for people needing to do large numbers of edits. --Tlosk 22:20, 14 May 2009 (UTC)

Well, I haven't added anything like in this in the new version, 0.6, but there is a namespace selector now. Is there any chance that that serves to eliminate problem of too many pages at once? Yaron Koren 21:01, 19 May 2009 (UTC)

That's a great addition. Is it possible to also restrict a search to a single category? Similar to how you can enter a category name on the Export Page. --Tlosk 22:34, 21 June 2009 (UTC)

To restrict it to a certain cat has been requested before. --Subfader 01:11, 22 June 2009 (UTC)

Replacing URL encoded characters

I'm having problems replacing a string where the space (in a URL) has been converted to %20. For example, I want to replace: "gallery/Registered%20Players" with "gallery/factions" but although the extension picks up articles where the original string is present it doesn't perform the rename despite giving the impression it has. Is this a known problem? Coldmachine 16:20, 19 May 2009 (UTC) <--- strike that, it looks like it just took a while to cache and the changes have taken place as hoped. Coldmachine 17:19, 19 May 2009 (UTC)

A few more :)

• If only the move option is ticked on the form, don't look for page content or just don't list them
• If the move option is ticked and a 2 or more string is entered in the find or replace textarea, return an error message on the preview page like "Two or more rows cannot be found or replaced in page titles."

--Subfader 17:40, 30 May 2009 (UTC)

Hmh wait, if you click for moving it will replace in content nontheless. --Subfader 20:35, 3 June 2009 (UTC)

Oh - if true, that's a major bug - let me look into it. Yaron Koren

I haven't been able to duplicate either your first or third note here. Are these both still problems? Yaron Koren 15:02, 16 June 2009 (UTC)

Dunn yet. I skipped a few versions and just upgraded from 0.52. I can tell after more replacements with moves. At least the move options are not showing up anymore when move is not ticked. Btw: the ns selector was eally needed and seems to work fine. --Subfader 01:50, 21 June 2009 (UTC)

In the latest version, it finds no page titles. I don't want to diss your hard work, but this is not the first heavy bug on a simple feature. I simply wonder how this can happen. Don't you test those few main features before releasing an update? :/ --Subfader 09:40, 24 June 2009 (UTC)

I don't understand - this could be because of a fix in the last version, where it now handles capitalization correctly when searching for pages. Maybe there should be a warning somewhere reading "Search is case-sensitive". Is that what you're talking about? Yaron Koren 16:39, 24 June 2009 (UTC)

With "simple feature" I meant "main feature" and there aren't much to test before releasing a new version. Don't be pissed please ;)
When you only tick "Replace text in page contents" it finds nothing and that very quickly, caps are correct. Tried with various examples. You can only move via using "Replace text in page contents" ticked as well. --Subfader 19:25, 24 June 2009 (UTC)

I can't duplicate this problem. I couldn't understand the "it finds nothing and that very quickly" - are you talking about two bugs here, or one? Yaron Koren 19:30, 24 June 2009 (UTC)

No, just one bug. I use 0.6.4. Untick "Replace text in page contents" in order to only move pages. I tested with multiple words belonging together like "Albert Einstein". Tried again. It finds single words in titles though, e.g. "Einstein" but not "Albert Einstein" although pages exist and caps are correct. With "Very quickly" I meant it doesn't even try searching and prompts the "nothing found" message cos of some major bug. When you also use the content replacements it finds words in titles properly. --Subfader 19:46, 24 June 2009 (UTC)

Perhaps you meant "Replace text in page titles", previously. In any case, I see the problem with spaces in the search strings. Yaron Koren 20:02, 24 June 2009 (UTC)

Doh! Sorry for the confusion. At least it's spotted now. --Subfader 23:32, 24 June 2009 (UTC)

Well, maybe this experience with bug reporting can help you realize that this stuff isn't as easy as it looks. Yaron Koren 04:38, 25 June 2009 (UTC)

Just a thought...

This could perhaps somehow be turned into a category move feature, perhaps, maybe. With a little move button, like at the top of this page. Great extension, still; extraordinarily. :)

That's an interesting idea (a "complete move" tab?) and if it made sense for category pages, it would probably make sense for regular pages too. Such a tab might end up more confusing than it's worth, though, given all the options people get for text replacement. Yaron Koren 01:29, 16 June 2009 (UTC)

Yeah, I agree. Creates too much hassle. Still you need to del the old and create the new. --Subfader 00:46, 21 June 2009 (UTC)

I was wondering...

Is it possible to chose text that should not be replaced, so that if you wanted to replace all instances of "abc" with "abcd", but there are already instances of "abcd", you can say that the pre-existing instances of "abcd" would not become "abcdd"?

Currently you have to untick "abcd" in the preview or find "abc " or whatever follows c in your examples. --Subfader 22:14, 22 June 2009 (UTC)

That seems like it'll have to wait until there's support for regular expressions - otherwise, the interface for allowing all the possible combinations could easily get out of hand. Yaron Koren 23:26, 22 June 2009 (UTC)

Leading slash "\" fails in search

I was trying to do a search and replace on \begin{align} and it was failing to find any pages that contain that string. I commented out line 445 in the function doSearchQuery in the file SpecialReplaceText.php,

$search = str_replace(array("\\", "'"), array("\\\\", "\'"), $search);

This fixed my problem and I'm now able to search and replace for strings that start with '\'. However, I'm afraid that this line was here for a purpose and it might break elsewhere down the line. --Joshuagay 03:27, 10 July 2009 (UTC)

Hi, I can't duplicate this problem. Are you using an old version of Replace Text, or of MediaWiki? Or are you using a non-MySQL database, or some other unconventional database setup? Yaron Koren 22:10, 15 July 2009 (UTC)

Okay, the line has now been removed in version 0.6.7 - it was causing other problems, that I was able to reproduce. Hopefully this won't lead to yet other problems... Yaron Koren 18:53, 20 July 2009 (UTC)

Mediawiki 1.12

0.6.5 does not work with Mediawiki 1.12, because Xml::textarea is not supported there and Namespace is not yet renamed to MWNamespace. Please set the requirement on the main page to Mediawiki 1.13. --Barbe 05:47, 14 July 2009 (UTC)

Done, thanks; and sorry about the bad info. Yaron Koren 13:05, 14 July 2009 (UTC)

No problem. Although I know nothing about PHP, the (makeshift) backport took only a few minutes. After all the extension saved me a couple of hours. So the next drink's on me :-) --Barbe 17:04, 14 July 2009 (UTC)

respect bot flag

If the user replacing text is member of the group 'bot', the replacement-edits should not show up in recent changes.

I 'patched' that myself (although I don't 'speak' PHP) by changing line 67 in ReplaceTextJob.php from

$flags = EDIT_MINOR;

to

if ($wgUser->isAllowed('bot')) {
 $flags = EDIT_MINOR | EDIT_FORCE_BOT;
} else {
    $flags = EDIT_MINOR;
  }

Maybe something like this should be changed in the extension. Sorry for my poor english. Nachteule 23:55, 26 July 2009 (UTC)

We temp solved that by letting it be minor edits, but a i'd also prefer a complete hide. --Subfader 09:02, 27 July 2009 (UTC)

 Done in rev:54949. siebrand 16:58, 13 August 2009 (UTC)

[RESOLVED] Selection per category

I still think this is the next big step :) On teh form add a new input for Category names. If filled, the find/replaced only affects pages in the selected namespace(s) in the defined category. Any plans to add it? --Subfader 22:32, 8 August 2009 (UTC)

Oh, great it has been added. This makes things much faster on big wikis :)

• Bug: This should be easy to fix. Replace blanks with underscores from the cat input. Entering "Foo Bar" returns no results since it's stored in tables as "Foo_Bar".
• Improvement: If you search strings in a category that doesn't exist it would be good to return "Category:Foo doesn't exist", instead of just "String not found" (which is a big difference). --Subfader 17:15, 16 August 2009 (UTC)
• Bug: Apostrophes in the category name cause a MySQL error. --Subfader 14:47, 27 August 2009 (UTC)

Thanks for the two bug reports, and the improvement suggestion. They all make sense, and all have been fixed/addressed in the latest version, 0.7.1. Yaron Koren 00:14, 8 September 2009 (UTC)

Big thanks, everything works fine atm :) --Subfader 18:16, 8 September 2009 (UTC)

Yay! Yaron Koren 18:51, 8 September 2009 (UTC)

[FR] Prefix for pages to replace on

At translatewiki we use ReplaceText mostly to rename pages, but occasionally to replace text. When doing that in the MediaWiki: namespace, our wiki is unresponsive for over 5 minutes, because so much content has to be scanned 900k+ pages. It would be very helpful if we were able to scan with a prefix index for page names (like Special:PrefixIndex allows). This will save a lot of time, and allow more precise search and replace. siebrand 16:52, 13 August 2009 (UTC)

Would a category selector (like mentioned above) help accomplish the same thing, or would prefix be the only/best way to narrow down the search results in this case? Yaron Koren 17:04, 13 August 2009 (UTC)

In (I think all) the use cases at translatewiki.net, a category selector will be of no help at all. As we deal with messages that all have the same prefix, with a trailing language code, that's the ultimate tool for us at least. siebrand 22:44, 13 August 2009 (UTC)

Alright, it's some people's lucky day! I just released version 0.7, which contains new inputs for filtering both on category and on prefix. Please let me know if there are any problems. Yaron Koren 18:10, 14 August 2009 (UTC)

Made some small changes in the messages area just before you tagged. Haven't used it yet, but thanks a lot, Yaron. Now on to supporting regex on the content replacement ;) siebrand 19:45, 14 August 2009 (UTC)

0.7.1 issues

Hi Yaron

After installing 0.7 (and now 0.7.1), I am seeing a lot of missed selections in Replaced text.

For example, I have pages with 'Related to=Abc1,Abc2' in a template and 'This is related to Abc1' in the freetext. A search for 'Abc' does not return any page while a search for 'Abc1' returns one page with that string in a template but not other pages where the string is used as well.

And this is without Category filtering.

Very odd.

Any idea how I could troubleshoot this issue ?

- Laurent

That's odd, indeed... this might be the best way to troubleshoot the problem: create a page on your wiki that Replace Text should find, but doesn't; and make sure the page doesn't contain any private information. Then copy the page over to discoursedb.org, and let me know the search and replacement strings you used. Yaron Koren 19:06, 9 October 2009 (UTC)

I will keep looking for a reliable way to reproduce this issue. It seems very random at the moment. Another example, I am trying to rename a template. Doing a search for '{{TemplateA' and replace to '{{TemplateB' only returns 10 out of 44 pages using that template. Now all pages were created with the same template, and I do not have anything pending in my Jobs queue. - Laurent

|| Actually, it looks like either something is messed up with my data or it is a deeper issue that goes back further that 0.7.1. I rolled back to an older version (0.5.4) and I am still getting only 10 out of 44 pages looking for the template name. - Laurent

Problems, when extension finds a string inside a link

I installed your extension on MediaWiki 1.15.1 with PHP 5.4.12, it works, thanks. However, the first example showed up one page with the needle string in the checkbox selection list, the "needle" is inside a [link linktext] element, and this was not replaced with the current version. --Wikinaut 18:29, 21 December 2009 (UTC)

(Answer was: yes, it looks like a bug)

Not working for me

Everything seems to go right. There's the find page, the results page, and at the end (after clicking REEMPLAZAR, replace, I guess), I get the following:

Page name: Reemplazar texto

Message: 'string' será reemplazado con 'another string' en # páginas. Retornar al formulario.

In English is something like

Page name: Replace text

Message: 'string' will be replaced by 'another string' in # pages. Return to form.

However, nothing happens. I did a replacement a week ago and nothing. I get that previous message really fast too, which makes me think that nothing really happens behind it. Do I have to add anything else to my localsettings besides require_once( "$IP/extensions/ReplaceText/ReplaceText.php" ); and $wgGroupPermissions['sysop']['replacetext'] = true;? I'm definitely missing something because it works for everybody else! I'm using Mediawiki 1.15.1. and, by the way, this tool has become very valuable for anyone implementing semantic mediawiki because of the possibility to clean up template information from unwanted data (i.e. wiki markup) --Mark 10:40, 22 December 2009 (UTC)

Please go to the Special:Statistics page (or whatever it's called in Spanish :) ) and look for the job queue length. It could be that the job queue is just really long, and the 'replace' jobs still haven't been run, even a week later. Yaron Koren 15:29, 22 December 2009 (UTC)

Yaron, please, run for Prez. We need a man like you in the WH: Quick, efficient, patient... Anyway, MY GOD! My job queue was zero every time I saw it for YEARS. Now I have 1200 jobs running! How do I make them run fast? I tried the runJobs.php script but something is wrong. A couple of jobs ran and then:

Content-type: text/html

<br /> <b>Warning</b>: array_shift() [<a href='function.array-shift'>function.array-shift</a>]: The argument should be an array in <b>/home/content/c/o/j/cojoilustrado/html/maintenance/commandLine.inc</b> on line <b>42</b><br /> <br /> <b>Warning</b>: reset() [<a href='function.reset'>function.reset</a>]: Passed variable is not an array or object in <b>/home/content/c/o/j/cojoilustrado/html/maintenance/commandLine.inc</b> on line <b>54</b><br /> MediaWiki internal error. Exception caught inside exception handler

I know this is not the right place for this error (I think), but if you have an answer to this message I'd appreciate it. --Mark 23:37, 22 December 2009 (UTC)

OK, it's running. My job rate was 0 in my localsettings. I changed it to 3 (is that wise?) and the queue began to move down. After a few hundred ran runJobs again and it worked. I still get the errors above "Mediawiki internal error", but "Mediawiki internal error" and "Exception caught inside exception handler" are gone. By the way, those like me using flagged revs, don't pull your hairs (like I did) when articles seem unchanged. The character substitution is seen as an edit and need to be approved before showing up in the page. --Mark 00:00, 23 December 2009 (UTC)

Cool, it worked. If I ever run for president, I'm glad to know that I have at least one vote. :) Setting a "run rate" of 3 or even much higher is fine, as long as it doesn't cause page loads to become very slow. I don't know what's causing those error messages - probably some extension that had jobs in the queue. Yaron Koren 17:51, 23 December 2009 (UTC)

Just e-mail me for that vote. Totally yours. Thanks for your reply (sorry for my lateness, went on a road trip for the holidays). After testing the extension for a while, I can say that it works fine under the right conditions. Usually it chokes up on us but I believe this has nothing to do with the extension. We have a godaddy shared hosting account and through cache non logged in users experience a quite fast site, but when we log in (and we need to be logged in to use replace text), speed goes to hell. I've see other Mediawiki installations in shared hosting that are quite fast, even when logged in, but ours lags bad. Because of this environment, when searching for matches we don't get results. The page just clocks until it stops and Firefox (that is when using FF) prompts us to save an empty index.php file. This happens also when saving or previewing, not just with replacing text. Sometimes, our hosting is quite quick even though logged in (server neighbors not quite active, I guess), and in those cases replace text works like heaven. It takes a second for even the widest searches and the jobs queue runs fast with a 3 rate. I assume that's the way it works under the right conditions and give the extension a two thumbs way up. And that's it, bud. Thanks for all your help and all the best in 2010. --Mark 03:30, 4 January 2010 (UTC)

Okay, that's good to know, and thanks for the kind words! That "save an empty index.php file" thing is usually the sign of an overloaded server. Yaron Koren 18:30, 11 January 2010 (UTC)