01175: Multi-line PmForm fields stored with "\r"
Description:
Problem
When using PmForm it looks like multi-line fields are stored in the base page with each %0a on a physically separate line, rather than the normal PmWiki way of storing the entire page text on a single line.
Here's a snip of what I mean. I've edited from the real thing to avoid email wrapping, but this demonstrates the end effect:
text=(:pmform savedata:)(:name:test %0amulti %0aline:)%0a(:email:djg:)%0a
Solution
From [1]: Adding the pattern below fixes the problem for new entries.
$PmFormPostPatterns['/\r/'] = '';
Notes
I can't view the underlying PITS entry pages, but I believe PITS uses PmForm, and so we should probably run a script in through the pages order to correct this problem.
Update: It looks like PITS uses PmForm to post to an edit page. The edit process will correctly remove the "\r" so existing PITS pages should be okay.U
No, PITS does not use PmForm, it is self-contained, see Cookbook:PITS. --Petko March 05, 2010, at 06:40 AM
Was the host where the problem occurred Windows or Linux? I'm wondering if there might be a bug related to CRLF and LF newline processing... Were you able to confirm whether it was CR or LF or CRLF causing the linebreak when you viewed the file in your editor? -Peter Bowers March 05, 2010, at 06:06 AM
I believe it doesn't come from the server host but from the client browser which submits the form with the carriage return \r character, which is not removed by PmForm. --Petko March 05, 2010, at 06:40 AM
@Peter: I tried on both Windows and Linux and the problem occurs on both. The character is "0D", carriage return. DaveG March 05, 2010, at 08:26 AM
The form is submitted as application/x-www-form-urlencoded, and according to the spec, "line breaks are represented as 'CR LF' pairs". So it's not really an issue of what browser you're using to submit the form, it's an issue of what OS and program you're using to view it. Since PmWiki reads PageStore files specifically looking for '\n' and the 'split' markup also specifically looks for '\n', the '\r' ends up as just white space in the resulting HTML. The $PmFormPostPatterns entry does fix this, but when I looked at how this is fixed when editing pages, I noticed that HandleEdit and other functions also call stripmagic(), which I don't see PmForm doing; should this too be fixed? —Eemeli Aro April 27, 2010, at 04:33 AM
The stripmagic() function is called from RequestArgs(), itself called the second line of HandlePmForm(). --Petko September 04, 2010, at 11:33 AM