Problem With Version 11.0.5 and Larger 'Other Info' Box

[Garry T]

I recently changed to a Windows 8 pc and therefore had to upgrade to version 11.0.5 of SellerDeck to overcome the IE 11 upload problems. I had previously implemented the “Larger Box for the 'Other Info' Prompt” on my website as detailed in the Advanced User Guide but since upgrading to version 11.0.5 I notice that when someone enters multiple lines in the Other Info Box their input is displayed rather oddly in the Shopping Basket - It seems that the carriage returns are now being handled incorrectly.

As an example, if someone enters the following in the Other Info Box:-

Line 1
Line 2
Line 3

It gets shown all on one line as follows on the Bounce Page and in checkout:-

Line 1 %0aLine 2 %0aLine 3

And as the following in the Basket:

Line 1
%0aLine 2
%0aLine 3

As you can see the carriage returns are showing as %0a. Has anyone else noticed this problem and any ideas on fixing it? I tried resetting all the Perl scripts to their factory settings and then following the AUG again but still the same problem so it seems as though whatever was changed in 11.0.5 to fix the IE11 problem has caused this one.

I hope someone can shed some light on this, cheers.

[NormanRouxel]

The KB article on using a TEXTREA is 2009 vintage and has the same problems on a SD2013 site.

I've re-done it for SD 2013. Try using the tweaks there on your 11.0.5 site.

[Garry T]

Thanks for the replies. I seem to have found a solution by just editing ActinicOrder.pm that means you don’t need the JavaScript on the Cart Page and it is slightly different to the 2013 changes.

In 11.0.5’s ActinicOrder.pm file there’s a line of code, just above the IF statement that gets edited for the TEXTAREA amendments in the KB article, which says:-

$sValue = ACTINIC::HTMLEncode($sValue);

This line of code seems to force the %0a’s to be displayed and prevents the line of code “$sValue =~ s/%0a//ig;” from removing all the instances of %0a. If I comment out, or remove “$sValue = ACTINIC::HTMLEncode($sValue);” then all the %0a’s get removed from the customers text as desired.

The question is what does “$sValue = ACTINIC::HTMLEncode($sValue);” do, and would just removing this line from this function cause any unwanted issues? I assume this line of code is there for a reason?

Any views would be appreciated (I hope my explanation above makes some sense).

Thanks.

[NormanRouxel]

That line is (I think) intended to stop people hacking the site by entering HTML tags (SCRIPT IFRAME, etc) in the Other Info field and then getting it to evaluate on subsequent pages.

[Garry T]

Ah, thanks, probably not the best idea to completely comment it out then! It would seem that the simple solution would be to move it to after the "$sValue =~ s/%0a//ig;" line of code so that the the %0a's get removed first. The block of code in ActinicOrder.pm would be as follows:-

$sHTML = ACTINIC::GetPhrase(-1, 2161);
$sHTML =~ s/%d/%s/;
$sValue =~ s/%0a//ig; # we seem to need to remove some Line Feeds here
$sValue = ACTINIC::HTMLEncode($sValue);
$sHTML = sprintf( $sHTML, "", $sIndex, $sStyle, 1000, $sValue);

I've tried it out and all user text is shown correctly in Bounce Page, Cart and Checkout Pages without the need for the JavaScript as detailed in the workaround, and I assume the "security" etc from the "$sValue = ACTINIC::HTMLEncode($sValue);" line is still valid?

[NormanRouxel]

I can't see how that works for the bounce page (checkout and receipt, too). You'd get everything on one long line.

In my SD 2013 tweak, I had to translate %0a into <br> for the bounce type pages and strip it for the editable pages.

The code that needs patching in ActinicOrder.pm is identical between 11.0.5 and SD 12.0.2 / 3 so my patch (step 11) should work on SD 11.0.5.

[Garry T]

I've not got SD2013 so I wouldn't really know, it might be because I moved "$sValue = ACTINIC::HTMLEncode($sValue);" from before the IF statement to inside the ELSE, as suggested in the workaround linked to in post 2?

I noticed something in IE11 which added a complication for me!
"$sValue = ACTINIC::HTMLEncode($sValue);" sets line breaks to "& # 1 3 ;". It seems as though all browsers treat this as a line break except for IE11 which just doesn't so I had to translate this string to \r (this was just on the shopping cart page). It would have been much easier just to implement the workaround from post 2, I was just determined to try to do it all in the perl scripts rather than javascript!