Module Tracy Debugger

[adrian]

Back to the Tracy logs directory/files permission issue - I have just added a check that prevents the error and warns if the directory is not readable. 

Still don't know why it ended up that way for you guys, but at least now Tracy will still work and you'll get a message about why it can't show the Tracy log file entries.

[adrian]

@tpr - back to your slow loading issue - I don't think it is https related. I am getting TTFB for 3 scripts files at about 10s for all. This only happens for the master (dev) version of the Tracy core which is loaded automatically if you have php 5.4.4+. If I manually force the stable version to load, then it loads very quickly.

Weird thing is that I have two PW installs on my local dev setup and one is fast with the master version and one is slow. So I need to investigate further but thought you'd like an update on that.

Until I get it sorted properly (maybe needs a fix in the Tracy core), you can always force the stable version of Tracy here: https://github.com/adrianbj/TracyDebugger/blob/master/TracyDebugger.module#L102 - you'll want to change the two lines after that.

Hope that helps in the meantime.

[tpr]

Thanks, I will try that. I could revert to a previous version but it's not that crucial on the project in question.

I got the slowdown even with no panels selected. I also tried to play with the settings but it didn't helped.

[tpr]

OK, updating to the latest module version reverted the working debug bar

But I manually updated Tracy (master), and it's OK now (non-https).

There was a commit 4 days ago which may be related (according to the variable names in there ).

Logging is also OK with the default 755 permission on logs/tracy dir.

[adrian]

The module includes the latest core version of Tracy with that commit you referenced, so not sure why manual updating would have helped. Also note that I make a couple of manual modifications to the core to make editor links reference the main template file, rather than the compiled version, so you will have problems there.

Did you try the stable version - that should really speed things up - seems to me that the new src/Tracy/assets/Bar/loader.phtml approach used by master is the source of the slowdown.

Any chance you can give me access to this server - I am baffled as to why the latest commit to the module stopped by debugger bar from working again.

PS For reference, here is my Issue report to the Tracy core: https://github.com/nette/tracy/issues/157 - hopefully they'll be able to figure out the slowdown problem with the master (dev) version.

[tpr]

I'm afraid I can't give server access, those are clients' server.

I uninstalled Tracy and then reinstalled, and the bar is gone again. Switching to the master version in L102 fixes it, so I guess it should be a Tracy core issue.

[adrian]

Hi everyone,

A few commits today to improve a few things.

1. You can now choose the branch of the Tracy core from the modules config settings. It defaults to the master (dev) version if you have PHP 5.4.4+, but now if you have having the slow rendering of the debugger bar (mentioned by @tpr above), you can easily choose to load the stable branch instead. Hopefully the Tracy folks will fix this and if they do, I'll likely remove this setting in the future.
    
2. There is now better panel resizing and scrolling of internal content - this is especially handy with large panels when you have the dev console open on the bottom. Probably still not perfect, but should be much better. Actually I think the Tracy core needs some work to make this even better.
    
3. Performance Panel now has internal scrolling - this was absent before.
    
4. Enhancements to the Debug Mode panel, including linking of the API variables to the new PW 3.x API Reference docs.

[tpr]

It's great to be able to switch to the Stable branch, now Tracy bar appears here without editing the module file, thanks!

[adrian]

Just added a new "Core Classes" section to the debug panel - so now you have really quick access to the new 3.x API ref docs for all the core classes.

[adrian]

sorry adrian for being late - there was too much going on in this thread so i set notifications to weekly...

the simplest solution would be to send a get request like this:

some errors: https://validator.nu/?doc=https://processwire.com/talk/&out=json

valid: https://validator.nu/?doc=https://processwire.com/&out=json

maybe parse this json and set the color of the panel to green = valid, orange = warnings, red = errors

and a link to the validator report. nothing more needed, i think

Hi Bernhard,

I finally made some time to add a validator panel. 

At the moment it only works with live sites because I am using the standard "doc" method for sending the URL to the validator.nu service. If you guys are interested in a version that also works with local dev sites, let me know and I'll add that too - looks like it's possible, but this was the easiest way to get started to see what you think.

