Re: [pmwiki-users] Content/Music - extremly long access-path via URL
thank you very much. If you have converters for this it should be easy to make work. I have some ideas for the future for our chorus singers: - for example, to let the user select a voice (let's say bass) and the instruments. I think I like one major/static midi, and indivduell temporary midi and mp3 for a specific surfer, which he can generate - playlists - easy mp3 download for mp3-players. - easy audioCD generation (for privileged users) - a commercial service would be imaginable... (create individual .isos for download). I have to think in general about what is usefull and how it can be implemented. I let you know, when I have some specific technically questions about ABCM-implementation. Patrick P.S. If somebody likes to share ABC stuff, let me know. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Strip markup to generate plain text
Perhaps a stupid question but is there some way to generate
plain text from pmwiki content source?
I wasn't sure what you meant by markdown -- do you mean plain text
*after* markup has been applied? Or are you looking for the source text
with the markup still visible? Or (as your subject might indicate) are you
looking for the text with the markup simply stripped out?
I'm guessing you're already familiar with the ?action=source addition on the
URL? That gives you access to the source. (Or simply edit the page.)
If you're looking for the source text and want to do a bunch of pages (i.e.,
specifying ?action=source or editing each page is not an option) then within
the next few days the {(cp ...)} function from WikiSh will give you that
capability. You will be able to specify {(cp MyGroup.* GroupB.FileA
TEXT--newdir)} where MyGroup.* and GroupB.FileA represent the types of
file-patterns you can specify and newdir represents an existing directory.
The TEXT-- means that you want them written out in simple text rather than
being copied as wiki pages.
I had started this function last night before I saw your email, but it won't
be done for a few day or so, probably. If you need it urgently let me know
and I'll see if I can carve out some time for it tonight...
If you are looking for plain text with markup stripped out then you may want
to look into Hans's ExtractText with the markup=snip option. You could
search for . (i.e., return every line) and specify markup=snip so that
you got markup simply deleted. [Hans, might a SnipMarkup() function with a
corresponding {(SnipMarkup ...)} MX be a good function to have available in
PowerTools? Just a tho't... I know I could make use of it with WikiSh.]
If these (viewing source or viewing source without markup codes) is not what
you're looking for then my apologies -- you may want to look into some of
the caching recipes to see a post-markup version. I believe these recipes
result in HTML, though, which probably is not what you're looking for if
you're looking for plain text. You can also generate PDF using another
recipe called PublishPDF. Maybe one of these recipes might have an option
to produce plain text? That's a shot in the dark...
-Peter
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Strip markup to generate plain text
Wednesday, February 13, 2008, 9:43:24 AM, Peter Melodye Bowers wrote: If you are looking for plain text with markup stripped out then you may want to look into Hans's ExtractText with the markup=snip option. You could search for . (i.e., return every line) and specify markup=snip so that you got markup simply deleted. It is TextExtract: http://www.pmwiki.org/wiki/Cookbook/TextExtract There is no option markup=snip, but a markup=cut option. This will cut out lines which have directives of syntax (::) in them. It does not clean out wiki markup. Inluine and link markup etc. are preserved and active. I have not got a strip-bare-of-wiki-markup option. ~Hans ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Bugs in TextSection and MakePageName
On Wednesday 13 February 2008, Hans wrote: I think I found a bug in function TextSection (pmwiki.php): The function did not return the correct text when using the suffix ..#section to a pagename, which should return all text up to anchor [[#section]]. [...] I need that for placing a manipulated section back into the whole text. Fox is doing this, and I now had to create a slightly modified version of TextSection in order to get the section position. Fox is the new ZAP. ;-) No, this is not a bug, you are using it incorrectly. You need to use: Page##section or: Page#..#section and not Page..#section Related to this I think there is also a bug in function MakePageName: It appears that MakePageName does not deliver a pagename if the name supplied has a suffix '..#section'. It strips off any other anchor suffix, but not this one. See above for the correct syntax. Thanks, Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Bugs in TextSection and MakePageName
Wednesday, February 13, 2008, 1:12:49 PM, Petko Yotov wrote: No, this is not a bug, you are using it incorrectly. You need to use: Page##section or: Page#..#section and not Page..#section Thanks, I am happy to be corrected! Then the documentation is wrong (the commenting of the function in pmwiki.php): ## TextSection extracts a section of text delimited by page anchors. ## The $sections parameter can have the form ###abc - [[#abc]] to next anchor ###abc#def - [[#abc]] up to [[#def]] ###abc#, #abc.. - [[#abc]] to end of text ####abc, ..#abc - beginning of text to [[#abc]] ## Returns the text unchanged if no sections are requested, ## or false if a requested beginning anchor isn't in the text. and ..#abc mirrors #abc.., so intuitively one could expect syntax PageName..#abc to work (and it does with the changes I noted). ~Hans ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Strip markup to generate plain text
Wednesday, February 13, 2008, 9:43:24 AM, Peter Melodye Bowers wrote:
[Hans, might a SnipMarkup() function with a
corresponding {(SnipMarkup ...)} MX be a good function to have available in
PowerTools? Just a tho't... I know I could make use of it with WikiSh.]
If the aim is to strip out every PmWiki markup, then this is not an
easy task. I think we would need a bunch of StripMarkup rules, one for
each markup, so the StripMarkup engine can use a reverse Markup Table
with these StripMarkup rules. Basically a reversing engine.
I have no stomach to develop this, sorry. ;-)
~Hans
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Strip markup to generate plain text
On Wednesday 13 February 2008, Hans wrote:
Wednesday, February 13, 2008, 9:43:24 AM, Peter Melodye Bowers wrote:
[Hans, might a SnipMarkup() function with a
corresponding {(SnipMarkup ...)} MX be a good function to have available
in PowerTools? Just a tho't... I know I could make use of it with
WikiSh.]
If the aim is to strip out every PmWiki markup, then this is not an
easy task. I think we would need a bunch of StripMarkup rules, one for
each markup, so the StripMarkup engine can use a reverse Markup Table
with these StripMarkup rules. Basically a reversing engine.
I have no stomach to develop this, sorry. ;-)
How about something like :
return Keep(strip_tags(MarkupToHTML($MyMarkup), pbr));
(strip_tags() is at http://php.net/strip_tags )
This will be very slow if called multiple times, but for some cases it may be
worth it.
Petko
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Bugs in TextSection and MakePageName
Wednesday, February 13, 2008, 2:22:42 PM, Petko Yotov wrote: Anyhow, I hope that you will be able to change Fox to use ##section instead of ..#section for it to work without your users required to modify core scripts. :-) Oh I think Fox does already. I just wanted it to be fully able to use the ..#abc syntax as well, as i though tit was valid from the function commentary. And it gave me plenty of headache... so NOT to be able to have to cater for page..#anchor is a relief! That said despite my earlier mark that it is an intuitively correct mirror of #abc... I guess that is the reason Pm put it into the commentary, following his own intuition. I hope it gets changed so the commentary is correct. ~Hans ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Strip markup to generate plain text
Sorry for being so unclear. Markdown in this case is text formatting system that is quite popular http://daringfireball.net/projects/markdown/syntax. But what I'm looking for is something that will allow me to strip PmWiki syntax from the stuff I've written and generate plain text. Even better would be a something that generated slightly formatted text. If you could give a list of elements you would want to replace and what you would want to replace them with I'm sure some sort of markup2markdown could be put together. It doesn't sound like a difficult thing to build -- just a bunch of preg_replace's unless you want stuff done with multi-line markups and conditional and etc. The thing that will take time and effort is coming up with the list of changes that would look like this: ORIGINAL: [[link]] CHANGE TO: link ORIGINAL: [[link|title]] CHANGE TO: title ORIGINAL: ''text'' CHANGE TO: text ORIGINAL: '''text''' CHANGE TO: text ORIGINAL: - text CHANGE TO: tabtext -or- CHANGE TO: 4 spacestext Etc. If you'll get me a list like that I'll put it into an MX for inclusion in PowerTools (if Hans is agreeable for that location). Or I can give you the skeleton for it and you can put the preg_replaces yourself if you're into that... -Peter ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Bugs in TextSection and MakePageName
On Wed, Feb 13, 2008 at 02:37:35PM +, Hans wrote: Wednesday, February 13, 2008, 2:22:42 PM, Petko Yotov wrote: Anyhow, I hope that you will be able to change Fox to use ##section instead of ..#section for it to work without your users required to modify core scripts. :-) Oh I think Fox does already. I just wanted it to be fully able to use the ..#abc syntax as well, as i though tit was valid from the function commentary. And it gave me plenty of headache... so NOT to be able to have to cater for page..#anchor is a relief! That said despite my earlier mark that it is an intuitively correct mirror of #abc... I guess that is the reason Pm put it into the commentary, following his own intuition. I hope it gets changed so the commentary is correct. Petko is correct, the comments are wrong and the correct syntax for everything up to an anchor is either ##abc or #..#abc. The leading '#' is necessary to tell PmWiki that we're talking about anchors, as opposed to dots being used for some other purpose. I'll correct the comments in the code immediately. Thanks! Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] 2.2.0-beta65 and InitialPasswords
On Wed, Feb 13, 2008 at 12:50:33AM -0500, Aaron wrote: I recently installed 2.2.0-beta65 and have been having great luck with it. However, I uncovered some funniness tonight with regards to the information in the InitialPasswords page (http://www.pmwiki.org/wiki/PmWiki/InitialPasswords). From the page: 2. The change page attributes action is locked for the Main, PmWiki, SiteAdmin, and Site workgroups. Actually, I just ran a test using a new browser (IE, which I never use) and found that without specifying a password, I can muck around with the attr action on any page in Main and PmWiki. SiteAdmin and Site seem to be properly locked off. Hmm, there appear to be several things going on here. First, the InitialPasswords page itself is misleading -- it's not part of the official PmWiki documentation, nor has it ever been. It appear to duplicate the information that is already in PmWiki.PasswordsAdmin. The remainder of the information (What Passwords to Set) should probably go in a Cookbook recipe and be linked to from the PasswordsAdmin page. Obviously, these are easily solvable problems on my end as a site admin, but I wanted to send the feedback so that either the code could be changed or the InitialPasswords page changed to reflect the behavior of 2.2.0. [Full disclosure: I haven't tested 2.1.27, so I don't know if the behavior described in InitialPasswords is correct for that version.] You're correct that the information about the PmWiki and Main groups being locked is no longer true -- we eliminated the locking in 2.1.beta15 but apparently the documentation was never updated. I think we should eliminate and/or refactor the InitialPasswords page, and then update PasswordsAdmin with the correct information. Thanks! Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Duplicate email notification
Wednesday, February 13, 2008, 5:30:21 PM, Patrick R. Michaud wrote: This is probably the source of the difficulty -- NotifyUpdate really doesn't expect to be called more than once in a given session. But if multiple pages are being updated via UpdatePage(), then it would get reigstered multiple times and result in multiple postings. And if squelch is zero, or the squelch period has passed, then this could potentially generate multiple email messages for the same post. I find it quite alright that for multiple page postings multiple notifications are generated. If squelch is set to zero it will come as a burst of emails. Randy's problem was that he got duplicates of the same notification. After a lengthy investigation we found that a change in notify.php would stop that behaviour: changing this in notify.php: ## check if we need to do notifications if ($action != 'edit') NotifyCheck($pagename); to this: ## check if we need to do notifications if ($action!='edit' $action!='foxpost' $action!='foxdelete' $action!='comment') NotifyCheck($pagename); Then Fox and Commentboxplus will not generate a NotifyCheck. and he had the problem of duplicates specifically with fox and commentboxplus postings, which use the actions included above. Why his server's mailing system (or php or what) creates duplicates, but not my or other folks system, I don't know. The hack works, but the reason for the problem is not found yet. ~Hans ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Duplicate email notification
On Wednesday 13 February 2008, Hans wrote:
Randy's problem was that he got duplicates of the same notification.
After a lengthy investigation we found that a change in notify.php
would stop that behaviour:
changing this in notify.php:
## check if we need to do notifications
if ($action != 'edit') NotifyCheck($pagename);
to this:
## check if we need to do notifications
if ($action!='edit' $action!='foxpost' $action!='foxdelete'
$action!='comment')
NotifyCheck($pagename);
Then Fox and Commentboxplus will not generate a NotifyCheck.
and he had the problem of duplicates specifically with fox and
commentboxplus postings, which use the actions included above.
Hey wait a minute!! Don't search what changes in PmWiki core would serve your
recipes, try to adapt your code instead. PmWiki has countless possibilities
to do this.
In the current case: there is yet no need to change notify.php. You can
instead have in config.php:
if($action!='foxpost'
$action!='foxdelete' $action!='comment')
{
$EnableNotify = 1;
}
Petko
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Duplicate email notification
On Fri, Feb 08, 2008 at 10:03:06AM +, Hans wrote: I suspect something goes wrong there for you, and NotifyUpdate is twice registered, and twice executed, resulting in double emails. Why I do not know. But notify.php has no mechanism to prevent the NotifyUpdate function from being twice registered for execution. Maybe there is some sense in it, but maybe this should not happen. This is probably the source of the difficulty -- NotifyUpdate really doesn't expect to be called more than once in a given session. But if multiple pages are being updated via UpdatePage(), then it would get reigstered multiple times and result in multiple postings. And if squelch is zero, or the squelch period has passed, then this could potentially generate multiple email messages for the same post. I think the fix would be to have PostNotify() store update information into an array, and have NotifyUpdate() process that array instead of checking and handling $IsPagePosted directly. Then we could fix it so that NotifyUpdate() is only registered once, at which point it does all processing as it's designed to do now. Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Cookbook path
On Sun, Feb 10, 2008 at 05:52:30PM -0500, DaveG wrote:
I'm writing a Cookbook (or Recipe, I never know which is which), and I
need to get the URL of the location that the script is executing from --
basically the cookbook directory. This way gets me the script *path*
(not the URL), which isn't quite what I need:
dirname(__FILE__)
The best I have so far is this (extracted from pmwiki.php), but that
assumes the location of cookbook directory.
preg_replace('#/[^/]*$#', '/cookbook', $ScriptUrl, 1)
Anyone done this before?
In the most general case it's not possible to automatically determine
the url of an executable script. This is why PmWiki has to guess
at values of $ScriptUrl and $PubDirUrl when it is invoked, but sometimes
guesses wrong if the system has been configured with url aliasing
or CleanUrls or any number of other items that may change the url-to-file
mapping.
That said, if you have files that you want to be available directly
via the webserver from a url, then those files really belong in
the 'pub/' subdirectory and not in 'cookbook/'. And you can presume
that $PubDirUrl is properly set (either automatically or manually by
the admin) to the url that corresponds to the pub/ directory.
Hope this helps,
Pm
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] FW: UpdatePage() vs save from ?action=edit
On Fri, Feb 08, 2008 at 09:52:04PM +0100, Peter Melodye Bowers wrote: Did anybody have any thoughts on this? I'm guessing it has something to do with what functions are registered in EditFunctions before calling UpdatePage()? To rephrase my question below, I am creating new pages using UpdatePage(). The pages are created, but they are not being placed in .pageindex until I manually edit and save them. What do I need to do to bypass this manual step? When is UpdatePage() being called? Perhaps it is being invoked before pagelist.php has been loaded? Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Content/Music - extremly long access-path via URL
--- Patrick Ogay [EMAIL PROTECTED] wrote: But Exsultate justi definitely made problems (in Moz) and I changed it to (:music:) again. http://www.wprj.net/chor/index.php/Tunes/ViadanaExsultateJusti I looked at your page above. I pasted the abcm into my test wiki here: http://www.theficks.name/test/Content/pmwiki.php?n=Music.Huge What I see is what I would have guessed. The page renders fine when I save it (short URLs), including the midi link, but if I try to preview it it chokes. During the preview the links (such as the midi one) are as to be expected, indeed huge. I will look into creating one of the workarounds that I mentioned in the previous emails. But you should know that you can probably just go ahead and use the (:abcm:) tag just fine for that song, just not when previewing it on edits! -Martin Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Duplicate email notification
On Wed, Feb 13, 2008 at 05:45:10PM +, Hans wrote: Wednesday, February 13, 2008, 5:30:21 PM, Patrick R. Michaud wrote: This is probably the source of the difficulty -- NotifyUpdate really doesn't expect to be called more than once in a given session. But if multiple pages are being updated via UpdatePage(), then it would get reigstered multiple times and result in multiple postings. ... Randy's problem was that he got duplicates of the same notification. After a lengthy investigation we found that a change in notify.php would stop that behaviour: changing this in notify.php: ## check if we need to do notifications if ($action != 'edit') NotifyCheck($pagename); to this: ## check if we need to do notifications if ($action!='edit' $action!='foxpost' $action!='foxdelete' $action!='comment') NotifyCheck($pagename); Then Fox and Commentboxplus will not generate a NotifyCheck. and he had the problem of duplicates specifically with fox and commentboxplus postings, which use the actions included above. Why his server's mailing system (or php or what) creates duplicates, but not my or other folks system, I don't know. The hack works, but the reason for the problem is not found yet. Sure, the problem is exactly as I mentioned above: NotifyUpdate was being registered more than once -- one time as a result of NotifyCheck (because $action!='edit'), and then again as a result of UpdatePage. However, since NotifyUpdate only checks $IsPagePosted to determine if it needs to add a notification, and since $IsPagePosted would be true as of the point where NotifyUpdate is called each time, it would end up generating two separate notifications. Thus, fixing notify.php so that NotifyUpdate is only invoked once, and using an array of updated pages (instead of assuming that $pagename is the page being updated) should go a long way to resolve this particular problem. Thanks! Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] java pop-up for duplicate upload name
david roundell said... i would like to have a script to warn our users that the filename they intend to use on an upload is already in use. ideally the pop-up should state are you sure you wish to overwrite the file yes/no? whether this should be in java or html is not essential. Well, Java would be overkill, but I suspect that you mean JavaScript ;-) the script needs to work for i.e6 only as it is only used at work and i.e6 is the only browser we can use! Ouch! But really, no-one here is likely to want to produce something for any one browser, perhaps least of all IE6 which was, and remains, a disaster. similar to this script: http://www.pmwiki.org/wiki/Cookbook/ConfirmEditNotSaved I don't know this recipe, but you might want to consider the $EnableUploadVersions option. See the docs: $EnableUploadVersions When set to 1 (default is 0), uploading a file to a location where a file of the same name already exists causes the old version to be renamed to file.ext,timestamp (instead of being overwritten). timestamp is a Unix-style timestamp. Alternatively, the fix looks like pointing $UploadVerifyFunction, at your own function and, probably, calling UploadVerifyBasic() before your code - with an appropriate escape for the '' return value. It might even work in IE6! -- Cheers, Marc ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Duplicate email notification
Wednesday, February 13, 2008, 5:58:51 PM, Petko Yotov wrote:
Hey wait a minute!! Don't search what changes in PmWiki core would serve your
recipes, try to adapt your code instead. PmWiki has countless possibilities
to do this.
Sure. I only tried to find a solution to someone's particular problem
(duplicate notification emails), which I have not encountered
anywhere else or with anyone else, and which reasons I still fail to
understand fully. I do not know if notify.php in general needs to be
changed, also it seems Pm has an idea now, which will prevent such
isolated problems in future for anyone.
In the current case: there is yet no need to change notify.php. You can
instead have in config.php:
if($action!='foxpost'
$action!='foxdelete' $action!='comment')
{
$EnableNotify = 1;
}
Thanks, very nice! I hope Randy takes note of that, as it will help
ease of upgrading his PmWiki system.
~Hans
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Duplicate email notification
Wednesday, February 13, 2008, 6:07:48 PM, Patrick R. Michaud wrote: Thus, fixing notify.php so that NotifyUpdate is only invoked once, and using an array of updated pages (instead of assuming that $pagename is the page being updated) should go a long way to resolve this particular problem. Yes, very good! I still don't understand why one system sends out duplicated emails and others not. Following your reasoning I would expect this problem to be a general one for anyone using Fox or CommentBoxPlus, which it has not been. ~Hans ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Duplicate email notification
Much easier! Thank you.
I tested it in on a couple of different forms and it seems to work.
Randy
On Feb 13, 2008, at 1:21 PM, Hans wrote:
In the current case: there is yet no need to change notify.php. You
can
instead have in config.php:
if($action!='foxpost'
$action!='foxdelete' $action!='comment')
{
$EnableNotify = 1;
}
Thanks, very nice! I hope Randy takes note of that, as it will help
ease of upgrading his PmWiki system.
~Hans
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] MySQL and Notify?
I've been asked to put up a simple volunteering form on a PmWiki website. They would like the results from the form to be stored in a MySQL database, and a copy of the data emailed to the person in charge of volunteers. I know of recipes to store form data in a database, and ones to mail results to someone, but what's the best way to do both? Use a database recipe and some variation of Notify perhaps? Will they even play nice together? Any suggestions would be helpful, although I should mention that I'm not interested in using Zap. The learning curve for getting MySQL working is already steep enough (I've never used it before), so I don't want to add to the difficulty. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users-fr] UTF8 / Latin-1 et pmwiki.... ;(
Bonjour, Je suis en train de lutter depuis quelques semaines sur une migration de machine d'un pmwiki... Le problème que j'ai c'est que j'ai des accents (grrr !) dans les noms de fichiers et que j'ai l'avantage, et l'heureux problème d'avoir des noms de fichiers avec aussi bien des accents en UTF8 (du a la mise a jour en 2.x de pmwiki), mais aussi en Latin-1... Bref j'ai perdu des données et est-ce qu'il y aurais un truc magique pour : - migrer les liens dans les fichiers du wiki sans pertes de données - faire de sorte que pmwiki n'ai pas l'idée géniale d'écrire en latin1 et UTF8 dans le filesystem ? Voila... Si qqn a déjà ce genre de problèmes et as la solution magique... /Xavier ___ pmwiki-users-fr mailing list pmwiki-users-fr@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users-fr
