Extension talk:Replace Text/Archive 2018

[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): . 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)

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: --Subfader 21:41, 18 March 2009 (UTC)
 * 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.


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


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

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)

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)

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

Moving issues (as of 0.5.1)
--Subfader 05:05, 1 May 2009 (UTC)
 * 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?"


 * 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
 * with
 * with

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 "", it shows in the page not the string "" 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
 * with
 * with

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: 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)
 * 1) Apply the "&lt;nowiki>{$this->replacement} " trick also for the 'replacetext_warning' system message (lines 132 & 138 of SpecialReplaceText.php)
 * 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: