Module Tracy Debugger

[szabesz]

9 hours ago, tpr said:

I'm not sure this would be better but wanted to share. The biggest advantage would be that it would pop out more from the rest of the page. Orange and red icons would require some brightening to be more visible though.

I do not think making the devbar pop-out is a good idea, at least I keep it always on even when I'm dealing with design so it is good to have it sit there while not distracting the general look of the page. Therefore the not inverted version is good for bright page designs, while the inverted one would be OK for dark page designs. Maybe automatic switching and/or option to set which one to use?

Regarding the color of the inverted one, a good compromise could be using goldish yellow and magenta like colors (and with not so blue color but slightly bluish gray background instead):

also, if the other icons are not white then colored ones pop-out more:

Edited August 17, 2018 by szabesz
EDIT: added not white icons demo

[tpr]

Making it optional means more work and maintenance. However if svgs are well prepared colorization can be easily added with something like

.tracy-invert-bar svg * { fill: white; }

As for inverted colors I often use the editor theme called Son of Obsidian as a reference. For example my file manager (Double Commander) colors are set up using that and it's beautiful ?

https://www.google.hu/search?q=son+of+obsidian&prmd=ivn

[netcarver]

13 hours ago, tpr said:

I think non-grey default icons would look nicer, eg. a darker blue like #354B60 (borrowed from the Uikit admin theme).

It's just a quick devtools preview but for me the current grey is too pale, and rather suggests that those icons are in an "off" state.

Hi @tpr I think this looks great! Not so sure about the inverted scheme - but it may work well with a darker admin theme.

[netcarver]

I've just issued a PR to the main repo for a reworked diagnostics panel for Tracy.

This...

• Adds a "Dedicated" server switch via cookies.
• Adds colour coded cells.
• Displays file permission flags.
• Adds checks for existence, ownership, readability by process user, writability by process user, world-accessibility, execute/traversal.
• Detects installation of the PW Upgrade module.
• Detects use of non-file session handling.
• Adds basic checks of the debug, chmodFile and chmodDir config settings.
• Unifies the colour scheme with the new Tracy constants.
• Supplies formatted suggestions for chown, chgrp and chmod commands (on non-Windows servers.) 
• Adjusts severity of issues reported based on Local vs Production server and/or Dedicated vs Shared server.
• Adds links to documentation for some assets.

If you want to try it out and let me know any problems you find, please consider using my temporary Fork of Tracy on github until Adrian has had a chance to consider merging the PR.

[szabesz]

@adrian Hi, If using Toggle All to turn on all panels, then when not enough memory is available we only get this in the source code of the page:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 3008800 bytes) in .../site/modules/TracyDebugger/tracy-master/src/Tracy/Helpers.php on line 133

Could there be a more graceful way to notify the developer? Since it is in the HTML output, I had to dig it up to figure out why the debugbar "disappeared" while the rest of the page was rendered ok.

[bernhard]

I've also had such an issue several times but no time so far to check out the reason

[netcarver]

Just trying the latest version on a shared host and found a bug regarding the config->debug setting. Will fix.

[adrian]

Busy morning ?

Firstly, a huge thank you to Steve (@netcarver) for his epic rework of the Diagnostics panel - take a look at the diff https://github.com/adrianbj/TracyDebugger/pull/24/commits/8604a683ef408b4106f7b7237b3eae6c24de315a - he's put in a huge amount of time on this. I have merged his changes and bumped up Tracy's version to 4.11.0 - it deserves a major point bump for this ? If you haven't used this panel much in the past, you really should take another look and give it a thorough go - it's really useful for new and experienced devs alike!

I also also added @tpr's blue for the icon color. Not sure about the inverted scheme just yet - any strong thoughts on it? I do think that the background color of the bar (the light version) could be made to look a little less dirty though. BTW, as a reference, take a look at the default Tracy bar: https://nette.github.io/tracy/tracy-debug-bar.html - be sure to check out the panels as well - we have @tpr to thank for our version looking considerably better than that ?

Regarding the automatic dumping of both full object and debugInfo versions, it could be as simple as this - just one version, and then the other. Perhaps some visual indicator so you know it's from one call or something. Any ideas/thoughts? @szabesz - you mentioned wanting the page ID shown without having to open the object - I don't think is any simple approach to do that, especially given that not all dumped objects are pages. Of course you can do: d($page, $page->id) but that's only useful if you are dumping multiple pages at once so you know which one is which. If you have any more specific thoughts on how to implement what you are looking, let me know.

Regarding the memory limit error - not sure what can be can about that - I guess Tracy can't handle that error because the error broke Tracy ? Seriously though there is just so much output when you have all panels toggled on that it's not surprising that these come up occasionally - I haven't seen one, but I up the PHP memory limit on my dev machine to 128M. 

Hopefully I answered everyone's questions, and please don't forget to test the new Diagnostics panel and give @netcarver your feedback.

[netcarver]

The diagnostics panel will need more follow-up work in the days to come, but hopefully it's a useful first step.

I've just noticed how bad the permission model for my current shared host is *sigh*. Looks like I'll be moving this site to a VPS sooner rather than later.

[tpr]

1 hour ago, adrian said:

Not sure about the inverted scheme just yet - any strong thoughts on it?

As I wrote that was an experiment only but wanted to share to you to check. The current latest is more consolidated if you ask me.

[bernhard]

yep, one theme is absolutely fine for me. looks great already! ?

[adrian]

On 8/16/2018 at 12:57 PM, szabesz said:

Would it mean that we have to click twice to see one of them? First a click on the arrow next to the class name, after that another click on either debugInfo or PW object? Or maybe you "extend" debug info and PW object gets injected into it?

Either way, I think it would be nice to see the id of a Page object without clicking on anything, somewhere between the class name and the arrow. Is that possible?

What do you guys think about this approach.

As you can see I have automatically combined the debugInfo and the full object versions into an array. I have also added an automatic title if one isn't specified. I was thinking about making this all work for PW's $page, $template, $field, etc objects.

 

The one concern I have is that at first glance this looks like $page returns an array, so I wonder if it might be better simple, like this where the first dump is debugInfo, and the second one is the full page object, but they both are obviously a PW $page object.

 

Not sure - what do you guys think? I am pretty keen to have both version output automatically, but I want it to be obvious what's what.

 

[szabesz]

9 hours ago, adrian said:

The one concern I have is that at first glance this looks like $page returns an array

I agree, we should avoid making this "impression". However, UI-wise I like the first approach a lot more: more compact and makes a group of the two. Cannot you somehow output this:

Edited August 18, 2018 by szabesz
typo

[bernhard]

At first glance I liked the array-approach, but thinking about it a little bit more I think it is not a good idea to modify the type of the originally dumped object. It should really output the correct type. Also @szabesz suggestion would be a wrong output for my understanding.

Having one d() call output two dumps on the other hand can also be misleading.

IMHO the best solution (and I guess also the simplest one) would be to have d() output the debuginfo version and dv() = dumpVerbose() output the verbose info with debugInfo = off. I don't think that a config setting is necessary or any better. I think it's even more confusing and one more thing to keep in your mind. Another setup and you might end up in another output. Not the best option.

d() and dv() would just be one thing to remember across all setups and it would produce a consistent output always and everywhere.

EDIT: Another option I could think of would be something like this, having a toggle in the label section showing/hiding one or the other but outputting only one visible object for one single dump and also showing correct variable types:

The label, eg d($page, 'my custom label'); could also be shown right beside the toggles

 

[szabesz]

14 minutes ago, bernhard said:

it is not a good idea to modify the type of the originally dumped object

Then let's not call it "dump" ? Seriously, we need debug info and not "dumps". I'm longing for a version which outputs both so there is no need to use options or different method calls, and I really do not mind if that one is not d() but maybe i() (short for info) or whatever, if d for dump is misleading.

Edited August 18, 2018 by szabesz
typos

[bernhard]

29 minutes ago, szabesz said:

Then let's not call it "dump" ? Seriously, we need debug info and not "dumps".

I don't care about how we call it, but I care about what it shows and dumping/debugging/infoing a page object that is then labelled as array is simply not what I understand as good/correct dumping/debugging/infoing.

