Module Tracy Debugger

[Zeka]

Im sorry if my question was already answered somewhere, but there is 25 pages to read and i can`t find it. 

Here is my config of Tracy:

I work on localhost. Debug mode is set to false, I am logged out from admin panel, but Tracy is still showing on frontend.

I can`t figurate out is it normal behavior for Tracy, because earlier, if Im not mistaken, with the same options it was not showing? 

Im using latest Tracy version and PW 3.0.30.

 

 

[szabesz]

@Zeka How about unchecking "Frontend" in "Debug Bar and Panels > Show Debug Bar"?

Edited September 7, 2016 by szabesz
spelling

[Zeka]

@szabesz Yes, of course, if I uncheck to show in frontend it will be not shown, but i was thinking that if debug is set to false and Im not logged in as superuser it should be not shown. 

[adrian]

  On 9/7/2016 at 6:51 AM, Juergen said:

Tracy makes problems during updates of modules if it is in strict mode (show warnings as errors), because there are several warnings of the PW core files. I use it in strict mode and I always have to disable Tracy Debugger if I want to update a module. Otherwise the module will not be updated if I skip the warning. So it would be a nice addition if you add an enable/disable link for Tracy Debugger at the bottom like AdminOnSteroids module (see image below). This makes the workflow much easier.

Expand  

Ok, I'll see what I can do. Obviously a disable link like AOS has would only be available when you're in the admin, but if the only problem you are having is module updating, then that is probably ok. I had actually been thinking about a "Disable Once" button available from the debug bar that would prevent Tracy from being loaded on the next page load, but I don't think this would handle your situation anyway because module updating involves a few page loads. One thing though - if you are getting warnings from PW core files - have you reported these as issues on Github? 

 

  On 9/7/2016 at 7:07 AM, szabesz said:

As opposed to AOS, we can enable Tracy for both frontend and admin, so the disable feature would be nice to have on its main panel too, which I have already missed a few times.

Expand  

Sorry, what is the "main panel" you are referring to? Do you mean the debug bar, or the panel selector panel? Do you have any specific ideas for how best to provide a disable feature?

 

  On 9/7/2016 at 9:02 AM, Zeka said:

@szabesz Yes, of course, if I uncheck to show in frontend it will be not shown, but i was thinking that if debug is set to false and Im not logged in as superuser it should be not shown. 

Expand  

You have noticed something that I have been considering changing. It was meant as a feature, but I wonder if it's more of a confusion. Basically the logic is that if you are in DETECT mode and Tracy also determines that you are on a localhost, then it will display the debug bar regardless of whether you are logged in or not. If you switch to DEVELOPMENT or PRODUCTION mode, it will behave the same as a live server. I was trying to make it easy to have the debug bar available to test things when not logged in, but now that Tracy has the User Switcher panel, we don't really need this, because we can use the User Switcher to change to a non-superuser (or even logout) and still have access to the debug bar for the length of the user switcher session. Do you (or anyone else) have any thoughts on the best scenario here?

[szabesz]

  On 9/7/2016 at 3:42 PM, adrian said:

"Disable Once" button available from the debug

Expand  

This one and a permanent disable feature is what I'm voting for. 

  On 9/7/2016 at 3:42 PM, adrian said:

what is the "main panel" you are referring to?

Expand  

 I mean the "System Info", since this is the one that cannot be turned off. "Disable Once" and "Disable Permanently" would do, I suppose.

[adrian]

Ok, the latest version has a new disable/enable option.

I added the Disable button  to the bottom of the Panel Selector because I think most of you have that enabled all the time. Please let me know if that won't work for some of you and I can rethink @szabesz's suggestion for adding it to the System Info panel. I would have done that straight away, but that is a Tracy core panel, so I would have to add with JS. The main problem is that panels are lazy rendered, so the DOM for panels is not available until the first time they are loaded. Still do-able, but requires a little more effort.

The Enabler button is simply a red bug icon (like the one I am using for Tracy in the site modules list). It appears at the bottom right of the page when you have disabled Tracy. It only appears on frontend and backend if the debug bar is enabled for those locations.

Note that this disabler doesn't actually uncheck the "Enable Tracy Debugger" checkbox in the settings - it's just disabled with a cookie. I am happy to revisit this approach, but my reasoning was that I'd rather the settings checkbox had a little more power, so that if it's unchecked there, the enable icon won't actually appear at the bottom right of your site.

Anyway, hope this helpful and don't be shy if you think I have messed it up by doing it this way  

 

 

[adrian]

I decided to add a dedicated "Tracy Toggler" panel. Well it's actually just a button  - you can see it second from the end:

and when it's disabled, this is all you see at the bottom right of your site:

I left the "Disable Tracy" button in the Panel Selector because I figured some users may prefer that approach - it's your choice.

