Module Tracy Debugger

[adrian]

3 minutes ago, bernhard said:

quick question because i needed it today and couldn't find it: is it possible to see the current url segments somewhere? i just found "urlsegments ON/OFF" indication but it would also be helpful so see wich urlsegments are currently active.

thanks

In this what you mean?

 

[bernhard]

thank you. i thought it was already there, don't know how i missed that

[adrian]

On 8/15/2016 at 2:16 AM, tpr said:

@adrian

I may found two bugs for the Mail panel:

• it doesn't intercept emails for the backend. I have to add the Mail panel for the Frontend to make it work. If you need I can give you access to a pw setup that sends emails from the admin.
• "Clear emails" button loads this page when clicked: "/page/edit/bookmarks/"

Ok, I think these should be fixed - the problem was not just limited to the Mail panel. I have made a significant change to handle ajax requests in the backend - before they weren't detected as coming from the backend - I am relying on $_SERVER['HTTP_REFERER'] which isn't awesome, so please let me know if anyone notices any problems.

The fix for the incorrect URL when clearing emails (and other things) now also uses $_SERVER['HTTP_REFERER'].

Thanks @tpr for the server access - very helpful!

[tpr]

Thanks! Will report if I find something strange.

There's one thing I noticed yesterday (before the Ajax changes). Using an ajax-loaded repeater, adding a bd() call the dump appears on the ajax bar for a split second, then disappears. I'm using bd() from an Inputfield::render hook. As I wrote this is not new, though haven't noticed earlier.

[adrian]

9 hours ago, tpr said:

Thanks! Will report if I find something strange.

There's one thing I noticed yesterday (before the Ajax changes). Using an ajax-loaded repeater, adding a bd() call the dump appears on the ajax bar for a split second, then disappears. I'm using bd() from an Inputfield::render hook. As I wrote this is not new, though haven't noticed earlier.

Any chance you could set this up on that test site you gave me access to? 

I think there might be some redirect going on in the repeater somewhere. The barDump content in the Tracy core only exists until the page is reloaded. If I can test your setup and confirm that would be helpful. I am also wondering if it might be useful for me to create a new panel that is a combination of expandable/collapsible nature of content that is sent via bd() and the persistence of content sent to the Tracy log files via l() - I think this "Persistent Dumps" panel could be very useful as I have come across similar situations myself where the data sent to bd() is lost due to a page reload, so I end up using l(), but this doesn't allow nice dumping of objects/arrays. This panel would have a "Clear Items" button so it's easy to reset when you have reviewed everything you've sent. Any thoughts on this idea? Or maybe this Tracy Issue would also deal with the problem: https://github.com/nette/tracy/issues/199 - it's not quite the same problem though, or maybe in your repeater case, it actually is the problem - more than one ajax call, rather than a redirect?

[szabesz]

5 minutes ago, adrian said:

This panel would have a "Clear Items" button so it's easy to reset when you have reviewed everything you've sent.

$like++

[tpr]

@adrian check your messages.

That panel would be handy, though this was the first time I encountered this issue, so I can live with it I guess

I also tried the same thing without a repeater and dumps haven't disappeared, so you may be right that it's related to repeaters.

[adrian]

2 hours ago, tpr said:

@adrian check your messages.

That panel would be handy, though this was the first time I encountered this issue, so I can live with it I guess

I also tried the same thing without a repeater and dumps haven't disappeared, so you may be right that it's related to repeaters.

Thanks for the test example - I added an "exit" after your bd() call and that keeps the dumps panel active, so without investigating too much, I am guessing that there is a second ajax action that is clearing the dumps panel. So I think this is related to this: https://github.com/nette/tracy/issues/199

The Tracy guys might come up with a rework to make this possible, but in the meantime, I think I'll proceed with the idea of a "Persistent Dumps" panel as it has other/different  benefits as well.

[tpr]

Great, thanks!

[adrian]

Ok, the new Dumps Recorder Panel is now available.

If you have this panel enabled, all dumps sent via bd() calls will automatically be stored and displayed in this panel until you click the "Clear Dumps" button. Keep in mind that dumps of PW objects can be very large, so it pays to keep this cleaned up very regularly. In case you didn't follow the discussion above, this panel is great for when there are more than one AJAX call which would replace the core dumps panel content with the last call meaning you may completely miss the dump you are interested in. It will also be handy if there are multiple redirects going one. It may also be useful when you want to compare the values of dumping the same variable/object from different pages. I am sure there are use use cases as well. I hope you'll find it a useful addition.

