BUG: Sub folders not allowing commas in 10.0.3 and Javascript borked

[leehack]

Had a client upgrade from 10.0.2 to 10.0.3, go live and then ring in panic as his site was not right. He has a section where the images for that section are held in a sub folder structure like so:

130x130\Oils, Lotions and Gels\NQ-REPAIR10-130-1.jpg

This worked fine on 10.0.2, no problems, but somehow is not on 10.0.3, some playing around with the image locations seems to point to the folder name being the problem, i'm presuming the comma. I have moved the same image into another sub folder and it showed in the design. In its original location you just get the red cross missing image icon. Example - http://www.physiosupplies.com/acatal...ND_CREAMS.html

The underlying code for the image is not getting parsed correctly, it still shows as it is on the local PC, not within the acatalog as it should. The upgrade has also borked the live chat window, somehow interacting with the Javascript running that area, which means that has completely disappeared.

[JGLIGHTING]

Hi

You might want to talk to actinic as they have a special build that sort out image paths problems. Might not be the some problem as you got, but it sorted out my site. I do have a link for the download if you want it let me know.

Elliott

[leehack]

Thanks Elliott, client has changed the folder name as it seemed the quickest way to fix things. It seems to have worked and all is OK now. So BEWARE any of you with commas or maybe other characters, actinic will not work on those!

Actinic messing up Javascript code is still a problem though, what is planned to fix this actinic? We need to be able to use exterior scripting without actinic breaking it. I have code such as:

<script type="text/javascript">var seGFuS=document.createElement("script");seGFuS.type="text/javascript";var seGFuSs=(location.protocol.indexOf("https")==0?"https":"http")+"://image.providesupport.com/js/physiosupplies/safe-standard.js?ps_h=GFuS&ps_t="+new Date().getTime();setTimeout("seGFuS.src=seGFuSs;document.getElementById('sdGFuS').appendChild(seGFuS)",1)</script>

on a site but actinic is screwing it up and interfering. How do you plan on giving us a way to circumvent such problems, possibly a new tag that we wrap around code that we do not want you to touch? Grateful of any ideas.

[NormanRouxel]

Try replacing the fragment:

"://image.providesupport.com/js/physiosupplies/safe-standard.js?ps_h=GFuS&ps_t="

With

"://image.providesupport.com/js/physiosupplies/safe-standard" + "." + "js?ps_h=GFuS&ps_t="

It probable that Actinic is seeing http and later .js in a line and processing it as if it was a local filename.

[leehack]

Many thanks Norman, that's done the trick. I'd seen you do this kind of thing in the past, but i'd tried breaking up the start of the code, not realising it is the .js that it struggles with. Thanks for the quick reply, really appreciated.

Actinic, this needs fixing or we need some new tags please.

[Duncan Rounding]

I think a pair of "leave me alone" tags is a great idea and should be quite easy to impliment i would expect.

[NormanRouxel]

Why not kill two birds with one stone. If Actinic detected <*!! and *>, and then replaced it with <!-- and -->, leaving the generated comment tags in place and everything between them unprocessed, then we could use this to create conditional comments as well as mark JavaScript not to be munged.

[NormanRouxel]

While on this subject, would you believe that there's a new bug that I and two others have seen. New bug is the reverse of the problem noted here, in that Actinic is occasionally not detecting variables and expanding them.

E.g. If you have a .CSS file referenced in your overall layout. Like:

<link rel="stylesheet" href="mystyles.css" type="text/css" media="screen" />

And mystyles.css contains some Actinic variables, then sometimes the file is uploaded to the server without the variables being parsed. The <actinic:variable ... /> stuff appearing in the uploaded file.

Unfortunately I cannot find any way to reliably create this problem on demand so it's really hard to work out why it happens and create any workarounds.

[leehack]

I think that bug is a throwback to the old v9 problem of not given enough time to parse the file before it moves onto the next file, particularly bad with files/variables within. From memory they changed the order and the timings so that the external files were parsed correctly before uploading the files. This seemed to fix the problem 99% of the time, but there is always an odd one where actinic for some reason removes code from the server or does not parse correctly, often an external stylesheet, so a site gets completely borked.

Again it is under no specific condition, so very hard to replicate on demand. On asking Ben about this, i was informed it is not an issue as it was in V9, it is different, i don't recall hearing any further on the matter. Suffice to say, whether it is different or not, the result is the same, a borked site.

However they tackle these issues, one thing for sure is we need a rock solid way of uploading and adding external items without actinic screwing it up.

[Krithika]

Hello

Thank you for bringing this to our attention, Lee. I have reported both the issues and passed them on to our development team.

Regards