[szabesz]

Thanks again Adrian! One issue with the Panel selector: we have "too many panels"  On one hand this is awesome, on the other hand we are running out of space:

  Reveal hidden contents

And this is with a set of css rules that do not override the small line height + small font size. I also used "css frameworks" which blew it up and it took a lot more space than this. Since you added "Disable Tracy" to the bottom, we've lost valuable space.

It's ok if you do not want to hack the System Info panel, I "had the feeling" it might not be supported to add anything to it, so that is out of the question. However, this panel should be laid out in a horizontal manner as much us possible, so that to make room for the other panels you are going to add in the near future  

Jokes aside, you might want to logically group panels in the list (you know I'm talking about @tpr's AOS-settings-like groupping) so that they can be found more easily. And this is true for the admin's setting, where a similar groupping can help too (we've already touched this topic).

[adrian]

Thanks for your thoughts as usual. I keep for forgetting about your screen real estate limitations. My laptop is 1680 x 1050 and my last one was actually 1920 x 1080 (from 2003) so I forget that people have smaller resolution to work with.

  On 9/8/2016 at 1:10 PM, szabesz said:

I also used "css frameworks" which blew it up and it took a lot more space than this. Since you added "Disable Tracy" to the bottom, we've lost valuable space.

Expand  

I thought I took care of this recently - are you still seeing this problem? There are lots of things that I need to override but it takes time to come across them all. Please let me know whenever you find a CSS attribute that I have missed.

  On 9/8/2016 at 1:10 PM, szabesz said:

Jokes aside, you might want to logically group panels in the list (you know I'm talking about @tpr's AOS-settings-like groupping) so that they can be found more easily. And this is true for the admin's setting, where a similar groupping can help too (we've already touched this topic).

Expand  

What would the logical groupings be? I just made them in alphabetical order which I thought would be simplest. I agree that the admin settings could be improved. I'll admit I don't have @tpr's flare for that though  

[tpr]

Well at first using CSS3 column-count could be handy for the panel list here. Eg. 2 columns, then the panel would be more than 2 times wider.

You could also use CSS "all: initial;" to reset all styling - of course then you will have to re-style everything.

  On 9/8/2016 at 1:22 PM, adrian said:

I'll admit I don't have @tpr's flare for that though  

Expand  

Better saying you have more important things to do than beautify the admin

[adrian]

@tpr - columns for the panel selector does sound like a decent idea.

The Tracy core CSS is a bit of a pain - I already have to make one core hack because of the way they have things set up. I am actually using all: initial in one place already, but not everywhere. Maybe I'll revisit using it more.

  On 9/8/2016 at 1:28 PM, tpr said:

Better saying you have more important things to do than beautify the admin

Expand  

That's always been my thought too, but when I see what you have done with AOS I second guess that decision

[szabesz]

  On 9/8/2016 at 1:22 PM, adrian said:

What would the logical groupings be?

Expand  

Good question... To tell the truth, I've lost track of the features the module has to offer and only use a small set of panels, so I'm not the one who could answer this easily, but they could be grouped by functionality if it is possible.

  On 9/8/2016 at 1:22 PM, adrian said:

are you still seeing this problem?

Expand  

No, I had this issue some time ago, but not recently. I will investigate and report should I see it again.

[adrian]

Is this better? That's how it looks in the latest version.

[tpr]

Looks more usable to me. I see some room for improvements, eg.

