Module Tracy Debugger

[adrian]

7 hours ago, Robin S said:

Hi @adrian,

Might be a silly question, but just wondering why the dump output doesn't appear in the same order that the dumps occur in. So if I do...

 

...how come the output order is reversed?

The idea was to reduce the need for scrolling if you had lots (or large) dumps, or especially if you checked "Preserve Dumps" when you are trying different things on subsequent page loads and want to compare the output.

Maybe a better approach is to put back in normal order and automatically scroll to the bottom on page load, or when a new item is added via an AJAX call. This would make it function like d() calls in the Console Panel.

What do you guys think about that option?

 

[adrian]

Ok, the order of items in the Dumps panel is now "normal", not reverse.

The latest version also:

1) hides the PW Info panel if you click on one of the navigation icon links and also hides the Dumps Recorder panel if it's empty.

2) makes $input->get, $input->post, and $input->whitelist available to the Console Panel, so if you do: d($input->get->variable) you'll get the value of that get variable for the currently loaded page. These $input vars are already available in the Debug Mode Panel, but now you can use them programmatically in any code you might be trying to test in the Console Panel which I think can be very handy at times. Note that $input->urlSegments, $input->pageNum, & $input->cookie also work, but they always have.

[Robin S]

Hi @adrian

I just discovered the feature where the Captain Hook panel links the hookable method name to the API Explorer (if it is installed I guess). This is very cool. But just wondering if you could have it open the API Explorer in a new tab, to avoid navigating away in the current tab?

[adrian]

6 hours ago, Robin S said:

I just discovered the feature where the Captain Hook panel links the hookable method name to the API Explorer (if it is installed I guess). This is very cool. But just wondering if you could have it open the API Explorer in a new tab, to avoid navigating away in the current tab?

Hi @Robin S - glad you like it  Yes, if the API Explorer is installed it will link to those and if not, it will link to the API docs on the PW website. On a related note, the links from the API Variables and Core Classes sections on the Debug Mode panel behave the same way.

As for opening in new tab - I am honestly not sure about this. I struggle with this a lot - I used to be all about new tab for external links and same tab for local links (so long as it wouldn't result in a broken form submission / loss of user input). However these days I mostly don't go with new tab for external links at all - I think the user should have the choice. Also, in this case the user of Tracy is going to be a developer and they know about middle-click, three-finger-click, or right-click new tab, so I am tempted to leave it up to them. I would like input from other Tracy users on this though, because it is a grey area and it could result in a loss of form data. Keep in mind that all links from Tracy (especially the PW Info panel) are same tab, so I think I have been consistent here.

Any strong thoughts from any of you out there?

[Robin S]

2 minutes ago, adrian said:

However these days I mostly don't go with new tab for external links at all - I think the user should have the choice.

You're absolutely right - I thought the links were opened with Javascript and that therefore I couldn't control the target tab, but I was getting them mixed up with the parent class link which just toggles the list of class methods open and closed. So all good, thanks.

[Macrura]

i vote for the clear cache admin to be in TD; I do find it necessary to sometimes look at and/or clear caches in wirecache ($cache)..

[adrian]

2 hours ago, Macrura said:

i vote for the clear cache admin to be in TD; I do find it necessary to sometimes look at and/or clear caches in wirecache ($cache)..

Hi @Macrura - do you have any thoughts on how this would actually look? I can envision the clear/delete options, but you mention "look at". Do you want to be able to actually preview the contents of wireCache items? Currently I use the Console panel for this:

d($cache->get("hello-world"));

but I can see the advantage of being able to peruse them all. I just worry that some might be quite large.

Any thoughts on what you'd like for this feature?

 

[Macrura]

ok, maybe not - i actually just realized that i need admins to be able to browse and delete the caches so may have spoke too soon.. yes, i do routinely output the cache vars as you demonstrate...

[adrian]

Just added support for $options when using the dump() / d() method. It lets you specify the maxLength, maxDepth etc parameters the same way you can with bd() calls. I couldn't manage to get an equivalent to barDumpLive() / bdl() working at the moment, but making the $options available should still be very helpful in the Console panel when inspecting large objects.

Also if you have the "Reference page being edited" option checked, this now also applies to edited Users, Roles, and Permissions which means that the ProcessWire Info panel will display details of these, rather than the parent process and in the console panel, $page will reference the edited user/role/permission, which should be a helpful addition.

One last thing (which took most of my day) - the recent SessionHandlerDB fix for showing the "redirect" debug bar was resulting in various PW notices being lost and not displayed. I think this should now be fixed, but please let me know if you find any other side-effects of that original fix.

[adrian]

Lots more updates today.

1) I have changed the default zIndex of the debug bar panels. In the Tracy core they are set at "20000" and go up from there as new panels are displayed, but these were always above the PW dropdown menus which meant you always had to close a panel to access menu items - very annoying. I have set them to "100" as a default, but this is also now configurable in the module settings so if you find you are having problems (especially on the frontend of your sites), you can adjust as needed. Please let me know though if you think there is a better default than 100.

 

