Thread

I have a template on my site with the VideoJS-Player (http://videojs.com/ ) embeded. I used the player’s embed-builder to create the general embed-code and switched some of the parameters to EE-variables.

Everything worked great in EE 2.1.3.

After upgrading to 2.2.0 the CMS seems to be confused by the curly brackets the flash-player uses for it’s configuration and the parallel use of EE-variables.
The output is something like

Hi DrHackenbusch,

Make sure your debug preference is set to ‘1’ because…

for those utilizing Javascript that may resemble EE code, including curly brackets, this setting must be 1 in order for the Javascript to function, or ExpressionEngine will hide Javascript output believing it to be an error.

Let me know if that makes a difference for you.

It already is (and was too in 2.1.3 before) “1: PHP/SQL error messages shown only to Super Admins.”
With 2.1.3 no problems. After upgrade to 2.2.0 the mentioned behavior.

Just switched it temorarily to “2: PHP/SQL error messages shown to anyone - NOT SECURE” and the flash-player did work again.

But keeping it on 2 isn’t an option for me. Any other ideas?

I have almost exact same issue!

Can’t keep it on 2 - any update on this?

I have to throw in… my debug preference was on “1” as well and the brackets in Javascript do not work. I detail the problem here:

http://ellislab.com/forums/viewthread/192982/

When I change the debug preference to “2”, they do work. But obviously, running unsecure is not preferable though.

todd, and the rest of you fellows:

Since I’ve written up this problem pretty heavily for the past six months, I spent another hour on it here, looking mainly at 2.2.0 and today’s 2.2.1 source code.

I think what’s getting confused here, and it seems to be in your language, is the distinction between Debug Preference in the CP; and the $config[‘debug’] setting in config.php.

These are two different settings completely, and only one affects the curly brackets, I am pretty sure.

- Debug Preference in the CP decides who may see debug messages. That will be Anyone (setting of 2), or Site Administrators Only (setting of 1)—again in the CP. The 2 setting is as it say, NOT SECURE, not for magical reasons but because someone could get a clue from things debug may output, like paths.

- $config[debug] = “N”; in system/expressionengine/config/config.php, on the other hand, decides what _kind_ of debug will show, when the setting above says it _may_ show. The value there can be “0”, “1”, or “2”.

“0”—show no debug of any kind. The purpose of this level is clearly to make a site look clean even if it isn’t. Not good, but a practical need once in a while. Particularly this might be appropriate if you have customers who have Admin Group logins, and you have a problem which lets the site work but is not quite fixed, like for example some cases where an add-on that isn’t updated yet.

The thing that’s broken so many person’s JavaScript/JSON code is that when $config[‘debug’] = 0; is set, there’s _also_ a filter set in EE that removes all code within curly brackets that hasn’t been recognized as a valid EE variable. And that’s what you’re seeing here.

“1”—this means show normal debug output, and _don’t_ crush unrecognized curly bracket content. Thus it’s actually a good setting, as long as you have a clean site free of bad EE variable indicators, or if your customer doesn’t have Admin logins, and you use the CP preference so that they don’t see any errors.

“2”—like “1”, but it also turns of database handling debugging. Probably needful only when developing database drivers, or in unusual circumstances.

All of this from the source, rather than the documentation, but the documentation says the same.

===

Now, I hope the above explanation makes things clearer, and of course I am hoping the understanding will help avoid any confusion on this curly bracket problem. If you set $config[debug] = 1; in config.php, and _still_ have any curly bracket issues, I think Ellis needs to hear that right away.

As a real solution, what I have asked them to do is to allow configuring the control that is already actually in the code, so that unrecognized curly bracket variables will never be removed when that control is set so. And, I have asked them to default that control’s setting so that curly brackets are not removed.

This simple arrangement should cleanly allow JavaScript blocks and JSON to operate fine always; and let you still use config[‘debug’] of zero if you really need to hide site quirks. And the old way (as now) would always be available for anyone who likes it.

The latest is that Pascal has indicated they will talk it over. That’s in the current bug report here (there have been lengthy others).

And I will add to it reference to this thread, so they can see if there’s anything unusual, or that the issues merge to be the same, as I believe, unless I am mistaken. This current bug starts out about elapsed_time being scrubbed in 2.2.0, but that’s to do with the same issue you have, as you’ll see, and this is what has got their attention on it.

Regards,
Clive

That’s weird AND annoying. I only experienced this issue with javascript code being evaluated as ee code with the 2.2.1 update. Setting the debug = “1” in the config fixed the issue.

I should note I am using mx_jumper to place the javascript in a parent template and that’s why my JS needs to be included inbetween EE tags.

NAlbequerque, annoying, but very good that you explained so clearly how your case went. Thanks.

It may be that recent EE versions have changed something about where curly brackets are treated like variables (though this doesn’t show in their later handling) which is why people are suddenly noticing the problem now.

Nonetheless, I think the simple recommended fix will fix it all, for the good.

Regards,
Clive

Here is the full explanation of what is going on, and why it is confusing everyone.

- as Todd in another thread led me to discover, Admin Debug Preferences, and config.php setting for $config[‘debug’], actually at this point seem to be partially acting as much the same thing. I’m not certain that’s an EE design intent, but the effect is there.

- However, Debug Preferences does not properly affect $config[‘debug’]. Here are three example cases:

  a) $config[‘debug’] is “0”. Debug Preferences, however, will show 1. In this situation, Javascript is broken as everyone sees.

  b) You set Admin Debug Preferences to 2. However, $config[‘debug’] will now actually be set to “1”, not “2”. Javascript works again, but debug does not include database and GET debug as the code would say it should for 2. This result is the same as if you’d manually set $config[‘debug’] to “1”, which it now is.

  c) You set $config[‘debug’] to “2”. Now Debug Preferences also shows 2 if you refresh that page. By the code, database debugging will be included.

- Notice that in any of these false settings, it’s not clear whether users will see debug along with administrators, or not, as they shouldn’t unless intended. That’s a rather critical function for security, and while it may be present, I didn’t notice any code that actually implements this according to the present oddly shared debug setting. This along with the rest needs careful looking into, by strong EE developers.

In short, things are a bit messed up at present. I am filing a bug report on this and will note it here when done, as well as refer it back to this thread.

I believe the safe and sure recommendation for the present is to leave Admin Debug Preferences entirely alone, and set the following in system/expressionengine/config/config.php:

$config['debug'] = "1";

That should get you working in the safest mode, and with JavaScript not being affected, in 2.1.3 onward to 2.2.1, where I’ve tested the last of this.

Regards,
Clive

Edit:  the bug report is filed, hopefully without incident due to the hour, and is found here.

It does feel good to have apparently surrounded all the directions of hints that have been coming on these forum postings. As always, everyone has a reason for what they say.

Hi all,

We’ve posted a fix for sites being affected by this, and of course the fix will be rolled into the next release. If anyone is still having issues after replacing those three files, please let me know. Thanks!

Everyone– I’m closing this thread out, but please open up a related thread if you continue to have issues once you’ve implemented the fix linked above by Brandon.