Over time I developed a little tool to convert a dumped "replace-text search result" page into MediaWiki code so I could post the result if needed.
In relation to this I wonder if the used filter setting could be included in the search result. For my purpose they would not be needed to be shown on the search result page. Including them in some comment/remark part would do the trick too.
Edit summary?... No no. I mean the form-page that shows the found results of a search. A lot of times I use ReplaceText just to search (without any intention to run a replace action(yet) - finding outliers, data collection, ...)
When it comes to posting the (auto-converted) result, potentially on a request of a user, It would be nice if one could also include the used filter settings off that particular search directly (ie: from the saved html-page of the search result page.)
On the main page it says one need to use "{$1}" (in some cases). But that did not really work, as it left behind the two brackets in the replaced text.
But by using "${1}" instead of "{$1}" I got the intended result.
(not sure if this is a relative new thing for which the main page is not update yet. kinda tricky if this is something that is version (or something else) depended ... which I don't know.)
Using v1.7 btw (replace_text page-interface)
Sorry about that - generally the main namespace is indeed selected by default, but you must have some PHP configuration where the code didn't work. If you apply the change here (a one-line change), hopefully it will work for you.
Thank you so much Yaron, looks like code changed a lot since 1.7 and that line cannot be found in my version: https://github.com/wikimedia/mediawiki-extensions-ReplaceText/blob/REL1_40/src/SpecialReplaceText.php
The line has changed, but you can still make this change - it's on line 679.
Yes, but the source line is quite different, for example the one starts with xml and the other with html. This was the end result of that change: https://ibb.co/jgkMPn8
Sorry, I meant that you should just make that one string replacement within the line, not to replace the entire line.
It seems not so difficult to implement, I wonder whether it is possible now, ie via a delimiter.
Hi all,
I have used the replaceAll.php script in the past without a problem, but for some reason it doesn't work for me anymore. What I try to do from the command line is the following:
php ./maintenance/replaceAll.php "some text" "the text that will replace the some text"
This returns: Couldn't translate '1' to a user.
php ./maintenance/replaceAll.php "some text" "the text that will replace the some text" --user="WikiSysop"
This returns: Couldn't translate 'WikiSysop' to a user.
The settings in the LocalSettings.php are:
wfLoadExtension( 'ReplaceText' );
$wgReplaceTextUser = "WikiSysop"; /*Just added this without success*/
$wgGroupPermissions['sysop']['replacetext'] = true;
$wgRunJobsAsync = false;
And this is on a mediawiki that runs:
- MW 1.41.2
- PHP 7.4.33 (fpm-fcgi)
- MySQL 8.0.36
Any idea what I might do wrong? Thanks!
And just to add some more info: The web interface of Replace Text does work fine, it is just that the script (replaceAll.php) doesn't for some reason. It tries to determine the user, which it can't find.....
FYI: In case somebody is running into the same thing; I hacked ReplaceAll.php; removed in the 'private function getUser()', the lines that check the User (if ( get_class( $user)Â !== 'User') {....}. The variable 'get_class ( $user )' gives as output 'Mediawiki\user\user', which doesn't match 'User'. Not sure why the get_class returns this, but the script ran well for me without this.
So by far not 'Solved', more like a dirty workaround.
I think ReplaceText put a bunch of <span class="error">Expansion depth limit exceeded</span> into some of my pages instead of the expected output. When I googled for solutions it appears that at least some other wikis have the same problem (e.g. https://wiki.gccollab.ca/index.php?title=Template:Cloud_Readings&mobileaction=toggle_view_desktop) It is possible that it wasn't ReplaceText that caused this, but since the actual markup on the wiki page was changed it seems the most likely candidate. I didn't catch this when it happened. Tenbergen (talk) 01:05, 12 September 2024 (UTC)
Its unlikely that ReplaceText itself had anything to do with this. It just reads/edits one page at a time without following/parsing included pages/code.
Its unclear here where those "<span class="error">Expansion depth limit exceeded</span>" lines turned up. If there not in the actual page-code itself ... there generated by mediawiki on page parsing. And as such are not related to ReplaceText itself. (Ie: its related to the applied edits/changes to those pages.)
Related information page: https://en.wikipedia.org/wiki/Wikipedia:Avoiding_MediaWiki_expansion_depth_limit
Thanks for your reply. On our wiki, the actual mediawiki markup ended up changed. I read the link you sent, and looked at the example with the 51 templates. For it, the markup remains as expected, but the templates don't expand right. On my wiki, the actual markup changed to have the ... text replacing the previous template call. It is possible that it wasn't ReplaceText that did it, but I am not sure what else would have updated a bunch of places on the site to ...
I can't really be specific due to lack of useful data. The biggest problem in my view comes from the "I didn't catch this when it happened." ... which turns any additional data into potential assumptions which might be irrelevant to your current problem.
The only things that come to my mind at this point are:
- Revert the changes that you think let to the problem. So you can try to debug the changes and see where things go wrong. (provided the problem went away)
and/or
- Inspect the effected pages (includes used, +resent changes) to try to track down where/when things went wrong.
Those might be expensive solutions to a problem that might be simple. But that's the best I can come up with.
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".
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?
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.
I would like the preview page with the found text passages (after hitting "Continue") to display a longer context before and after the reference, e.g. the whole line of text or the whole paragraph.
Which areas in the Replace Text scripts need to be adapted for this?
The context length is determined in this line. It looks like this code needs updating, because there is no longer a "contextchars" user preference, so the length is simply always 40. Perhaps there should be a setting for this, but for now, to increase the length, you would simply have to edit that line.
Hello everyone,
I am in the middle of updating a really old MW that was still running the HarvardReferences Extension. The current style for citations there looks like this: [Author Year: S. Pagenumber] (S stands for Seite = page in German), so e.g. [Smith 2014: S. 124]. Since I have to replace all those references with usual Cite references, I tried the following regex to find them but it did not return any result:
^\\[([^]]+) (\\d{4}): S\\. (\\d+)\\]$
Can you help me in figuring out what I am doing wrong at the moment?
Thanks in advance!
You don't need to double-escape: ^\[([^]]+) (\d{4}): S\. (\d+)\]$ should work fine (though note that I haven't tested this regex, so it may have other issues as well).
Thank you! I tried the expression you suggested but I stell get no pages on return. Simpler expressions (such as 'a(.*)c') work, though.
Try escaping the closing square bracket in your first class (i.e., write [^\]] instead of [^]]) or perhaps removing the beginning and/or end of line markers (^ and $).
Thanks! I just tried it but I still get the same result (no pages found). Could this be a DB issue or do you still think that this has something to do with the structure of the regex? As I said: simpler expressions do miraculously work...
At this point, the thing I'd suggest is to start with part of your target regex, test that it works, and then slowly add parts back to it until you find a part that causes it to stop working.
Its the "^" and "$" parts that don't work as intended/expected when I tried it.
Try "\n" or else real CR's/Enters. (depends on Replace Text version)
Ergo: "\n\[([^]]+) (\d{4}): S\. (\d+)\]\n"
Or:
"<hidden Enter>
\[([^]]+) (\d{4}): S\. (\d+)\]<hidden Enter>
"
Both options worked with Replace Text 1.7 (cba3752) 18:03, 14 March 2023. (+10.5.24-MariaDB)
If I remember correct I think the "^" and "$" only work for targeting the beginning and end of the whole text/page document.
Ergo: The whole text/page document should be looked at as one long string with no 'real' internal (^/$) line-breaks.
Thanks for your replies! I put in the expression(s) but I still get the same (= no) result but realized that while the first part \n\[([^]]+) works, the next one (year) does not.
Perhaps the match quantifier isn't supported. Instead of \d{4}, have you tried \d\d\d\d?
Replace Text: 1.7 (cba3752) 18:03, 14 March 2023. (+10.5.24-MariaDB)
I don't know what version of "Replace Text" supports what and/or what not. But if your using an older version, and can update it. That might be the best option at this point.
If your search string might also exist at the begin and/or end of the page text. "(^|\n)...(\n|$)" should do the trick (partially tested).
\d\d\d\d also doesn't work. I really think that the cause is rooted somewhere else, but I don't know where...
The wiki's is currently running with
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.
Same exact bug since upgrading to 1.39, text replace not seeing pages (and some matching text) until I edit the page. Thank you for the alternative tool.