2) Now if you are editing a field, template, or module in the admin, the Console panel will have access to: $field, $template, or $module, respectively which will be the object for the currently edited one.

So if you are editing the "body" field, instead of doing something like:

d($fields->get("body"));

you can just do:

d($field);

 

3) Again, when editing a field, template, or module, the ProcessWire Info panel now contains a new section at the top with details for the edited object. This is an example of the "body" field being edited.

 

4) The ProcessWire Info panel now uses the exact name of the PW property, rather than the old capitalized and spaced label. This means you can see what you will need to use in your templates to get a certain property.

 

Cheers!

[szabesz]

Thanks for the tweaks and new features!

8 hours ago, adrian said:

these were always above the PW dropdown menus which meant you always had to close a panel to access menu items - very annoying.

I have no idea what the "best" default value could be but I've never run into this issue. Probably because I do not actually use Tracy in the admin, it just sits there catching errors/notices  (currently I get undefined index notices form MarkupActivityLog and ProcessWireUpgrade).

However, defaults should be tailored to beginners and something like 100 seems to be too low in the frontend.

What do others say?  

[adrian]

Major speed improvement !

I have been in dialog with the Tracy core dev (David Grudl) for the last few hours and he has come up with a way to have all the advantages of the current version ("Master") of the Tracy core (including the AJAX bar), without the potentially huge speed penalty - the old ("Legacy") version was always much faster. On some servers, the new version was painfully slow at times.

For those interested, the slowdown was due to the use of $_SESSION to store the content of the debug bar. This was sometimes huge (especially will all the custom panels this PW implementation has). This new version doesn't use sessions for the main bar and because the AJAX bar doesn't show the custom panels, the size of the session is kept MUCH smaller.

This is brand new, but so far I don't see any side-effects, but please start using it and let me know if you come across any problems, or just feel free to comment on how much better it is! Maybe even drop David a thank you if you feel inclined.

[tpr]

I haven't noticed slowdowns (or perhaps I blamed my own code?) but good to know that there's less chance now to see them in the future  

[adrian]

12 minutes ago, tpr said:

I haven't noticed slowdowns (or perhaps I blamed my own code?) but good to know that there's less chance now to see them in the future  

For me it's been on one server in particular, but in general live servers are much worse than local dev, although I have seen it slow on a friend's local dev as well and I do remember others (eg @kongondo) reporting slow loading of the bar on local dev.

But yes, hopefully much better now!

[Robin S]

Hi @adrian,

To date I haven't used the Console panel much, because I prefer to write API snippets in my IDE (API code completion, version control, and having the code saved to disk just feels safer than trusting storage to a module). But I like the way the Console panel shows a handy list of snippets that can be executed by authorised users only (normally just superuser).

I see that the Console snippets are stored in the database as part of the module config data. What do you think about using a file for the saved snippets instead, with some scheme for labelling and delimiting the snippets within the file? Some benefits could be:

• Use an IDE / code editor to write snippets.
• Version control and file backups become possible.
• Easily share snippets between projects by copying the file or portions of it.
• No problems with exceeding the length limit of the config TEXT field in the database.

Edit: might be easiest to use one file per snippet, if there's no great performance penalty to that.

