PreserveScripts doesn't correctly handle php in html tags

[Adam J]

php can appear in html tags like this:

<input value="<?php print $foo;?>">

if u paste this into code view and then toggle html/ code - it comes back as:

<input src="/xinha-nightly/plugins/PreserveScripts/php.png" id="PreserveScripts?_1" value="&lt;img title=" />&quot;&gt;

AdamJ

[gogo]

Not so simple to fix because we'd need to go into more depth when parsing out these scripts so as to do different things in attributes. And we can't parse it using the DOM because of course it's not valid XML/HTML. Tricky.

[guest]

I noticed that wysiwygPro supports this feature: http://www.wysiwygpro.com/index.php?id=389

I played around with their demo and think I've figured out how they do it. When a script is in an attribute they replace it like so:

<input value="<?php print $foo;?>">

gets changed like so:

<input value="[WPSCODE'+encodeURIComponent('<?php print $foo;?>')+'WPSCODE]">

Resulting in:

<input value="[WPSCODE%3C%3Fphp%20print%20%24foo%3B%3F%3EWPSCODE]">

Adam J

[guest]

I can get PHP tag in attribute changed to: [PreserveScripts?_1]

This is stripped out by Xinha tho.

Can we get Xinha to ignore those blocks?

Bumped this up to 0.97 as I get the feeling this is fixable.

Adam J

[gogo]

Xinha should not strip out any valid attribute with well formed content. My suspicion here is that the attribute isn't well formed or valid.

Example, if you had something like

  <span <?php echo $On ? 'class="foo"' : '' ?> >

what would you "massage" that into for preserve scripts? You'd have to stick it into some special attribute.

It's probably possible, with adjustments to PreserveScripts? and also to the getHtmlMethod you use. Incidentally, you should try switching them to check the behavior in each, you may find that one already does what you want.

614	 /** This determines the method how the HTML output is generated.
615	  *  There are two choices:
616	  *
617	  *<table border="1">
618	  *   <tr>
619	  *       <td><em>DOMwalk</em></td>
620	  *       <td>This is the classic and proven method. It recusively traverses the DOM tree
621	  *           and builds the HTML string "from scratch". Tends to be a bit slow, especially in IE.</td>
622	  *   </tr>
623	  *   <tr>
624	  *       <td><em>TransformInnerHTML</em></td>
625	  *       <td>This method uses the JavaScript innerHTML property and relies on Regular Expressions to produce
626	  *            clean XHTML output. This method is much faster than the other one.</td>
627	  *     </tr>
628	  * </table>
629	  *
630	  *  Default: <code>"DOMwalk"</code>
631	  *
632	  * @type String
633	  */
634	  this.getHtmlMethod = 'DOMwalk';

[guest]

I've uncovered a bug here.

The attribute is valid and well-formed but xinha is being a little bit naughty by removing empty attributes.

Take this valid HTML for example: <select> <option value="">choose</option> </select>

The value is purposely left blank as it should not submit a value.

Xinha converts this code to:

<select> <option>choose</option> </select>

BTW please can I have an account to monitor bugs? (adam at bantha dot co dot uk)

[guest]

found the bit responsible for stripping empty attributes:

DOMwalk.js 242

if ( /^{(_moz)?$/.test(value) ) {}

// Mozilla reports some special tags // here; we don't need them. continue;

}

Adam J

[gogo]

Interesting.

That test looks unlikely to me, at first glance I'd have expected the test should be on name not value, and not anchored at both ends, just the start, and not matching the empty string.... ie

if ( /^(_moz)/.test(name) )

Will email login details.

[gogo]

PS: I'd suggest you make that change and test it in Firefox to see how it goes.

[adamj]

Thanks,

I've commented out that line and my empty attributes are preserved now so I can get back to working on the original bug.

[adamj]

BTW that was not coded I've added - but code that's already in there that is stripping attributes. If you take it out - then it works.

[adamj]

close to fixing this but I notice xinha is changing the order of the attributes - why oh why..

[adamj]

Having looked into it some more I think it's a browser thing as chrome retains the correct attribute order but firefox does not. I wonder how to get around this..

[adamj]

ok fixed the attribute order.

The nodes are retrieved in reverse order.

so in dom walk change line 130 to: for ( i = attrs.length-1; i >= 0; --i )

I will attach the amended files.