Thread

My site was functioning, I turned on template debugging & profiler, now my EE-template scripts seem to be breaking.

I posted the issue here: http://ellislab.com/forums/viewthread/196639

I am at a loss to explain what’s going on…

I tried rolling back the DB to a previous backup, and have spent a good 2 hours pouring over templates, trying to find a cause…

It seems to be a parsing error with the JS, but I have no idea why this has just started.

Is there any way I can pinpoint this issue? I’m not 100% sure it’s an EE thing, but I can’t think of anything that changed in my templates to cause it.

Please help if you can point me in the right direction… Thank you!

This is only happening in JS templates. Regular (static) JS files don’t have the issue…

Could something have changed in the way EE processes the template files when debugging was enabled? I’ve restored both DB and files from a backup from the night before and things are still broken.

This is really critical, as now all my site scripts are broken, and I have no idea what’s caused it…

Please help.

I did a backup and restored a working version of the site.

I am still suspicious that Template Debugging / Profiler was the cause of this issue.

Yes, I can confirm this.

Turning on “Display Output Profiler” breaks my JS. Turning off this setting does not correct the issue.

It seems to me something in config.php is being changed when Display Output Profiler is enabled that is not being changed back when it is disabled.

Restoring config.php from a backup after turning off Display Out Profiler fixes the issue.

Any ideas?

I started another thread in Community Help on this: http://ellislab.com/forums/viewthread/196639

@the3mus1can offers this thread as a related issue: http://ellislab.com/forums/viewthread/130168/#642488

I tried adding

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

to config.php. The issue still occurs when Output Profiler is enabled.

I have debug=1. My template type is set to “Javascript”.

Hi there Graham,

What version of ExpressionEngine are you using? Is there any reason you need to store these js files as templates? Depending on your ExpressionEngine version, you may have stumbled on a bug, but I need more information to replicate and verify.

Thanks,

Hi Dan,

EE v2.2.1 - Build: date 20110705

Correction: using static JS files actually didn’t fix the error, so the issue persists whether it’s template JS files or static JS files.

In this case, storing the JS as template files is just part of how we’re doing the site architecture (long answer: so the JS can be edited via Template Manager, enabling site devs to have CP-restricted write access to the core JS without needing FTP access).

I think it’s a bug. I was pulling my hair out last night to isolate the behaviour and correct it. I know now that something is getting modified in config.php by enabling Display Output Profiler that is breaking things. 

Perhaps a simple way to identify the change would be to compare config.php before and after enabling the setting.

Another hint: turning on the setting, then uploading a backup of config.php actually allows the Output Profiler to display without triggering the issue. Turning OFF Output Profiler will again trigger the issue, requiring config.php to be restored from a backup again.

So ya, it’s something with how this setting is being enabled/disabled that is causing the JS parsing error with certain code in curly braces (like JSON { } ).

Hey Graham,

Let’s see if we can get config.php behaving properly first. Can you verify the permissions on config.php on your server are set to 666?

Cheers,

It is 666.

Hey Graham,

Thanks for verifying that. There is a hidden config item that we can put into effect to solve the js parsing problem, but we need to be confident that the system is properly loading and honoring your config.php first. I’m going to ask that you make a change in config.php that we’ll be able to see in the Control Panel. Can you open /system/expressionengine/config/config.php and change the value of $config[‘site_label’] = ‘’; to something different and obvious, for example $config[‘site_label’] = ‘VERIFIED’;

Once we’re confident that the proper config.php is being loaded, then we can move forward with the troubleshooting.

Thanks,

Ok, put in $config[‘site_label’] = ‘VERIFIED’;

Don’t see the change in CP—I’m using MSM though, is it possible the site_label for the current site is being overwritten elsewhere?

When I set allow_extensions = ‘n’, this works… Does that sufficiently verify config.php is being loaded?

Ah! So you’re running MSM… that does make testing out variables a little more tricky because, yes, the site label could be overwritten in the admin.php or system/index.php of the secondary site if you’re accessing it through that site’s CP. Still, if uploading a backup of config.php after turning on/off the profiler restores EE’s ability to properly render your JS, I think the solution lies there. Is there any way you could just do a diff between those two versions of the config.php file (before and after turning the profiler on or off)?

Yes, running MSM.

I just tried turning Profiler on again to generate the “bad” config.php file to check, and it seems to be working now.

I’m not sure what I changed, but I’ve been messing with a lot of config & session/cookie settings.

This issue in particular seems to be corrected.

Well… I hate that we don’t know what happened, but I’m glad it’s corrected. I’ll mark this “Resolved” for now, but it the problem arises again, just open up a new related thread and let us know what’s different between the two config.php files (if that’s possible).

Thanks for your patience on this, Graham!