Thread

I had a EE1.6.3 installation set up in which I created a template set to “Javascript” type with the whole JQuery app pasted into it.

This worked find until just now when I upgraded to EE 1.6.4. I immediately noticed that the JQuery had stopped working. I then set up a concurrent installation of 1.6.3 and put viewed the full source of JQuery in both. They are not the same.

As an example, this portion of code in JQuery in EE1.6.3…

i<length&&callback;.call(value,i,value)!==false;value=object[++i]){}}return object;}

....has turned into…

i<length&&callback;.call(value,i,value)!==false;value=object[++i])return object;}

... in EE1.6.4

Is there some way I can stop EE from doing this to JS in “JavaScript” templates?

Joe

Try some other file types, most notably “static”. Or put the .js code in an external file.

Changing it to static doesn’t make any difference.

I suppose putting it in an external file is an acceptable solution, but it’s just a shame I can no longer keep it inside the system along with everything else.

Is there any reason why this would have stopped working between 1.6.3 and 1.6.4? Could it be a bug, or is it more likely to have been done as a security fix for something else?

If it’s a big chunk of js, I prefer to link externally for the cache benefit.  That said- if you go to ‘Admin- System prefs- Output and Debug’ do you have php errors set to show for superadmins?  If not- flip it to that and see if it makes any difference.

If it’s a big chunk of js, I prefer to link externally for the cache benefit.  That said- if you go to ‘Admin- System prefs- Output and Debug’ do you have php errors set to show for superadmins?  If not- flip it to that and see if it makes any difference.

Robin, BTW, I have a similar problem in EE. The Javascript in question is rather small, but won’t function properly from an EE template, though it works fine from a static file.

I went to Admin > System Prefs > Output and Debug, and set PHP Errors to show for Superadmins. That makes the Javascript work just fine. Switching it back to NO PHP/SQL error message generated causes it not to work.

Any idea what causes that? I don’t have a major issue turning On PHP Errors for Superadmins, but it seems it should work either way.

When error reporting is set to hide all errors, then EE takes the extra step of removing anything resembling an unparsed EE variable, so that if there were any unreported errors, it will not lead to revealing EE code to your visitors.

Hey Derek…

The odd thing is that the code works just fine when Output is set to 1 (for SA eyes only), but not to 0. But there are no errors showing up anywhere.

That’s not the odd thing, that’s the intended thing.  Anything resembling unparsed EE variables when debug is set to 0 (hide errors from everyone), will be removed from the output.

So, does javascript work as intended when stored in a template? It seems to only work when the debug setting is set to 1, right?

What am I missing here?

If your JavaScript has inline curly brackets, and no characters to trigger EE to understand that it’s script, e.g.:

{foo}

then since you have told EE to hide all errors, it removes any EE-looking variables and tags from output that could result from errors occurring but not being reported to anyone.  EE does not do this when your error reporting is set to 1 (recommended) or 2 (show to everyone, useful when developing your site or add-ons), because someone will be given opportunity to see errors and correct them.

So no, JavaScript that has syntax resembling EE tags will not work if you have your debug set to 0.  Specifically in the code example in the original post, it is this:

{}}

It’s that pattern that’s being removed.  EE will not remove it if there are linebreaks between the curly brackets, or if there is a semi-colon within it, which is an indicator that it’s a scripting language syntax and not an EE tag.  The JavaScript could be modified so as to not “look” like it has unparsed variables, but really, setting debug to 1 is the best solution, as you need have at least one person with the ability to catch errors going on should they occur.

then since you have told EE to hide all errors, it removes any EE-looking variables and tags from output that could result from errors occurring but not being reported to anyone.  EE does not do this when your error reporting is set to 1 (recommended) or 2 (show to everyone, useful when developing your site or add-ons), because someone will be given opportunity to see errors and correct them.

Whew. Sounds like a lot of effort just to figure out that something isn’t really Javascript when it’s supposed to be.

The JavaScript could be modified so as to not “look” like it has unparsed variables, but really, setting debug to 1 is the best solution, as you need have at least one person with the ability to catch errors going on should they occur.

Which, finally, explains why the default setting is “1” and why my default setup to set it back to “0” paralleled logic but defied reality.

😊

Thanks, Derek. I feel safer about moving it from 0 to 1, but it does seem that if the template is set to Javascript that EE should not ignore the request.

Thanks, Derek. I feel safer about moving it from 0 to 1, but it does seem that if the template is set to Javascript that EE should not ignore the request.

I understand your intent, but ExpressionEngine tags are parsed in JavaScript templates, so that wouldn’t be proper.  In looking at our docs, I do see that this behavior is not explained (including why the default and recommended setting is 1), so we’ll get that changed.