Opened 12 years ago

Closed 3 years ago

#1391 closed defect (fixed)

PreserveScripts doesn't correctly handle php in html tags

Reported by: Adam J Owned by:
Priority: normal Milestone: 0.97
Component: Plugins Version: trunk
Severity: normal Keywords: PreserveScripts php
Cc: adam@…


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;


Attachments (2)

DOMwalk.js (12.6 KB) - added by adamj 10 years ago.
PreserveScripts.js (2.5 KB) - added by adamj 10 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 10 years ago by gogo

  • Milestone changed from 0.96 to 2.0

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.

comment:2 Changed 10 years ago by guest

I noticed that wysiwygPro supports this feature:

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

comment:3 Changed 10 years ago by guest

  • Milestone changed from 2.0 to 0.97

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

comment:4 Changed 10 years ago by 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';

comment:5 Changed 10 years ago by 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:
<option value="">choose</option>

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)

comment:6 Changed 10 years ago by 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.


Adam J

comment:7 Changed 10 years ago by gogo


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.

comment:8 Changed 10 years ago by gogo

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

comment:9 Changed 10 years ago by adamj

  • Reporter changed from guest to Adam J


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

comment:10 Changed 10 years ago by 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.

comment:11 Changed 10 years ago by adamj

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

comment:12 Changed 10 years ago by adamj

  • Cc adam@… added

comment:13 Changed 10 years ago by 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..

comment:14 Changed 10 years ago by 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.

Changed 10 years ago by adamj

Changed 10 years ago by adamj

comment:15 Changed 3 years ago by gogo

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.