The debugger icon is changed based on the report so you have a quick visual of the result.

The panel is not enabled by default.

Anyway, let me know what you think.

[adrian]

I decided to go ahead and make the validator work with local dev sites as well (note the local ".dev" domain in the results). Also note that the validator is now using the html5.validator.nu version when it sees a HTML5 doctype declaration.

Note the colored "cross" icon indicating some errors.

[bernhard]

thank you adrian, that's great! i didn't think about dev-sites. that's surely a good thing to be able to check the markup before going online

[adrian]

A small, but hopefully useful timesaver - I have added a new method:

TD::debugAll()
debugAll()
da()

This will output the content via all dumping/logging methods: barDump(), dump(), fireLog(), log()

This can come in handy when you want the expandable tree that you get with barDump, dump and fireLog, but also want to store in a log file for later comparisons. It can also be useful in AJAX calls or some other instance when you're not sure if barDump / dump will work or not, or if there is a page redirect which causes them to disappear from fireLog / dump

Obviously this will be a little slower (depending on the complexity of what is being dumped), so maybe don't use it by default, but it's as another useful timesaving tool in your arsenal.

Note - you'll need to enable the debugAll() and da() shortcuts in the config settings.

[adrian]

Latest version adds a "Panel Selector" panel to the debugger bar.

I added this because I noticed that the overhead of having all panels loaded all the time can sometimes be a few seconds depending on the server. With this new feature you can pare down the main "Show Panels" module config setting to just the ones you want all the time and then use this new panel to quickly and easily enable additional panels for a specific purpose without having to go to the module's settings and mess with the defaults.

The changes to the list of panels is stored in a session cookie, so as soon as you close the browser (or you use the "Reset Default" option), you'll return to your default set of panels.

Hopefully you'll find this speeds things up for you.

On this note, if you are finding things slow you may want to consider the config setting for switching to the stable version of the Tracy core (this was mentioned several posts ago, but in case you missed it, it can make a huge difference. Hopefully the Tracy guys will come up with a solution (https://github.com/nette/tracy/issues/157) for the master/dev branch before it is marked stable).

I am also going to do some code review on all the panels in an attempt to speed things up - I am sure there are some things I overlooked in initial development that can be dramatically improved. Let me know if anyone has any ideas though.

[adrian]

Sorry - another minor improvement. You now have "Once" vs "Sticky" options.

"Sticky" behaves like the previous version - the selected panels will remain until you reset or close the browser.

The new "Once" option will only change the panels for the one reload that happens when you click the button.

This should make it even easier to quickly view a panel you rarely need like PHP Info for example.

[szabesz]

Thanks Adrian! I could speed thing up considerably (especially by switching to stable from master, but turning off two additional panel helped too.)

However, I cannot use the checkboxes in the Panel Selector panel. Probably my css rules conflict with the ones needed for this panel to work. The checkboxes are situated over their "labels" respectively and the click event is not handled at all, not matter where I click, nothing happens.

I did not spend too much time to investigate what causes this, so I don't know it yet, but by turning off all linked styles (by using Chrome's Web Developer extension by Chris Pederick) the layout of the panel is back to normal and the checkboxes work as expected.

Isn't there a way to make sure that this panel works whatever css rules the underlaying page has?

[adrian]

Thanks Adrian! I could speed thing up considerably (especially by switching to stable from master, but turning off two additional panel helped too.)

Thanks for the feedback on this - I'd love to know which two panels sped things up the most - maybe I can optimize them.

However, I cannot use the checkboxes in the Panel Selector panel. Probably my css rules conflict with the ones needed for this panel to work. The checkboxes are situated over their "labels" respectively and the click event is not handled at all, not matter where I click, nothing happens.

Thanks for reporting - I'll look into it although I am curious what styles you have that are moving the checkboxes over the labels.

[adrian]

Isn't there a way to make sure that this panel works whatever css rules the underlaying page has?

Well CSS is not my strongest skill, but I think this is generally tricky. There is:

all: initial

which has pretty good support these days, but I am still having some troubles getting initial values for everything. I have made some changes that may help you, including using proper <label> tags for the checkboxes. 

On an unrelated note, there is now also a toggle all checkbox for even quicker modification of panel selection.

Please let me know if any of my changes helped and if not, it would be great if you could spend a little time figuring out what rules are conflicting - thanks!

[adrian]

New version:

1. New config setting for the number of entries to show in log viewer panels (now defaults to 10 rather than 25 to speed things up a little). You might even want to change this to 5. The PW logs panel isn't too bad, but currently the Tracy logs panel is definitely a little slow - I will also be looking into speeding this up.
    
2. Panel generation time is now listed at the bottom of each panel which should help you to decide which ones to not show by default.

Unfortunately the PW Info panel is one of the slower ones at the moment, so I will tackle trying to speed that one up first.

Not surprisingly, the Diagnostics and Validator panels are also relatively slow, so depending on the speed of your server, it might pay to have those off by default.

Let me know if any of you notice any panels that are particularly slow on your systems.

[tpr]

Is the Validator panel ajax-driven? That could speed things up too I guess.

[szabesz]

have made some changes that may help you, including using proper <label> tags for the checkboxes.

Thanks Adrian! Probably this change made the checkboxes clickable. As for the css issue, I could fix the issue of the boxes covering the labels by applying these rules:

#tracy-debug input[type="checkbox"],
#tracy-debug input[type="radio"] {
    width: 12px;
    height: 12px;
    position: static;
}

