I just noticed that the debug setting in the backend also affects templates which contain JavaScript. We have this code in one of our templates:

<div class="videoplayer_container">[removed]var kyteplayer = new Kyte.Player("channels/313418/1114721", {width:680, height:544, p:"1763", wmode:"transparent", quality:"high"});[removed]</div>

If I set the debug setting in the backend to “1: PHP/SQL error messages shown only to Super Admins” EE will clear the {witdh:680 etc..} object.

I know how to workaround this so not really looking for technical support. Wondering whether or not it should be this way.

Hi Bjørn,

Thanks for offering your findings to the Community. I’m going to migrate this into Development and Programming since those folks are most likely to need this advice. That will also keep the discussion going 😊 I’ll post a link to this thread in our Dev Forums to bring it to the Dev Team’s attention.

Cheers!

Dan, as Bjørn in his polite posting likely is quite aware, and I certainly am, this is now an ongoing fault in EE for eight months. It has caused many, many quite capable developers considerable loss of hours and frustration.

Here is an early Feature Request detailing problem and then-easy fix.

Here is a late Bug Report out of quite a few, which hits other related problems, but finally comes to conclusion that the real solution is to make a very small parser which actually avoids messing with JavaScript by avoiding what’s in HTML |script| tags.

I gave up entirely on this when encountering the bug report response’s last resistance to even looking at this. The reasoning is likely quite incorrect: I think no-one has looked at the setup or runtime cost of running the current Regex that happens behind the scenes in PHP, compared to a real parser; and in any case, running that or a real script tag parser is surely immaterial compared to all that goes on in EE.

Further, it’s surely better to correct EE’s behaviour while allowing a hidden config to return ancient behaviour for any remaining corrupt legacy site that’s been depending on not having their errors appear. Even that thought caused endless discussion, endless resistance, and then a fumble.

I am not trying to criticize, actually; but will honestly have to say that this sort of thing has turned my attention away from EE. Now that you have some fresh talent, maybe a clean look at the situation can be done.

It could all have been fixed with a day’s time by a programmer.

It would have been on any real-world attentive, experienced team in the enterprise domain where EE wants to head.

The original bug report on the subject was by a very capable person well known to Ellis, _rsan, and he was told it was the famous ‘Not a Bug’.

I don’t think there’s anything more I can do to help this, having tried. I hope this will be the time for the team to learn what they need to, for the future.

Regards, Clive

p.s. if anyone would like to see scope of the unanswered problem, just search JSON and see what you find.

Clive, thanks for chipping in. You’re right - I’ve been aware of the problem with EE’s Template Parser messing with JS code for quite a while - but this if_debug_is_0_strip_unparsed_tags “feature” was new to me. Since it’s now added in the EE.php controller, it will also affect addons returning JavaScript .. so it’s gotten worse.

Not sure if I understand the reasoning behind this feature. Sure, you don’t want unparsed tags on a live website, but all in all, I’d say stripping JavaScript is a bigger problem then unparsed tags displaying on erroneous websites.

I think EllisLab should strongly consider a fix - or, if not possible, update the documentation with best practices when it comes to JavaScript in templates (that is, warnings that it should be avoided, maybe even removing the .js template type).

Bjorn,

Have you tried using the protect_javascript hidden config item? As per our docs, it “prevents the advanced conditionals parser from processing anything in tags. By default, it’s set to ‘y’.” So set that to ‘n’ and see if that helps out any.

$config['protect_javascript'] = 'n';

Wes

Thanks Wes, but that setting won’t make a difference (the stripping is done in the EE controller, not in the Template library).

I was more interested in learning if this is seen as a non-issue from EllisLab’s side - or if it is being worked on .. do you know?

To be honest, we see it as a non-issue because it works just fine when debug is set to 1. We encourage setting debug to 1 so much so that we’ve removed 0 as an option from the drop down. If you already have debug set to 0, then it will show up as an option in the Control Panel, but otherwise it won’t.

In our documentation, you can see that the 0 option is no longer listed as well and that there’s a note explaining that you ought to use a debug setting of 1 if your Javascript resembles EE code.

So, the best practice is to set debug to 1 and clear up any errors you might be seeing, they show up for a reason.

That being said, we’ve added a hidden configuration variable (explained in Clive’s bug report) that will change the behavior of removing unparsed variables within your code. It will only work in conjunction with debug being set to 0 and it hasn’t been released yet, it’ll most likely be released with 2.3. That should help you out a bit, but at this point, I can’t imagine us doing much more in regards to this since none of the team likes the use of debug 0.

Wes

Actually, JavaScript in EE templates does not work fine, independent of the debug setting.

But let’s focus on the debug setting first .. There’s something strange going on here.

Here’s an existing EE install that I have:

Notice, that option 1: has value = “0”. So, you can only set it to either 0 or 2.

Here’s a fresh 2.2.2 install:

Here the option 1: has value = “1”. So, you can choose between 1 or 2.

That means that the code in EE.php that I mentioned above will only run on old installs. These installs can not set debug to 1.

Is this a bug or intentional?

