I remember there being an option to suppress the generation of redirect pages (the known issues section in the instructions mentions this as well). As of ReplaceText version 1.7 I can't see that option on any of my wikis. The user in question has the rights to suppress redirects, and the option is present when I try to move an individual page. How do I make this option available again?
Extension talk:Replace Text
Do you mean an actual checkbox in the interface, or something like that? I don't remember such a thing. The "Known issues" section only mentions the 'suppressredirect' permission, I think. Or is that what you're talking about?
Seems there was such an option, or at least closely related.
See bottom of second screenshot in the Screenshots section. => "For moved pages: ..."
Oh - were you just talking about the "Save the old titles as redirects to the new titles" checkbox? That checkbox is still there.
I just used it on another of my wikis and that section is there, correct. But on this one and another it's not. Both are MW1.40 and ReplaceText 1.7, both use vector legacy (2010) skin. I uploaded a screenshot to demonstrate.
@Tenbergen: The search text 'needs' to be found inside the page-title for those "For Moved Pages" options to show up. (It was not possible to verify if that was, or was not, the case in your screenshots)
Arrrr yes. You are right, I would only expect to see it if there were pages found that could be moved. And when there are, it shows up. Thanks for explaining the obvious, sorry I wasted your time.
Not a (direct) showstopper as such.
When a page-title change would result in an empty page-title it triggered the following error. (Replace_text form interface)
[ZLjjNw_BJjdvj9s8jky3lgAAAAQ] /wiki/Special:ReplaceText TypeError: Argument 2 passed to MediaWiki\Page\PageCommandFactory::newMovePage() must be an instance of Title, null given, called in /var/www/mediawiki-1.39.0/extensions/ReplaceText/src/SpecialReplaceText.php on line 386 Backtrace: from /var/www/mediawiki-1.39.0/includes/page/PageCommandFactory.php(300) #0 /var/www/mediawiki-1.39.0/extensions/ReplaceText/src/SpecialReplaceText.php(386): MediaWiki\Page\PageCommandFactory->newMovePage(Title, NULL) #1 /var/www/mediawiki-1.39.0/extensions/ReplaceText/src/SpecialReplaceText.php(186): MediaWiki\Extension\ReplaceText\SpecialReplaceText->getTitlesForMoveAndUnmoveableTitles() #2 /var/www/mediawiki-1.39.0/extensions/ReplaceText/src/SpecialReplaceText.php(82): MediaWiki\Extension\ReplaceText\SpecialReplaceText->doSpecialReplaceText() #3 /var/www/mediawiki-1.39.0/includes/specialpage/SpecialPage.php(701): MediaWiki\Extension\ReplaceText\SpecialReplaceText->execute(NULL) #4 /var/www/mediawiki-1.39.0/includes/specialpage/SpecialPageFactory.php(1428): SpecialPage->run(NULL) #5 /var/www/mediawiki-1.39.0/includes/MediaWiki.php(316): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext) #6 /var/www/mediawiki-1.39.0/includes/MediaWiki.php(904): MediaWiki->performRequest() #7 /var/www/mediawiki-1.39.0/includes/MediaWiki.php(562): MediaWiki->main() #8 /var/www/mediawiki-1.39.0/index.php(50): MediaWiki->run() #9 /var/www/mediawiki-1.39.0/index.php(46): wfIndexMain() #10 {main}
MediaWiki: 1.39.0 PHP: 7.4.33 (fpm-fcgi) MariaDB: 10.5.19-MariaDB ICU: 50.2
Replace Text 1.7 (cba3752) 18:03, 14 March 2023
Related page could potentially be flagged as invalid case, and skipped as such.
Potentially printing that there where cases skipped because of the empty page-title replacement result.
Using the Original text:/Replacement text: form interface of this extension and the Use regular expressions option, what expressions can be used to find all spaces in File names to replace them with underscores?
The replacement should consider all and any markup begining with [[File: until .jpg, .png or other file type.
So anywhere from [[File: up until the first period becomes the searched pattern space:
[[File:Some file name.jpg|
... in which whitespaces should be replaced with underscores that may exist, resulting in:
[[File:Some_file_name.jpg|
Thanks
Why do you want to run this replacement? The software treats spaces and underscores the same in page/file names, and the general convention is to prefer spaces.
I agree, spaces are normally preferred.
However, unlike the usual metadata File page linked via images, I use a simplified image view.
Instead of [[File:Some image|800px]] on www.example.wiki leading to www.example.wiki/File:Some_image.jpg, images sometimes link to www.example.wiki/File.cgi?Some_image.jpg
File.cgi is an exception on my Apache that is bypassed by MW's default behaviour in returning non-existing page URLs, like: [[File:Some image.jpg|link=File.cgi?Some_image.jpg|800px]]
would achieve.
Using the link=
markup, Replace Text, either by command line or its form-based interface, would be the preferred method of replacing markup across many pages. A search and replace regex could for example:
- Extract the filename pattern between any
[[File:
until the first period before jpg, JPG, png, etc. - Place in variable and replace spaces in filenames with underscores.
- Insert the
|link=Some_image.jpg
variable in each[[File:
... enclosure, just berore its closing]]
.
This way the spaces and wiki markup can remain standard. The regex procedure would need to be idempotent to not operate on patterns which have File.cgi somewehere within [[File: .. File.cgi .. .jpg]]
already.
Or, perhaps it is easier to change the MW's File: procedures for image displays to link to example.wiki/File.cgi?... instead of to example.wiki/File:..., in which case the underscores will need to be present.
Can this be configured by hooks in LocalSettings or in one particular MW template or PHP file?
Thank you for any ideas.
That's horrifying. Depending on what exactly your File.cgi does, this really seems like something you should be doing via a specific class name + Javascript (whether that JS is just a shim between the markup and File.cgi, or fully implements the functionality of File.cgi itself, also depends on what exactly File.cgi does).
Anyways, you could probably torture regex into doing what you wanted (or something close to it), but tbh this sounds like something a proper bot would be more appropriate for.
Linking to an external page, file or location via the[[File: ... |link=..]]
markup is standard. Anyone who happens to be familiar with Replace Text's regex procedures, please kindly share your ideas how to insert the link markup above, bearing in mind the undercores needed in linked URLs which may be missing in the original [[File:Names of files.jpg]]
segments.
Its not something that can be done with a single RE-job in this extension (at least not that I know of).
Bare basic example that targets file-titles with two words:
REGEX:"(?i)\[\[:?file:([a-z0-9]+)[ ]([a-z0-9]+)\.([a-z]+)\|
"
Replace String:"$1_$2.$3
"
For titles with other word-counts one would need appropriately adjusted, including the replace string, versions.
Unless your sure you don't have titles with mixed "Underscore/Space" ... More work ahead (three or more words per title). You could try "[_ ]
" instead of "[ ]
" as long as you don't hit the maximum page result limit.
This is missing the later added "|link=
" part, as I have not looked at that part. Personally I think its better/easier to use a single RE-job to completely remover those parts first, and use accordingly adjusting Replace-Strings (from the example above) to re-add them.
(I probably don't know what I'm talking about and got it all wrong. And probably should not have reacted. Trying hard to work on that last part though.)
This is why I said ReplaceText regex isn't the right tool for the job. There is no way around having to multi-pass this if that's what you constrain yourself to.
Thanks for the above example. I presume a procedure to replace the spaces and insert the link= variables would require two or more steps.
There are different numbers of spaces in files depening on how many words different filenames happen to have but never a mix of spaces and underscores as in [[File:Some_ file name.jpg]]
in my wiki situation.
I tested the regex using Special page form interface of Replace Text:
Original text: (?i)\[\[:?file:([a-z0-9]+)[ ]([a-z0-9]+)\.([a-z]+)\|
Replacement text: $1_$2.$3
The following error was returned by the Special page:
Database error: A database query error has occurred. This may indicate a bug in the software.
But without indication of a database table, it's difficult to know the cause of the error in case a MySQL table needs to be repaired.
If that's not the problem, since my Replace Text works with other more simple regexes, the old REL1_27 version of Replace Text I have may be incompatibe with the above code example. Did you by any chance test-run the regex using the Replace Text form interface or the extension's replaceAll.php command line option?
Database error) That should not happen. On this side the example RE works ok (Using the Replace Text form interface).
Used Replace_Text version:
1.7 (cba3752) 18:03, 14 March 2023
With:
MediaWiki: 1.39.0 PHP: 7.4.33 (fpm-fcgi) MariaDB: 10.5.19-MariaDB ICU: 50.2
Ps: With mixed spaces and underscores I mean [[File:Some_file name.jpg]]
style links.
+Dinoguy1000 is right about "ReplaceText regex isn't the right tool for the job" in this case. Personally I would try to create a MW-bot for this. But that is not something that's done in a day if you have never used/created them.
Thank you for confirming your result. I'll test again with a newer MW installation.
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+?(.*)".)
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.
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.
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.
I don't want to duplicate it here, but I reported a problem on the Support Desk at Topic:Xepd60061zwhisr6. Essentially, dozens of pages ended up with this error message after using ReplaceText on them. I wonder whether anyone here has had this experience. Thanks.
Somewhat minor, but which could be a bit less ambiguous.
When the "Replace only in category" filter is used. And Replace-Text can't find the target string in any of the pages listed in the targeted category. It comes back with: No category exists with the name "Category:<+name>".
Technically:
1) Replace-Text just could not find any page that matched the search string.
2) Categories are of course a bit tricky. As they can exist as a page, but still be empty. Or they can contain pages, without actually having some page-content set.
Something like No matching pages found in/for the "Category:<+name>" seem a better feedback text for these cases.
Replace Text: 1.7 (8e35c8f) 19:50, 4 December 2022 MediaWiki: 1.39.0
> Or they can contain pages, without actually having some page-content set.
Is that the issue in your case? This seems to check if the category exists as a wiki page and if it doesn't, throws the error message you mentioned.
Mmm ... will have think a bit, and explore that code.
Although I'm not familiar with PHP ... other than a quick PHP crash-course at w3schools. The related code seems ok as far as I can tell.
The only thing that I could not figure out is what that exists()
part in line 280 is doing. It seems not a PHP native function, but I also could not find any reverence to it in the other ReplaceText codes on Github.
Considering the output I got, and the fact that the used category has pages linked to it and also a content-page. A failing category-detection at line 280 would kinda explain that result.
+(The used category also has no special name)
-- Searching with the Replace-Text MW-search-page.
-- Used Options shortcuts:
a) [Replace text in page contents]
b) [Replace text in page titles, when possible]
c) [Replace only in category]
These Options are displayed/presented to the user as seeming to be independent options.
Replace-Text behavior however shows that if option [a] is Off. All other option also 'seem' to be non-usable/-active.
For example:
With option [a] Off, but Option [b] On, and looking for "/doc" (templated"namespace) Replace-Text never finds anything.
Or:
If Option [c] is used (valid category specified), and option [a] is Off. A "/doc" search comes back with "No category exists with the name "Category:<used category>".
-- This seems more related to the fact that no matches where found.
For Replace-Text to provide less ambiguous UI-feedback to the user, based on this behavior, it kinda makes sense to auto-disable all options if [a] is Off.
... or to just lock Option [a] to On.
-- Not specific to any Replace-Text version.
It seems like the real issue is the bug that you can't replace text in only page titles, no?
By the way, I can't replicate this bug. What version of Replace Text are you using? And could it be that you have not selected all the necessary namespaces?
>It seems like the real issue is the bug that you can't replace text in only page titles, no?
If its intended that that should be possible with Replace-Text, than yea.
>... could it be that you have not selected all the necessary namespaces?
Unlikely. I first made sure Replace-Text found a bunch of pages, before trying it with the [Replace text in page contents] option disabled.
Specs:
Replace Text: 1.7 (8e35c8f) 19:50, 4 December 2022 - - - - MediaWiki: 1.39.0 PHP: 7.4.33 (fpm-fcgi) MariaDB: 10.5.18-MariaDB ICU: 50.2
Personally I can't recall any time that this worked on any version of Replace-text.
(only have used Replace-Text on the same wiki. Although with different MW-versions over time)
Ps: I'm not running/hosting the wiki. Just being its active admin.
Did run into case where I did get a 'found in title' result, while 1) there where no matches on title content. (Or 2) 'find in pages' was disabled.)
So there seems to be some additional (unknown at this point) trigger in play.
Will re-post, with more appropriate title, when I think I found that potential trigger.
(Closing: "Invalid/Insufficient data")
Running the search for words that should return are returning empty results, from both the web interface and CLI.
Everything else on the wiki appears to be working fine, when doing regular word searches it appears content on the pages are returned. Are the results generated from some other process? Oddly searches for words in templates appears to work. Also odd, for testing a search for 'the' one page does return and from the results it appears that page is just seeing that one word, not displaying any surrounding text, even though there are many other words on that page.
I recently upgraded from 1.35 to 1.39.1. Anyone else see similar issues?
After doing a small edit on a page, now that page does show up when I search for text using Replace Text. There have been many edits previously so I'm looking to see why those aren't showing up. Further edited pages now show also.
Perhaps some database needed to be initialized by running Replace Text?
I had $wgCompressRevisions set to true, now I see that in the 'known issues' section. Will set that to false and test further.
Setting it to false won't make it work, unless you edit all your pages to add a new uncompressed revision.
Using the suggested alternative MassEditRegex extension worked in my case. If Replace Text could issue a warning of some sort if $wgCompressRevisions set to true that would have been helpful, I likely set that following some optimization guide years ago but forgot about it.
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) :-)
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!)
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)
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?
let me recheck ....
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) ;-/
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.
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.
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.
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.
Thank you!!