@tpr - I tested the situation you described with a repeater and the bd() from your AOS module and this new panel works great for recording these calls. I updated your test install so you can see it in action there.

Let me know if anyone has any problems/suggestions for this.

[adrian]

On another note - I am seeing more issues with PW's SessionHandlerDB module - it seems to affect the loading of the AJAX bar when using vanilla JS. Without it everything works great. I'll be putting together a troubleshooting section on the support blog post sometime soon will all the issues like this.

[adrian]

Good news - the Variables panel now works without the file compiler - which also means you can use it with PW 2.x as well!

[adrian]

The Console Panel now also has access to any template variables that you might have defined yourself. The screenshot shows dumping of two custom defined variables via the console (I have included the content of the variables panel so you can see where they are coming from). This should make testing code snippets in the context of the template of a specific page much easier.

The one caveat is that currently (hopefully I'll find a way around this) to access to these variables requires including the template file a second time. In most situations this probably won't be a problem, but if the page using the PW API to add/modify/delete any content or similar, then it will be processed twice. So, for the moment, this functionality requires checking the "Allow access to template variables" checkbox - otherwise you'll get an "Undefined variable" error.

Hope you all find this useful!

[bernhard]

hi adrian,

what do you think of making it auto-clear by default and have an option to keep them just when the user wants it. similar to the sticky option.

[szabesz]

38 minutes ago, bernhard said:

hi adrian,

what do you think of making it auto-clear by default and have an option to keep them just when the user wants it. similar to the sticky option.

+1

[tpr]

The Dump Recorder looks great, but there's one issue: after a number of items, the admin loads very slow. Not sure how to overcome this, maybe setting a max limit?

Apart from that, how about adding new items to the top?

Plus having the normal Dump and Dump Recorder at the same time seems superfluous. Sometimes I don't know in which panel I'm seeing, but of course it's maybe just me.

[adrian]

Hi @bernhard, @tpr and @szabesz - thanks for the feedback.

7 hours ago, bernhard said:

what do you think of making it auto-clear by default and have an option to keep them just when the user wants it. similar to the sticky option.

I am not sure I understand the point to auto-clear. Surely if you activate the Dumps Recorder panel then that means you want to keep them. Otherwise disable it and rely on the built-in dumps panel that comes from the Tracy core. You could even enabled the Dumps Recorder panel using the Once option. As I think about this, maybe what should happen is if the panel is not enabled, then it should clear its results then? Would that make sense so you don't need to clear before disabling? Maybe that's what you meant in the first place?

5 hours ago, tpr said:

The Dump Recorder looks great, but there's one issue: after a number of items, the admin loads very slow. Not sure how to overcome this, maybe setting a max limit?

Yeah, there are potentially a lot of DOM elements in a dump of a PW object - add several of those together and it can get very large. I guess I didn't want to assume when it was time to remove old items, hence the manual clear button. But if you guys feel strongly about a max number of items, or a max size in bytes for the output before older items get truncated, I can add that.

5 hours ago, tpr said:

Apart from that, how about adding new items to the top?

Sure - done locally - will commit later.

5 hours ago, tpr said:

Plus having the normal Dump and Dump Recorder at the same time seems superfluous. Sometimes I don't know in which panel I'm seeing, but of course it's maybe just me.

This would be easier if this request (https://forum.nette.org/en/26456-ability-to-disable-panels-in-debug-bar-and-the-bluescreen) had been considered. I could have disabled the core dumps panel if the Recorder version was enabled. Maybe I can still unregister the panel somehow - I'll take a look. The other possibility of course is to not send bd() calls to the Dumps Recorder, but instead have a separate recordedDump() / rd() method and we use that instead - maybe that is easier, or maybe it is more confusing? Any thoughts?

[adrian]

Two major changes this morning!

1. The "Variables" panel is now called "Template Resources" and contains: variables, constants, user defined functions, and included files.

 

2. The Console panel now also has access to any functions defined in any included files. In this example I am calling the renderNav() function from the _funct.php file.

[adrian]

Ok, some more updates.

@tpr and @bernhard - hopefully I have taken care of your suggestions with this latest version.

Now if the Dumps Recorder panel is enabled, the built-in dumps panel is not triggered which should make things simpler.

Once you disable the Dumps Recorder, it automatically clears recorded dumps. They are also cleared when you logout. This behavior has also been added to the Mail and Event Interceptor panels.

Other updates improve detection of template constants and functions in the Template Resources panel and adding editor links to the included files section.

Any thoughts on these improvements? Do they come close to what you were looking for regarding keeping the Dumps Recorder manageable?

[tpr]

I had limited occassions to try but regular Dumps were not showing up when the Dumps Recorder was active, so it seems to work fine here. 

Admin slowdowns due to many items in Dumps Recorder is still an issue but of course it's not Tracy's fault, but it's still better than seeing no dumps at all (when they disappear).

[adrian]

Thanks for the confirmation @tpr.

Minor update just committed adds the filename and line number of defined functions, and links to open to that spot in your code editor. Should be a nice addition when you don't remember where a function is defined.

[tpr]

Auto-clearing of the Dumps Recorder could be achieved on client-side on each page load:

    $(window).on('unload', function () {
        if ($('a[rel="tracy-debug-panel-DumpsRecorderPanel"]').length && window.Tracy && Tracy.Debug.panels['tracy-debug-panel-DumpsRecorderPanel']) {
            var BRPanel = Tracy.Debug.panels['tracy-debug-panel-DumpsRecorderPanel'];
            // init only if it's not initialized
            if (!$('#tracyDumpEntries').length) {
                BRPanel.init();
            }
            if (window.clearDumps) {
                clearDumps();
            }
        }
    });

Note that I haven't tested this thoroughly but I guess it's safe to use. Maybe there's also a more efficient/nicer way to do this.

Edit: if you use 'beforeunload' event instead 'unload' then you can also see the panel clearing.

Edit2: fixed the code above: init only if required

[bernhard]

hey adrian,

what do you think of a panel to switch off certain modules. like the panel selector but not for panels but modules. so you could switch off modules during development to make sure it is not related to that module...

no idea how hard that would be - just wanted to share the idea and hear your thoughts

[adrian]

7 hours ago, tpr said:

Auto-clearing of the Dumps Recorder could be achieved on client-side on each page load:

    $(window).on('unload', function () {
        if ($('a[rel="tracy-debug-panel-DumpsRecorderPanel"]').length && window.Tracy && Tracy.Debug.panels['tracy-debug-panel-DumpsRecorderPanel']) {
            var BRPanel = Tracy.Debug.panels['tracy-debug-panel-DumpsRecorderPanel'];
            // init only if it's not initialized
            if (!$('#tracyDumpEntries').length) {
                BRPanel.init();
            }
            if (window.clearDumps) {
                clearDumps();
            }
        }
    });

Note that I haven't tested this thoroughly but I guess it's safe to use. Maybe there's also a more efficient/nicer way to do this.

Edit: if you use 'beforeunload' event instead 'unload' then you can also see the panel clearing.

Edit2: fixed the code above: init only if required

Interesting idea for sure. The thing is that I am not sure that I would always want it to auto-clear. There are times when I want to compare the results of one dump with another (perhaps after a code change), or even on a different page. It could be a configurable option though - on the module settings page, or maybe a checkbox on the panel so you can easily uncheck when needed. What do you think?

 

5 hours ago, bernhard said:

hey adrian,

what do you think of a panel to switch off certain modules. like the panel selector but not for panels but modules. so you could switch off modules during development to make sure it is not related to that module...

no idea how hard that would be - just wanted to share the idea and hear your thoughts

I think the idea is great, just not sure how easy the implementation is. I can't find Ryan's notes about the module disable feature he added, but he only made it available when in advanced mode because he mentioned there can be some big side-effects in the case of some modules. I guess I could also limit to advanced mode and add the same caveat.

Here is the text from the source code where the disable module checkbox is added (https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessModule/ProcessModule.module#L1280):

"Be careful, checking this box can break the module or your site. Use for temporary testing only."

[szabesz]

7 minutes ago, adrian said:

...or maybe a checkbox on the panel so you can easily uncheck when needed. What do you think?

This one