PS: actually I even do care a little about how we call it ? dump() is already some kind of standard. we have dump() and bardump() and it's called exactly like this in the nette docs. It's a better alternative for var_dump() and well... that also "dumps" variables. We already have firelog() and log() so I see no need for introducing another one (for me d() and dv() would be a similar thing and mean about the same just with different options. dump() and dumpVerbose() => tracy bar, log() => file, firelog() => dev console).

[szabesz]

3 minutes ago, bernhard said:

we have dump() and bardump() and it's called exactly like this in the nette docs.

Your idea is to stick to "dump", while Adrian's idea is different. Let's not try to merge the two ideas, but come up with a solution to support Adrian's original idea which is great, I think.

[bernhard]

That was my suggestion:

But I guess that's more effort than just implementing a new method dumpVerbose() with different settings. Let's wait for adrian to wake up - good morning btw ??

[adrian]

Morning ?

Thanks for the thoughtful discussion @szabesz and @bernhard - I think I like Bernhard's idea of a toggle, although I think it belongs below the title, just before the dumped objects.

I think I'll go with debugInfo and Full Object as the labels for the toggle though - I'd rather this was more explicit and helps to educate new developers about what they are actually seeing.

I tried blending the debugInfo version into the main object and it works but it gets added to the data property, so you have to dig down to find it and it gives an incorrect impression of how the object is actually constructed. This would certainly be the simplest approach, but I'll take a look at implementing the toggle idea - I think if that works it will be the cleanest and most useful.

 

[adrian]

Ok, here is a really quick and dirty demo. Obviously the links need to look nicer and the selected one needs to be highlighted, but hopefully you get the idea. Any thoughts before I clean it up? 

[adrian]

Playing with this idea where the toggles are icons floated to the right of dumps that have both debugInfo and regular object versions. Notice that the currently selected version of the dump results in the highlighted icon color.

I think I need some help figuring out the most useful / cleanest looking option for this.

Any ideas?

 

 

[adrian]

Here's a screencast of the icon based switching in action. 

Is everyone happy with this approach? Any ideas for improvements?

 

Back to @szabesz's idea of the page ID being shown - I have removed that from the recent screenshots/casts, but here it is again with the new icon toggles in place. What does everyone think about these automatic titles - useful, or unnecessary - I am not sure.

[szabesz]

18 minutes ago, adrian said:

Any ideas for improvements?

Thanks, looks ok, except the possibility of the icons "jumping" because of the scrollbar. Is it possible to move them to the left instead?

21 minutes ago, adrian said:

What does everyone think about these automatic titles - useful, or unnecessary - I am not sure.

If it's a collection of pages (WireArray and derived) then we could see the number of pages, for example. My idea is to see the basics so that there is no need to click on anything if that is enough.
BTW, it will also work with bd(), won't it?

[adrian]

14 minutes ago, szabesz said:

Thanks, looks ok, except the possibility of the icons "jumping" because of the scrollbar. Is it possible to move them to the left instead?

I tried both. Here is left which is fine and does prevent the scrollbar jumping, I didn't like the way it affected left alignment compared to other dumps like the "test" one above, but maybe it's ok?

15 minutes ago, szabesz said:

If it's a collection of pages (WireArray and derived) then we could see the number of pages, for example. My idea is to see the basics so that there is no need to click on anything if that is enough.

I see where you're headed, and I like the idea but I am a little worried about going down a huge rabbit hole. Maybe if you can put together a list of PW objects and the data you think should be automatically displayed in this way, maybe we can come up with a solution. I am actually thinking that this might need to be another element that sits between the title (if defined) and the object dump.

20 minutes ago, szabesz said:

BTW, it will also work with bd(), won't it?

That's the plan - I haven't coded it yet so not sure - there could be some complications, but hopefully solvable.

[szabesz]

8 minutes ago, adrian said:

, but maybe it's ok?

Another UX thing is that icons on the left require shorter mouse movements, well most of the time ?

11 minutes ago, adrian said:

I am a little worried about going down a huge rabbit hole.

Sure...

11 minutes ago, adrian said:

Maybe if you can put together a list of PW objects...

I am really thinking of the basics here, nothing more: id, count() that's all that comes to my mind ?