Can you let us know how to reproduce this error? The JS should be loading from an ACTion request, which doesn’t involve the template parser, so no debugging log would exist on those requests. The related profiler is disabled by the loader.

Here is what I tried:

• added a basic channel form in a new template, allowing channel form to output its default assets
• enabled Template Debugging in my Output and Debugging Preferences
• accessed the form on the front end, while logged in as a Super Admin

What am I missing?

Login as superadmin in CP, frontend load /index.php/?act=7 (or whatever the comboload action is in your setup)

Probably due to addons that DO load TMPL for emails or something, because controllers/ee.php L:107 does get triggered.

What add-ons do you have installed? If that is what is happening, I will not be able to replicate without the add-on causing this issue. The correct solution in that case is for those add-ons to ensure they are not running code when they ought not, and I’d like the opportunity to help those developers make sure their add-ons are playing nicely with others.

Your suggested patch would indeed cover the symptom, but it sounds like the root problem is an add-on running code unnecessarily, which can waste resources, and cause other unintended/unknown side effects by running their code in the wrong contexts.

If this is a custom add-on, I’m happy to help there too. For example, if an add-on is using an extension hook that runs on every request, but only actually has an impact on front end page requests, the first bit of code in the receiver method should be:

if (REQ != 'PAGE')
{
    return ee()->extensions->last_call;
}

i guess MX_notify is the culprit. in its __construct() it does a … if not isset TMPL, load library template. grmbl. Thanks for the heads-up. i’ll modify it myself, since it is not a supported add-on anymore

Sorry to say, it’s still EE channel-form itself. I added a debug_backtrace() to template constructor, to see who’s calling.

mod_channel is creating pagination in its constructor, ee_pagination is loading TMPL in its constructor.

0 Func: __construct() File: /codeigniter/system/core/Loader.php @line: 995 1 Func: _ci_init_class() File: /codeigniter/system/core/Loader.php @line: 896 2 Func: _ci_load_class() File: /codeigniter/system/core/Loader.php @line: 138 3 Func: library() File: /expressionengine/core/EE_Loader.php @line: 98 4 Func: library() File: /expressionengine/libraries/EE_Pagination.php @line: 70 5 Func: __construct() File: /expressionengine/libraries/EE_Pagination.php @line: 30 6 Func: create() File: /expressionengine/modules/channel/mod.channel.php @line: 87 7 Func: __construct() File: /expressionengine/libraries/Actions.php @line: 183 8 Func: __construct() File: /expressionengine/libraries/Core.php @line: 581 9 Func: generate_action() File: /expressionengine/controllers/ee.php @line: 64 10 Func: index() 11 Func: call_user_func_array() File: /codeigniter/system/core/CodeIgniter.php @line: 329 12 Func: require_once() File: /index.php @line: 235

Ah you are indeed correct. I see why I was not able to replicate—the JS loader sets a content-length header equal to the size of its output, so it didn’t matter that the app was later trying to add to the output. I had to comment out where those headers are set to get it to output the debugger and foul up the JS.

Fix is in the Solution tab above. Out of curiosity, what browser and version are you using? I’m puzzled as to why it wasn’t respecting the content-length headers.

i use google chrome and shift-cmd-reload (or shift click reload) to force a cache busting reload.

Odd, Chrome was respecting my content-length headers; when I test I disable caching with the web inspector. No worries, in any case, thanks for sticking with that one!

don’t rely on settings, shift (cmd-R) or shift click reload