[Pmwiki-users] Re: PmWiki 0.5.23 and the old preview.php add-on

[Patrick R. Michaud]

On Mon, Sep 08, 2003 at 12:44:21PM +0200, Carlo Strozzi wrote:
> [...] However there is one problem with HTML special characters, 
> like "&" for instance. With the combination of the new PmWiki and 
> the old preview.php, they get encoded twice before they are inserted 
> in the preview textarea, so that, for instance, the [[<<]] becomes 
> [[&amp;&amp;]] in the output. 
>
> I would like to ask Patrick whether he devises any potential
> side-effects associated with not calling htmlspecialchars() in
> preview.php, like characters not being escaped in some circumstances,
> and that. As I always point-out, I am not a PHP expert (although that
> may eventually change, as I keep tweaking the PmWiki code :-)

Sure.  The characters have to be encoded via htmlspecialchars() in order
to correctly appear in the <textarea> box.  Prior to 0.5.21, the HandleEdit
routine did the htmlspecialchars on the $Text variable prior to 
formatting and displaying the contents of $PageEditFmt; after 0.5.21
the htmlspecialchars takes place inside of the FmtPageName(), when the
substitution for $Text takes place.  I didn't realize that preview.php 
was using the HandlePreview function to generate its own edit page and 
was also performing htmlspecialchars--thus it's incorrectly being done 
twice.  Sorry about that.

The quick fix is to do as you've done here--remove the 
   $Text = htmlspecialchars($Text,ENT_NOQUOTES);
line from preview.php when using it with PmWiki 0.5.21 or later.  A
more robust fix would be to have preview.php only do the htmlspecialchars()
if the version of PmWiki is prior to 0.5.21.

The "correct" long-term fix would be for me to define a new $EditText or 
$TextSpecial substitution to be used in HTML forms such as the edit page, 
and never change the contents of $Text.  Unfortunately, this would break 
backwards compatibility for everyone who has created a custom edit form in
$PageEditFmt, and I chose not to do that in 0.5.21 (although perhaps I 
should just bite the bullet and do it soon).  It's not a big break in 
compatibility--it just means changing $PageEditFmt to use $EditText instead 
of $Text--but I decided to save this change for a later version.

Pm