adrian

Tracy Debugger

Recommended Posts

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:

screencapture-biotestlab-dev-admin-module-edit-1473236927321.png

screencapture-biotestlab-dev-admin-module-edit-1473237316826.png

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.

 

 

Share this post


Link to post
Share on other sites

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

Edited by szabesz
spelling
  • Like 1

Share this post


Link to post
Share on other sites

@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. 

  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, 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.

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? 

 

8 hours ago, 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.

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?

 

6 hours ago, 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. 

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?

Share this post


Link to post
Share on other sites
22 minutes ago, adrian said:

"Disable Once" button available from the debug

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

23 minutes ago, adrian said:

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

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

Screen Shot 2016-09-07 at 1.03.14 PM.png

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 :) 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

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

Screen Shot 2016-09-07 at 3.21.27 PM.png

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

Screen Shot 2016-09-07 at 3.23.04 PM.png

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

  • Like 3

Share this post


Link to post
Share on other sites

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

Spoiler

toooo-tall-tracy-panel-selector.png

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 :D:D :P

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).

  • Like 1

Share this post


Link to post
Share on other sites

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.

4 minutes ago, 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.

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.

10 minutes ago, 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).

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 :) 

  • Like 1

Share this post


Link to post
Share on other sites

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.

1 minute ago, adrian said:

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

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

  • Like 2

Share this post


Link to post
Share on other sites

@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.

3 minutes ago, tpr said:

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

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

  • Like 1

Share this post


Link to post
Share on other sites
16 minutes ago, adrian said:

What would the logical groupings be?

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.

19 minutes ago, adrian said:

are you still seeing this problem?

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

Share this post


Link to post
Share on other sites

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

Screen Shot 2016-09-08 at 9.14.41 AM.png

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites
17 minutes ago, adrian said:

Is this better?

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).

  • Like 1

Share this post


Link to post
Share on other sites

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.

Screen Shot 2016-09-08 at 11.49.12 AM.png

 

  • Like 2

Share this post


Link to post
Share on other sites

@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..

Share this post


Link to post
Share on other sites
On 7.9.2016 at 5: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?

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

Best regards

  • Like 2

Share this post


Link to post
Share on other sites
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.

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

  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, 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..

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.

 

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites

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.

15 minutes ago, adrian said:

Even unchecking "Enabled" loads some files

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:

Spoiler

h5d-sectioning-flowchart.png

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/

  • Like 1

Share this post


Link to post
Share on other sites

@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.

20 minutes ago, szabesz said:

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

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.

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, adrian said:

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

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?

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Anssi
      A simple module to enable easy navigation between the public and the admin side of the site. After installation a green bar will appear to the upper side of the screen, containing a few navigation elements and displaying the PW version number.
      Heavily inspired by @apeisa's great AdminBar (Thanks!). I needed a bit simpler tool for my projects and as a result, this was made. Available on GitHub .

    • By Sebi
      I've created a small module which lets you define a timestamp after which a page should be accessible. In addition you can define a timestamp when the release should end and the page should not be accessable any more.
      Github: https://github.com/Sebiworld/PageAccessReleasetime
      Usage
      PageAccessReleasetime can be installed like every other module in ProcessWire. Check the following guide for detailed information: How-To Install or Uninstall Modules
      After that, you will find checkboxes for activating the releasetime-fields at the settings-tab of each page. You don't need to add the fields to your templates manually.
      Check e.g. the checkbox "Activate Releasetime from?" and fill in a date in the future. The page will not be accessable for your users until the given date is reached.
      If you have $config->pagefileSecure = true, the module will protect files of unreleased pages as well.
      How it works
      This module hooks into Page::viewable to prevent users to access unreleased pages:
      public function hookPageViewable($event) { $page = $event->object; $viewable = $event->return; if($viewable){ // If the page would be viewable, additionally check Releasetime and User-Permission $viewable = $this->canUserSee($page); } $event->return = $viewable; } To prevent access to the files of unreleased pages, we hook into Page::isPublic and ProcessPageView::sendFile.
      public function hookPageIsPublic($e) { $page = $e->object; if($e->return && $this->isReleaseTimeSet($page)) { $e->return = false; } } The site/assets/files/ directory of pages, which isPublic() returns false, will get a '-' as prefix. This indicates ProcessWire (with activated $config->pagefileSecure) to check the file's permissions via PHP before delivering it to the client.
      The check wether a not-public file should be accessable happens in ProcessPageView::sendFile. We throw an 404 Exception if the current user must not see the file.
      public function hookProcessPageViewSendFile($e) { $page = $e->arguments[0]; if(!$this->canUserSee($page)) { throw new Wire404Exception('File not found'); } } Additionally we hook into ProcessPageEdit::buildForm to add the PageAccessReleasetime fields to each page and move them to the settings tab.
      Limitations
      In the current version, releasetime-protected pages will appear in wire('pages')->find() queries. If you want to display a list of pages, where pages could be releasetime-protected, you should double-check with $page->viewable() wether the page can be accessed. $page->viewable() returns false, if the page is not released yet.
      If you have an idea how unreleased pages can be filtered out of ProcessWire selector queries, feel free to write an issue, comment or make a pull request!
    • By David Karich
      Thanks to the great Pro module "RepeaterMatrix" I have the possibility to create complex repeater items. With it I have created a quite powerful page builder. Many different content modules, with many more possible design options. The RepeaterMatrix module supports the cloning of items, but only within the same page. Now I often have the case that very design-intensive pages and items are created. If you want to use this module on a different page (e.g. in the same design), you have to rebuild each item manually every time.
      With this proof of concept I have created a module which adds the feature to copy a repeater item to the clipboard so that you can paste this item to another page with the same repeater field. The module has been developed very rudimentarily so far. It is currently not possible to copy nested items. There is also no check of Min/Max. You can also only copy items that have the same field on different pages. And surely you can solve all this more elegantly with AJAX. But personally I lack the deeper understanding of the repeaters. Also missing on the Javascript side are event triggers for the repeaters, which would make it easier. Like e.g. RepeaterItemInitReady or similar.
      it would be great if @ryan would implement this functionality in the core of RepeaterMatrix. I think he has better ways to implement this. Or what do you think, Ryan?
      Everybody is welcome to work on this module and improve it, if it should not be integrated into the matrix core. Therefore I put it for testing and as download on GitHub: https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDublicate
      You can best see the functionality in the screencast: 
       
    • By anderson
      Hi,
      Please take a look at this:
      https://templatemag.com/demo/Good/
      The upper nav bar, including dropdowns like "pages" and "portfolios", what do you call this whole thing? At first I guess it's called "dropdown nav bar", but seems not.
      AND of course, what's the simplest way/module to achieve this in PW?
      Thanks in advance.
    • By Sebi2020
      Hey, I'm new and I created a simple module for tagging pages because I didn't found a module for it (sadly this is not a core feature). This module is licensed under the GPL3 and cames with absolutly no warranty at all. You should test the module before using it in production environments. Currently it's an alpha release. if you like the module or have ideas for improvements feel free to post a comment. Currently this fieldtype is only compatible with the Inputfield I've created to because I haven't found  an Inputfield yet, that returns arrays from a single html input.
      Greetings Sebi2020
      FieldtypeTags.zip.asc
      InputfieldTagify.zip
      InputfieldTagify.zip.asc
      FieldtypeTags.zip