[adrian]

Hi @Robin S - thanks for your thoughts on this - I am certainly willing to think about file based storage of snippets, but a few thoughts/clarifications....

 

5 hours ago, Robin S said:

But I like the way the Console panel shows a handy list of snippets that can be executed by authorised users only (normally just superuser).

The console panel is actually locked to superusers only - I don't think it should be available to any other Tracy authorized users - it's just potentially too destructive. I think my AdminActions module is a much better tool for making snippets available to non-superusers - you can control who has access to what and you can provide actions where the snippets aren't editable.

5 hours ago, Robin S said:

Use an IDE / code editor to write snippets.

I can see why this is partly an advantage, but I actually really like the console panel - it has PHP code highlighting, completion and syntax checking. Admittedly it doesn't have PW code completion, but we could actually add that. The main reason I like it is that I type and then OPT + Enter and the code executes, which to me is much quicker than using my code editor, hitting save, reloading the site in my browser and then running the snippet from the console panel. I also worry about getting snippets out of sync - if you make changes in the Console panel and save your code editor should instantly reflect those changes to the file on disk (at least SublimeText does), but what about saving changes in your code editor - how does the Console panel get updated? What if you then save again in the Console panel - you'll overwrite the changes to the file that you made in your code editor. It looks like PHP's iNotify or FAM might work for updating the console panel, but they are not standard and sound resource intensive to me. Maybe I am overthinking this - what do you think about the issues I have raised?

5 hours ago, Robin S said:

Version control and file backups become possible.

Definitely a nice possibility - I  think we'd be storing snippet files in site/assets/cache/TracyDebugger, so as long as this directory is included in your versioning then I guess it would be ok.

5 hours ago, Robin S said:

Easily share snippets between projects by copying the file or portions of it.

Agreed that isn't super easy at the moment. I use my ModuleSettingsImportExport module to copy my Tracy settings (and therefor all my snippets) to new site installs. Obviously file-based snippets would be easier though. I actually think in this case we'd want a separate file for each snippet, rather than having "some scheme for labelling and delimiting the snippets within the file", as you noted at the end of your post.

5 hours ago, Robin S said:

No problems with exceeding the length limit of the config TEXT field in the database.

Definitely a good point, although I haven't come across that set - I think most snippets tend to be pretty short, but definitely a possibility that would be nice to avoid.

Looking forward to hearing your (and others) thoughts on this.

[Robin S]

4 minutes ago, adrian said:

The main reason I like it is that I type and then OPT + Enter and the code executes, which to me is much quicker than using my code editor, hitting save, reloading the site in my browser and then running the snippet from the console panel.

This would remain the same under my proposal - the only difference is the way the snippets are saved and retrieved. Instead of reading from and writing to the DB, Tracy would read from and write to a file. You would still be free to modify a snippet in the console.

15 minutes ago, adrian said:

I also worry about getting snippets out of sync - if you make changes in the Console panel and save your code editor should instantly reflect those changes to the file on disk (at least SublimeText does), but what about saving changes in your code editor - how does the Console panel get updated? What if you then save again in the Console panel - you'll overwrite the changes to the file that you made in your code editor.

As you say, code changes made in the Console get saved to file when the save icon is clicked (just like they are now to the DB).

You're right that changes made to a file would require some kind of reload process in Console (ajax-powered, ideally). Depending on how snippets are loaded, this might only affect the currently visible snippet - if each snippet is a separate file I could imagine that on opening the Console window Tracy would initially just grab the filenames to build the snippet list, and only load a snippet's code from file to Console when a snippet is selected in the list. So changing a snippet that is not currently visible would not result in any sync issue. And for the currently visible snippet, I can't see sync being a big issue - users will tend to prefer either the Console or their code editor and will probably stick to using one or the other rather than both simultaneously (or if they do use both, they will become mindful of the implications of doing that ).

34 minutes ago, adrian said:

It looks like PHP's iNotify or FAM might work for updating the console panel, but they are not standard and sound resource intensive to me.

Things like this wouldn't be necessary IMO.

[Robin S]

More thoughts...