Sure, the radio version is not needed in this particular case, but my css "framework" also define its rules for that selector, so just in case... Position was absolute, so that is why the labels slid underneath the checkboxes, and dimensions were also quite "incompatible", so to speak.

I will look into my performance issues as well (when I have the time) and report back. I've also noticed the new version being released in the meantime. Keep up the good work, your fans – including me – love this gem!

[adrian]

Is the Validator panel ajax-driven? That could speed things up too I guess.

Do you mean so that loads in the background so that it doesn't slow the rendering of the page itself? If so, then that sounds like a good idea.

Interestingly, as I am testing the generation speed of various panels on different servers, I am seeing that almost all panels are very fast on a decent server - it seems like it is mostly my aging Macbook dev setup that is struggling - maybe I don't need to worry as much as I thought.

What are you guys seeing?

Thanks Adrian! Probably this change made the checkboxes clickable. As for the css issue, I could fix the issue of the boxes covering the labels by applying these rules:

#tracy-debug input[type="checkbox"],
#tracy-debug input[type="radio"] {
    width: 12px;
    height: 12px;
    position: static;
}

Sure, the radio version is not needed in this particular case, but my css "framework" also define its rules for that selector, so just in case... Position was absolute, so that is why the labels slid underneath the checkboxes, and dimensions were also quite "incompatible", so to speak.

I will look into my performance issues as well (when I have the time) and report back. I've also noticed the new version being released in the meantime. Keep up the good work, your fans – including me – love this gem!

Thanks for looking into this - I am happy to add those styles to Tracy, but I am not sure from your message whether or not you still need those with the version I posted that includes the all: initial - can you please confirm that your code is still needed and still works on the latest version.

Thanks for the kudos - glad you are loving it

[szabesz]

Sorry for not being clear! Version 1.4.9 did not solve the problem of the labels sliding under the checkboxes, so if it is ok, please to add those styles to Tracy. Since you mentioned it, I also tried to fix the issue with "all: initial", but could not figure out anything that cloud work.

[adrian]

No problem - thanks for clarifying and for helping to sort this out.

Latest version includes that style.

Let me know if there are still any problems.

[szabesz]

Thank you very much! Now the "Panel Selector" panel looks like just the one on your screenshot and works fine.

Implementing it was really cool idea, I also used to switch panels on and off a lot of by going to the PW settings, so it is a real timesaver.