7

With template debugging enabled, clicking the "show" link to display the database queries isn't working.

I suspect this is related to the fact that on all pages of this site there are 7 chunks of content loaded via XHR that pass through the template parser. Because of that, the same ID ci_profiler_queries_db_1 is used 7 times. Since the code used to show/hide the queries relies on getElementByID, it's unable to determine which of the identical IDs is the intended one.

Is there a solution short of waiting on a core rewrite to use classes and more advanced js?

Improve this question
8
  • Does this mean you're defining global variables in your config file(s) but they aren't being converted by the template parser (something like {my_custom_global} is just spitting out {my_custom_global}? The question title seems a bit different from what you've described above.
    – Erik Reagan
    Commented Dec 4, 2012 at 15:38
  • Crap, I had previously started a SE posting and this came up when I went to post it. The title is TOTALLY wrong here. I'll update.
    – Ian Pitts
    Commented Dec 4, 2012 at 15:42
  • I was thinking that was the case. Thanks for updating :)
    – Erik Reagan
    Commented Dec 4, 2012 at 15:56
  • Question: what are the 7 other chunks of content being loaded? EE doesn't include the output profiler on some ajax requests so there's probably something we can tweak about your request of those URLs. Can you share some of the JS pulling those requests in?
    – Erik Reagan
    Commented Dec 4, 2012 at 16:02
  • The seven chunks of content are six mega menus in the primary navigation plus one with a bunch of links in the fat-footer. Here's a link to the js I'm using
    – Ian Pitts
    Commented Dec 4, 2012 at 16:07

3 Answers 3

Reset to default
5

Ian,

You and Anna/MediaGirl hit on the issue. Currently EE's output class only disables the template debugger and output profiler on responses sent through its own send_ajax_response() method (which makes certain assumptions about the response itself.) Hopefully EllisLab will build in some additional ajax response options to the Output class in the future.

Until that time, I put together a simple plugin that allows you to surpress the template debugger and output profiler as needed. I'm not putting it anywhere because it's probably somewhat of an edge case. Here's the info:

  1. Create a directory called disable_profiler in your third_party directory
  2. Create a file called pi.disable_profiler.php in this new directory
  3. Here's the code for that file: https://gist.github.com/4206180
  4. Add this tag to your templates loaded over ajax: {exp:disable_profiler}

You can tweak the code as needed, if you'd rather there be an ajax request logic. I ran this locally with a $.get() and $.load() jQuery snippet and it seems to work fine. The main/master template keeps the output profiler but the loaded templates do not and thus do not break the master one.

[Edit]
Per a tweet it looks like there's an add-on that has this behavior among other features. You just install it and it "fixes" this issue for all template requests (per the author's tweet).

Add-on info: http://devot-ee.com/add-ons/ee-debug-toolbar
Tweet reference: https://twitter.com/mithra62/status/276025536717914113

Improve this answer
3
  • Oh, wow. That's great Erik! Is it possible to create an extension that would modify the code EE uses when building that debugging code? Seems this could be fixed fairly easily with better JS and a different technique on the show/hide front.
    – Ian Pitts
    Commented Dec 4, 2012 at 17:31
  • No, an extension you've described isn't possible but there are probably other possibilities with hooks that could disable these output strings. Given some time I'm sure we could come up with something. This is the simplest solution I could provide in the limited amount of time I tend to spend on SE questions :p (no offense)
    – Erik Reagan
    Commented Dec 4, 2012 at 17:45
  • No offense taken at all. I appreciate the plugin.
    – Ian Pitts
    Commented Dec 4, 2012 at 21:31
5

I recently had the same issue where clicking the "show" link didn't show DB query results when template debugging was enabled.

In my case, it was my CSS reset code that was hiding the output. If I remember correctly, "legend" was set to display:none.

You can check your theory about the matching IDs by setting up a blank template and checking to see if the query output appears on that page.

Improve this answer
3
  • Confirmed. When I hit one of my XHR-requested templates directly, the output profiler allows the database queries to be shown.
    – Ian Pitts
    Commented Dec 4, 2012 at 16:05
  • Are you using a header/footer embed in your templates? Can you try a template with just that code so your CSS loads. Still see queries?
    – Anna_MediaGirl ♦
    Commented Dec 4, 2012 at 16:14
  • I am. I just modded my 404 template to exclude the call to the primary nav and footer and tested with ENV_DEBUG set to TRUE. Confirmed that I can show/hide.
    – Ian Pitts
    Commented Dec 4, 2012 at 16:29
3

After doing some testing suggested by MediaGirl, I was able to answer with confidence that the root cause in my situation was the multiple calls to display template debugging (via the XHR-loaded content).

Since the code uses IDs to determine what container to show or hide and all 7 of those containers have the same ID, it creates a condition where none of them can be displayed.

I've mentioned this to EllisLab so hopefully they'll address it in a future update.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.