If I'm a person that prefers to edit my snippets in my code editor rather than the console window, and I have made changes to the current snippet using my editor that are not yet reflected in Console (because I haven't clicked "reload" or whatever), then when I do "Run" I would want my newer file version to execute rather than the older snippet visible in Console. Maybe when "Run" is triggered, Tracy could see if the file is newer than the last Console edit and if so run the file version and reload the snippet.

This is getting complicated, right? Where I'm coming from is, I'm not worried about the code in Console and I don't even need to see it because I think I would always work with my snippet in my IDE. I'm just dreaming of a handy interface to run my snippets via the frontend. So maybe I need to explore this as a separate module, because Console already has a lot of happy users who like to write/edit/see their snippet in Console and perhaps my idea would be more disruptive than useful to them.

[adrian]

3 minutes ago, Robin S said:

I'm just dreaming of a handy interface to run my snippets via the frontend. So maybe I need to explore this as a separate module

Or perhaps a new panel in Tracy - a dedicated snippet runner (with no editing interface) that pulls & runs snippets from a defined folder? This could be pretty handy - what do you think?

Or again, maybe actions for AdminActions. Remember that actions don't need options page - they can be as simple as:

class UnpublishAboutPage extends ProcessAdminActions {

    protected function executeAction() {
        $p = $this->pages->get('/about/');
        $p->addStatus(Page::statusUnpublished);
        $p->save();
        return true;
    }

}

 

[Robin S]

5 minutes ago, adrian said:

Or again, maybe actions for AdminActions.

Thanks for the reminder about this. I think I have two different kinds of things I would potentially use snippets for instead of what I do currently (which is just temporarily bung some code into a template file).

1. Occasional API tasks for use in actual projects. AdminActions is probably ideal for this so I should give that module some proper attention.
2. Exploring/debugging issues, often ones that are raised by others here in the forums.

The latter is where Tracy is probably the best solution, because it's so handy to have $page available in the snippet code and often the explorations are disposable after a short while once the issue is resolved.

18 minutes ago, adrian said:

Or perhaps a new panel in Tracy - a dedicated snippet runner (with no editing interface) that pulls & runs snippets from a defined folder? This could be pretty handy - what do you think?

I for one would love that, if it's not too much work to add (hopefully much of it could come from what you've already developed for console).

Thanks for listening to my ideas, and the suggestions.  

[Mike Rockett]

Have been using Tracy for a while now, and recently got to thinking: would it be possible to override the exception template with something more PW friendly? Not a fan of the design at all as the red is just too much, and the exception heading text is just too big... Thoughts?

[szabesz]

1 hour ago, adrian said:

AdminActions

I think AdminActions is good for implementing automation features, not for quick debugging/testing purposes. Hence the name Actions

Not really a solution to Robin's idea but an "export to file" option could probably deal with the version tracking issue.

[bernhard]

I'm totally happy with the console as it is now  usually I'm a fan of having everything in my IDE, but I just don't use the console that way... I'm not really against changing it to a file-based system - just stating that it is not necessary for me.

[adrian]

5 hours ago, Mike Rockett said:

Have been using Tracy for a while now, and recently got to thinking: would it be possible to override the exception template with something more PW friendly? Not a fan of the design at all as the red is just too much, and the exception heading text is just too big... Thoughts?

Hi @Mike Rockett - absolutely happy to style these differently. @tpr already did a great job of improving the look of the panels - any chance you feel like having a go at improving the bluescreen (that's what the Tracy devs call it) error page? It would be nice to match the look of the panels for the various tables (Callstack, Variables, etc) on the bluescreen as well.

If you don't have time, I can have a go, but just thought I'd ask

[Mike Rockett]

20 minutes ago, adrian said:

Hi @Mike Rockett - absolutely happy to style these differently. @tpr already did a great job of improving the look of the panels - any chance you feel like having a go at improving the bluescreen (that's what the Tracy devs call it) error page? It would be nice to match the look of the panels for the various tables (Callstack, Variables, etc) on the bluescreen as well.

If you don't have time, I can have a go, but just thought I'd ask

Awesome - will have a look-see now. I'm sure I can whip something up.