• move the Toggle All to the panels list as first item (plus make it bold to add some weight). I think no need to pull it to left as now.
• Disable Tracy could go to the far right, in the same row as the 3 other buttons (Once, Sticky, Reset)
• the top legend below the main title ("Temporarily enable/disable...) could go into one row, separated by eg. this: " • ", or float the second line to right

Plus when Tracy is disabled, its icon's position overlaps with the scrollbar (when AOS is active). Using "right: 10px" seems too small, around 20-24px this could be eliminated.

[szabesz]

  On 9/8/2016 at 4:17 PM, adrian said:

Is this better?

Expand  

Definitely! Thank you. I think it also helped a lot in being able to more easily find the panel one needs to spot, the alphabetical order might be the one to keep, and probably there is no need for "arbitrary" grouping (at least I was not able to suggest groups, because of the diversity of the functions the panels represent).

[adrian]

Tweaked, although I still like the "Toggle All" out on its own. I have also cleaned up the time/size values at the bottom of all panels - very simple now with no superfluous text.

 

[Macrura]

@adrian quick question - is it possible have Tracy active only for only select users, or limit by IP?
The current behavior is that tracy is active for all logged in users, unless you specify the IP but the IP only prevents non superadmins, seems to be always active for all superadmins..

[Juergen]

  On 9/7/2016 at 3:42 PM, adrian said:

Ok, I'll see what I can do. Obviously a disable link like AOS has would only be available when you're in the admin, but if the only problem you are having is module updating, then that is probably ok. I had actually been thinking about a "Disable Once" button available from the debug bar that would prevent Tracy from being loaded on the next page load, but I don't think this would handle your situation anyway because module updating involves a few page loads. One thing though - if you are getting warnings from PW core files - have you reported these as issues on Github?

Expand  

Yes I have reported it on Github: https://github.com/ryancramerdesign/ProcessWire/issues/2031

Best regards

[szabesz]

  On 9/9/2016 at 8:37 AM, Juergen said:

Yes I have reported it on Github: https://github.com/ryancramerdesign/ProcessWire/issues/2031

Expand  

Which one is the recommended repo to report issues currently? ryancramerdesign/ProcessWire or processwire/processwire ? Do we have a guideline to choose between the two? I do not remember seeing one.

[bernhard]

  Quote

To get things started, I've pushed ProcessWire 3.0.33 RC1 to this new organization account in the new ProcessWire repository. This is our way of testing things out. You'll see the same version posted on the devns branch of our old repository, so it doesn't matter where you download it from. But once 3.x is our new official version, then this new repository is where you'll want to get it from.

Expand  

so i _guess_ it does not really matter until that date. but i would choose the new one right from now...

[adrian]

  On 9/9/2016 at 3:47 AM, Macrura said:

@adrian quick question - is it possible have Tracy active only for only select users, or limit by IP?
The current behavior is that tracy is active for all logged in users, unless you specify the IP but the IP only prevents non superadmins, seems to be always active for all superadmins..

Expand  

A little confused here, although I think you might be seeing what @Zeka noted above: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=127543

If you are in DETECT mode and on local host then the debug bar is active for everyone, even guest users. Is that what you are seeing? If it is, please see my response here: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=127589

If not, then it might be something I need to investigate in which case it would be great to have some more details.

 

[adrian]

Actually in response to Macrura's question I want to clarify some things - Tracy active vs the debug bar visible vs Production/Development are all different things.

Once installed, Tracy is always active. Even unchecking "Enabled" loads some files - these files handle your bd(), d(), fl(), l(), da() calls so that non Tracy users / guests won't get undefined function errors in case you have some of those calls in your live code.

In Production mode Tracy is fully loaded to handle all errors, but it doesn't display those errors or the debug bar - it logs the errors and can email you of an error (if you have the settings configured with your email address and "Allow Logging in Production Mode" checked.

In Development mode (either set or determined from Detect mode), errors and the debug bar are displayed (although the debug bar can be hidden from front/backend based on those checkboxes). 

It can be all a bit confusing which is why I am contemplating removing the Detect mode option and maybe even making the "Output Mode" panel one of the defaults when Tracy is installed. 

If anyone has any thoughts on improved behavior, I am all ears!

[szabesz]

I do like (and use solely) the Detect Mode being on, so I'm against of removing it even tough I also see that it can lead to confusion. Tracy has so many options to choose from in a diversity of areas that it has become quite a challenge to familiarize ourselves with it anyway. However, I do not think getting rid of functionality is the way to go, although probably it is the easiest solution sometimes, so it is you who needs to decide in the long run.

  On 9/9/2016 at 12:08 PM, adrian said:

Even unchecking "Enabled" loads some files

Expand  

So we might be able to clear things up a bit by using different terms, not enable/disable.

What if we come up with some flowchart like setup-help, something like this:

  Reveal hidden contents

I use yEd to draw things like that and would be happy to do its first version if you think it might help. (You could even build a "setup wizard" based on it, but that might be overkill and a lot of work.)

Or, we can just make a table like chart to summarize the various states and results of the settings, something like this "Value of variable" chart in this post:

https://www.virendrachandak.com/techtalk/php-isset-vs-empty-vs-is_null/

[adrian]

@szabesz - thank you for the offer of putting together a flow chart. It might prove useful, but I am honestly wondering whether the fact that we are even discussing the need for a flowchart means that I have failed - if something is complicated enough that we need a flowchart, I get the feeling it needs be to simplified.

  On 9/9/2016 at 12:33 PM, szabesz said:

I do like (and use solely) the Detect Mode being on

Expand  

Thanks for your thoughts on this - maybe I should at least remove the "show the debugbar to everyone when Detect determines localhost" behavior - that seems to be a confusion.

[szabesz]

  On 9/9/2016 at 12:55 PM, adrian said:

at least remove the "show the debugbar to everyone when Detect determines localhost" behavior - that seems to be a confusion.

Expand  

Well, I know this idea will be against simplifying things, but what if this behavior can be turned on optionally, so it is not completely removed?