But let’s focus on the debug setting first .. There’s something strange going on here. Here’s an existing EE install that I have: Notice, that option 1: has value = “0”. So, you can only set it to either 0 or 2. Here’s a fresh 2.2.2 install: Here the option 1: has value = “1”. So, you can choose between 1 or 2. That means that the code in EE.php that I mentioned above will only run on old installs. These installs can not set debug to 1. Is this a bug or intentional?

That was a bug that was hot fixed and announced. It shouldn’t be a problem from 2.2.2 on and there’s a patch on the forum post so you don’t have to do a full upgrade.

As for the JavaScript not working, could you give me an example where it doesn’t work? At that point I can see if it’s a bug or not. Also, let me know what debug setting you’re using and whether or not protect_javascript is on or not.

Ok, yeah I thought that was strange.

As for the JavaScript not working, could you give me an example where it doesn’t work? At that point I can see if it’s a bug or not. Also, let me know what debug setting you’re using and whether or not protect_javascript is on or not.

Sure, here’s a recent example: http://getsatisfaction.com/addonbakery/topics/frontpage_slider_content_is_missing_in_delegate

The code in question: http://themes.addonbakery.com/delegate/index.php/js/loopedSlider

(that js template works fine for me btw).

AFAIK, the ‘protect_javascript’ flag is irrelevant as it will only be used for content wrapped in script tags. External js files do not have these.

I have several other examples of inline javascript being stripped. I can go through my git commits and see these fixes once every now and then when there’s a new release of EE and something changed in the template parser.

Bjørn, am suspecting the silence here may be because they haven’t grasped that you had to tell your customer for your EE Add-in Theme that she couldn’t have JavaScript successfully in an EE template, and thus had to move it.

I read the replies above, and think:

• now the Ellis position seems to be that debug 0 is deprecated. If that is what they’re meaning to say, then surely it’s needed also for them to prevent any response whatsoever to debug 0, isn’t it?

Otherwise, all those upgrading to 2.2+ who have been using debug 0 are set to run into the JavaScript eating problem. Still. Would think this would include a lot of pro devs. As it did today, reported below.

• As well, how much hair may be pulled if you have originally used debug 0, set it differently in the CP, and then can’t set it back again? Shouldn’t any debug 0 in config be auto-corrected to debug 1 on upgrade?

• protect_javascript. If there is to be one, seems it should protect javascript anywhere, not just in ‘advanced conditionals’. If the debug 0 problem is to be eliminated, the question is raised if there is any situation where protect_javascript should not default true?

I keep not wanting to involve any more in this, just feeling it needs a comprehensive viewpoint and very solid cleanup. However, tonight’s glimpse at #eecms Twitter has the following from jannisg:

“Hmm… why is #eecms stripping my inline javascript?! Doesn’t make sense and I don’t know how to make it show up… any ideas?”

Yet again. I really cannot fathom how it has been impossible to listen on this, but hope this present discussion will finally turn the key.

Wes, I know you tried to help on this, on the last bug report. Let’s hope now there are enough facts on the table that you can do that.

Regards to each, Clive

Sure, here’s a recent example: http://getsatisfaction.com/addonbakery/topics/frontpage_slider_content_is_missing_in_delegate The code in question: http://themes.addonbakery.com/delegate/index.php/js/loopedSlider (that js template works fine for me btw).

So I tried out the code they said was having a problem:

<script type='text/javascript' src='{path=js/jquery}'></script>
<script type='text/javascript' src='{path=js/general}'></script>
<script type='text/javascript' src='{path=js/jquery.easing.min}'></script>
<script type='text/javascript' src='{path=js/loopedSlider}'></script>

I used all three debug settings (0, 1, and 2) and I didn’t have a problem (and it looks like it worked for you as well). I see it was a problem for them, but without seeing their entire setup and their list of add-ons, I can’t really debug the problem.

Could you layout the problem like this: 1. This is what I did. 2. This is what I expected. 3. This is what I got.

That way I can make sure I’m repeating the exact issue and can debug the problem.

Sure thing.

1. This is what I did

Downloaded http://code.jquery.com/jquery-1.6.2.min.js and put in in an EE template in a template group called “js”. Saved as a file.

Here’s the index.html in the js template group: http://pastebin.com/JuELy4Gz

You’ll see there is an EE comment there to switch between loading jQuery from code.jquery.com or from the js template group.

I then loaded http://my.dev/index.php/js/ in Firefox.

2. This is what I expected

I expected a popup letting me know that jQuery works.

3. This is what I got

No popup when loading jQuery that has been run through the EE template parser. A popup if I load jQuery that has not been through the EE template parser.

Here are the javascript errors I get:

Tested on EE v2.2.2 - Build: date 20110801 - default settings.

FYI here’s a diff between jQuery 1.6.2 - untouched and run through the EE template parser. The yellow stripes to the left indicate lines that have been changed by ExpressionEngine:

Bjorn,

Thanks for those exact details, I’ve replicated the problem and I’ll look into it today. Out of curiosity, could you try using the full version (not minified) of jQuery to see if that works for you? I ran into this problem with someone else yesterday and they said the full version worked for them. (Edit: Nevermind, the diff you posted is using the full version.)

My thoughts at this point is it has to do with the length of the lines, but I have no more to go on than that.

Wes