Thread

I’ve been unable to find a solution from a quick search of the forums and devot-ee, but I want to keep Template Debugging enabled at all times on my dev server, but the debugging output doesn’t get returned into a wrapper container which I can style and separate from the template to my own specifications.  Javascript breakages are the most common.

Is there a way to control the Template Debugging output, or is it just an on/off thing?

Hi dehuszar,

I think you’ll find that the Output Profiler is wrapped in a div with the id of “codeigniter_profiler” and the Template Debugger is wrapped in a div with the id of “expressionengine_template_debug”.

At least my inspector shows that for ExpressionEngine 2.5.3, what version of ExpressionEngine are you using?

Cheers,

I’m using 2.5.2.  Here’s the output for PHP Errors:

<div>

<h4>A PHP Error was encountered</h4>

<p>Severity: Notice<br />
Message:  Undefined offset: 0<br />
Filename: stash/mod.stash.php<br />
Line Number: 1196</p>

<p></div>

and here is the opening tag for the bulk of the debugging content:

<div>

I can run an update to 2.5.3 if better containers were introduced there.

Hi, dehuszar -

That PHP error is not a normal thing to show up in the template debugger, and I suspect it is throwing off the layout.  That error indicates a problem with Stash: a third-party add-on.  I’d recommend ensuring that Stash is on the latest version and if it is still throwing an error, to follow up with the add-on author.

Does that help?

Hi Lisa,

I should have been clear that both output scenarios exhibit he same undesirable behavior.

I’ve already opened a ticket with Mark Croxton on this, the real issue is that the way all these messages load, I have no control over the display.  Whether it’s a PHP error, profiling or debugging output, if the message breaks my template it’s a little more difficult to both see what’s wrong, AND see if my template still works in spite of the error.

In this case, it’s a non-crucial error, the PHP error has no effect on what I’m trying to do other than the fact that I can’t both debug and effectively modify my templates at the same time.  It also presents a problem when other users with Super-Admin access try to demo a staging site.  Issues that don’t really break the site disrupt the display, with the only recourse being to turn off debugging, which on a staging site, is not super ideal.

If I could drop a tag in my template as to where the output should sit, or if I had an id or class selector to grab, I could create all manner of conditionals so that the output only displays for my logged_in_member_id, or gets tucked away and can be accessed in a modal when I want to see it.

The fact that I often dynamically load objects into the DOM, make it trickier to use elem + elem style selectors to target it that way.

Dan seemed to indicate that 2.5.3 fixes this.  Is that true?  I can easily run a backup and upgrade.

Thanks in advance.

Hey dehuszar,

I think Dan was indicating that he was testing in the latest version.

2.5.3 has over 100 bug fixes and so if there is a bug involved, then it helps us to better find it if you are on the latest version.

Sounds like you are working with Mark, which is awesome. If you can, upgrading to 2.5.3 would be good.

Cheers,

I have updated to the latest EE, and am still getting PHP error output (this time with Gmaps) which breaks my layouts.

Here is the html it’s outputting:

<div>

<h4>A PHP Error was encountered</h4>

<p>Severity: Warning<br />
Message:  Parameter 3 to Gmap_ext::channel_entries_tagdata() expected to be a reference, value given<br />
Filename: libraries/Extensions.php<br />
Line Number: 241</p>

<p></div>

...except that there are like 20 of those.

Hello dehuszar,

It looks like you Gmap Add-on might be out of date.

Can you update all of your add-on?

Thank you,

Hi Shane,

As above with the PHP error Stash was throwing, my concern is not that there ARE PHP errors.  The problem is that they are being dumped out into divs with no ids or classes assigned to them, so they break my layout even if the PHP error isn’t indicating anything critical. 

Incidentally, the addon IS up to date, though the developer tossed me a beta which I’ll try out tomorrow.  This is software.  There will be bugs.  It would be nice, though, if I had some control over the output when things do go wrong.

Is there some way to control the output without hacking core files?  I’m happy to get my hands dirty, but I’m not sure where to begin.

Hi dehuszar,

I see what your saying. No, there isn’t a way that I know of to take control of that.

Is there anything else I can assist you with?

Cheers,

That’s okay.  I’ll create a feature request.  Thanks for your help.

Hey there dehuszar,

Sounds good!

If you need anything else, please just let me know by opening a new thread.

Cheers,