<div dir="ltr">>

 just tell me,if possible,<br>>1/ what did you download (the file in wiki.d, the action=source page ?)<br>Yes, the 

action=source page<br><br>>2/ does Text Import keep your history, for edited pages which already had an history ?<br>Yes.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 4. Juli 2024 um 21:35 Uhr schrieb ABClf <<a href="mailto:languefrancaise@gmail.com">languefrancaise@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you for your comments.<br>
As for expanding PTV to more languages and accented words, it will be<br>
nice for people using such alphabets ;<br>
nonetheless, I may want to find and replace something else than a failing PTV.<br>
<br>
As text files are a flexible way to store data, it might be convenient<br>
to do text replacements with text editor.<br>
I understand PmWiki's flat files are a bit special though, and working<br>
directly on files not so easy.<br>
<br>
>From inside PmWiki, Wikish used to have basic sed tool (sed<br>
's/myname/yourname/g' Profiles.*) and in the best world, it would be<br>
convenient to have a search and replace tool working from inside<br>
pmwiki.<br>
<br>
Here it is my very rudimentary test :<br>
run a new pmwiki instance on some folder for testing purpose ;<br>
copy a bunch of files in wiki.d from my website.<br>
Go to test url and navigate : it works. Fine.<br>
<br>
Now, I connect to server with ssh ;<br>
search (grep) for pattern I want to change in wiki.d files<br>
check results : it looks good.<br>
<br>
Now change that pattern (one word) to see what will happen in real life :<br>
grep -rl %0apréface: | xargs sed -i 's/%0apréface:/%0apreface:/g'<br>
<br>
Change is done ; timestamp's files are updated to time of change<br>
(sadly no option in sed to preserve file time) ; pageindex doesn't<br>
look to bother (is not regenerated) ; browse page still work ;<br>
replacement is not in history of course ; PmWiki keep showing page<br>
last modified time according to time= if it exists.<br>
<br>
It might look rustic or brutal but it looks like it works (sure it<br>
works, PmWiki flat file need only 2 lines, plus 1 line for link list –<br>
PmWiki/PageFileFormat) ;<br>
question is what is the price to pay when :<br>
loose replacement step in history, have pageindex not up to date,<br>
time= different than file timestamp. Probably fastcache, if you use<br>
it, will have to regenerate cached files when they are browsed.<br>
Something else ?<br>
<br>
To Klaric, if your script is made for the search and replacement part,<br>
I think I don't need it, because the patterns I may want to replace<br>
are very limited ; big thank you for your offer ;).<br>
This said, using text import is interesting way of getting this work<br>
done from PmWiki itself. I will run some tests later ; just tell me,<br>
if possible,<br>
1/ what did you download (the file in wiki.d, the action=source page ?)<br>
2/ does Text Import keep your history, for edited pages which already<br>
had an history ?<br>
(I have used Text Import, but only for importing a bunch of ordinary<br>
plain text files created in text editor, not for text files coming<br>
from PmWiki).<br>
<br>
I understand it's a lot safer to have ready to use backup.<br>
<br>
Gilles.<br>
<br>
<br>
Le jeu. 4 juil. 2024 à 07:15, Petko Yotov <<a href="mailto:5ko@5ko.fr" target="_blank">5ko@5ko.fr</a>> a écrit :<br>
><br>
> There is this recipe International PTVs that might work without<br>
> mass-editing files:<br>
><br>
>    <a href="https://www.pmwiki.org/wiki/Cookbook/InternationalPTVs" rel="noreferrer" target="_blank">https://www.pmwiki.org/wiki/Cookbook/InternationalPTVs</a><br>
><br>
> I've put this recipe to the core candidates.<br>
><br>
> The bits that iPTVs don't work yet, for pagelist ordering, or in<br>
> pagelist templates, should be made to work. :-)<br>
><br>
> Alternatively, we can refactor PageTextVar() to allow pre-processing of<br>
> the page text before PTVs are extracted. This could allow you to define<br>
> variable replacements removing the accents, so that a text is valid:<br>
><br>
>    édition : Larousse<br>
><br>
> Then in the wiki you use {$:edition} without accents instead of<br>
> {$:édition}.<br>
><br>
><br>
> Note that in both cases FastCache may not detect a change in config.php<br>
> that modifies the pages HTML without the pages being modified.<br>
><br>
> As for the mass editing, I second Gregor's implied suggestion to not do<br>
> this directly on the live website. I'd also recommend having a backup<br>
> snapshot from before the operation, ready to be restored.<br>
><br>
> Petko<br>
><br>
> On 04/07/2024 00:39, ABClf wrote:<br>
> > I understand your answer, thank you.<br>
> > Here are more informations, to complete my question, in case someone<br>
> > has advice.<br>
> ><br>
> > At first stage, what I am planning to do are very basic and tiny<br>
> > replacements ;<br>
> > for example, I would like to able to replace things such as :<br>
> ><br>
> > édition :<br>
> > with<br>
> > edition :<br>
> ><br>
> > I guess I have around 20 terms to get replaced, affecting a few<br>
> > thousands of pages.<br>
> ><br>
> > For such a basic task (one word replacement, no multiline, no link<br>
> > affected), I would believe unix tools to be effective – as long as you<br>
> > know how to use them safely ;) – rather than playing with PmWiki API<br>
> > (first : far out of my knowledge ; second : I may have a lot of pages<br>
> > to process and it looks like overkill to edit/save hundreds or<br>
> > thousands pages for a one (or 10) word replacement).<br>
> ><br>
> > Also, for such a cosmetic/minor/negligible task, I don't mind about<br>
> > the diff ; I do restore pages sometimes, but not often, and I should<br>
> > be able to check the restored copy twice.<br>
> ><br>
> > I understand it is much better to preserve timestamp replacement<br>
> > (sure, I don't want to touch the unix time= data and indeed I do use<br>
> > fastcache recipe).<br>
> ><br>
> > At least, it is true that PmWiki file text format is somewhat tricky<br>
> > (to me, it is one of the very few things I regret with PmWiki) but the<br>
> > planned task would have very minimal impact and is expected to be<br>
> > quite easy.<br>
> ><br>
> > I didn't dare to use Anomen's XMLPageStore for my main site (if<br>
> > something bad happens will I be able to fix it ? if there is no more<br>
> > support in case of PHP incompatibility ?) but I do use it for a<br>
> > private and less important part with success. Wiki.d files created<br>
> > with that script are a lot cleaner.  No idea about the security<br>
> > issues.<br>
> ><br>
> > As for .pageindex creation, it takes long but it worked last time it<br>
> > ran ; nevertheless I'm not sure the server does like the experiment<br>
> > too much ; and because it is quite a big and long task in my case, I'm<br>
> > limited to regen .pageindex only if needed.<br>
> ><br>
> > Thank you,<br>
> > Gilles.<br>
> ><br>
> ><br>
> > Le mer. 3 juil. 2024 à 22:03, Petko Yotov <<a href="mailto:5ko@5ko.fr" target="_blank">5ko@5ko.fr</a>> a écrit :<br>
> >><br>
> >> On 03/07/2024 21:48, Petko Yotov wrote:<br>
> >> > PTVs are normally not indexed in .pageindex, only the page names, last<br>
> >> > modified times, and the list of words for searches.<br>
> >><br>
> >> Also the link targets from the page to other pages or to categories<br>
> >> are<br>
> >> stored in .pageindex.<br>
> >><br>
> >> Petko<br>
<br>
Le jeu. 4 juil. 2024 à 07:15, Petko Yotov <<a href="mailto:5ko@5ko.fr" target="_blank">5ko@5ko.fr</a>> a écrit :<br>
><br>
> There is this recipe International PTVs that might work without<br>
> mass-editing files:<br>
><br>
>    <a href="https://www.pmwiki.org/wiki/Cookbook/InternationalPTVs" rel="noreferrer" target="_blank">https://www.pmwiki.org/wiki/Cookbook/InternationalPTVs</a><br>
><br>
> I've put this recipe to the core candidates.<br>
><br>
> The bits that iPTVs don't work yet, for pagelist ordering, or in<br>
> pagelist templates, should be made to work. :-)<br>
><br>
> Alternatively, we can refactor PageTextVar() to allow pre-processing of<br>
> the page text before PTVs are extracted. This could allow you to define<br>
> variable replacements removing the accents, so that a text is valid:<br>
><br>
>    édition : Larousse<br>
><br>
> Then in the wiki you use {$:edition} without accents instead of<br>
> {$:édition}.<br>
><br>
><br>
> Note that in both cases FastCache may not detect a change in config.php<br>
> that modifies the pages HTML without the pages being modified.<br>
><br>
> As for the mass editing, I second Gregor's implied suggestion to not do<br>
> this directly on the live website. I'd also recommend having a backup<br>
> snapshot from before the operation, ready to be restored.<br>
><br>
> Petko<br>
><br>
> On 04/07/2024 00:39, ABClf wrote:<br>
> > I understand your answer, thank you.<br>
> > Here are more informations, to complete my question, in case someone<br>
> > has advice.<br>
> ><br>
> > At first stage, what I am planning to do are very basic and tiny<br>
> > replacements ;<br>
> > for example, I would like to able to replace things such as :<br>
> ><br>
> > édition :<br>
> > with<br>
> > edition :<br>
> ><br>
> > I guess I have around 20 terms to get replaced, affecting a few<br>
> > thousands of pages.<br>
> ><br>
> > For such a basic task (one word replacement, no multiline, no link<br>
> > affected), I would believe unix tools to be effective – as long as you<br>
> > know how to use them safely ;) – rather than playing with PmWiki API<br>
> > (first : far out of my knowledge ; second : I may have a lot of pages<br>
> > to process and it looks like overkill to edit/save hundreds or<br>
> > thousands pages for a one (or 10) word replacement).<br>
> ><br>
> > Also, for such a cosmetic/minor/negligible task, I don't mind about<br>
> > the diff ; I do restore pages sometimes, but not often, and I should<br>
> > be able to check the restored copy twice.<br>
> ><br>
> > I understand it is much better to preserve timestamp replacement<br>
> > (sure, I don't want to touch the unix time= data and indeed I do use<br>
> > fastcache recipe).<br>
> ><br>
> > At least, it is true that PmWiki file text format is somewhat tricky<br>
> > (to me, it is one of the very few things I regret with PmWiki) but the<br>
> > planned task would have very minimal impact and is expected to be<br>
> > quite easy.<br>
> ><br>
> > I didn't dare to use Anomen's XMLPageStore for my main site (if<br>
> > something bad happens will I be able to fix it ? if there is no more<br>
> > support in case of PHP incompatibility ?) but I do use it for a<br>
> > private and less important part with success. Wiki.d files created<br>
> > with that script are a lot cleaner.  No idea about the security<br>
> > issues.<br>
> ><br>
> > As for .pageindex creation, it takes long but it worked last time it<br>
> > ran ; nevertheless I'm not sure the server does like the experiment<br>
> > too much ; and because it is quite a big and long task in my case, I'm<br>
> > limited to regen .pageindex only if needed.<br>
> ><br>
> > Thank you,<br>
> > Gilles.<br>
> ><br>
> ><br>
> > Le mer. 3 juil. 2024 à 22:03, Petko Yotov <<a href="mailto:5ko@5ko.fr" target="_blank">5ko@5ko.fr</a>> a écrit :<br>
> >><br>
> >> On 03/07/2024 21:48, Petko Yotov wrote:<br>
> >> > PTVs are normally not indexed in .pageindex, only the page names, last<br>
> >> > modified times, and the list of words for searches.<br>
> >><br>
> >> Also the link targets from the page to other pages or to categories<br>
> >> are<br>
> >> stored in .pageindex.<br>
> >><br>
> >> Petko<br>
<br>
_______________________________________________<br>
pmwiki-users mailing list<br>
<a href="mailto:pmwiki-users@pmichaud.com" target="_blank">pmwiki-users@pmichaud.com</a><br>
<a href="http://www.pmichaud.com/mailman/listinfo/pmwiki-users" rel="noreferrer" target="_blank">http://www.pmichaud.com/mailman/listinfo/pmwiki-users</a><br>
</blockquote></div>