Module Tracy Debugger

[tpr]

Ok, made some progress:

MailPanel.inc: foreach'es in formatEmailAddress and formatAttachments methods suppose that arguments passed are array but that's not always the case so the Mail panel shows an error. Converting them always to arrays solves this:

if(!is_array($addresses)) {
	$addresses = array($addresses);
}

Intercepting Pages::save work in non-ajax mode, however, there's a blank screen after submission, is that normal?

Edit:

removing Pages::save makes the Mail panel disfunctional. I guess the info is lost in redirect then because when intercepting the redirect doesn't happen.

[tpr]

@adrian I sent you a PM with some additional details about these new panels.

[adrian]

I have committed some significant updates to the Mail and Event Interceptor panels over the last couple of days. Both now store the data they have captured in a session variable so new items captured will be added to the list in the panel. This also removes the need prevent redirects in the code just to see the data. @tpr has been a great help in debugging several things - thank you!

I think the Mail panel is now working very reliably and should prove a great help in testing/debugging form emails and the like.

The Event Interceptor appears to be working fine, but I have noticed that it can be quite destructive if you're not careful - one example I noticed when I had the Pages::save hook setup in the admin was that some pages ended up having the trashed status, but their parent was still listed as "1" (ie the home page). I still like the power this panel offers - especially when you want to prevent the creation of new pages when submitting test forms, but I am wondering whether it should be limited to front-end API actions only (to reduce possible damage), or whether it might be useful to have a "Capture Only" option which means that it won't prevent the event, but will simply capture the object and arguments to display in the panel. I need to think through this a little more, but would also really appreciate any thoughts from those of you who have tried it out.

[adrian]

Another nice little (but hopefully useful) addition for you guys!

This is not a panel, but it is in the same vane as the Template Path and Template Editor panels. This makes it really easy to show authorized users development versions of template files.

To make this work, all you need to do is enable the checkbox. Then setup either a "template-dev" role or permission and assign that to the required users.

Obviously this is not the best approach for major changes (you should set up a dev subdomain for that), but I think it could be quite handy for certain site changes.

While you should keep track of any roles/permissions you have assigned, you can quickly disable this functionality by unchecking the enable option, or by deleting the template files (because if the dev version isn't available, it will fallback to the default one).

Let me know what you think - I am happy to modify how this works if anyone has any suggestions.

PS - yes I know you don't need a module to do this - a couple of lines in your ready.php file would also take care of it, but for some users I think this is simpler and easier to manage.

PPS If you decide to go the route of using a permission (rather than a role), then you might find this type of selector on the Users page useful so you can see which users have the "template-****" permission.

[adrian]

Update to the User Dev Template functionality - it is now tied into the Template Path panel so that you can have an easy visual indicator to alert you when any user is being served an alternate template.

Before I explain further, the one breaking change from yesterday is that the system now only checks for "template-****" permissions and not roles. If you want to assign to a single user, then create a new "template-****" role and give it the "template-****" permission.

In this screenshot, you can see the reminder detailing why the icon is orange. Currently we are not viewing a page with an alternate template, but it is letting us know that:

• the "User Dev Template" option is enabled in module settings
• the "template-dev" permission exists
• the permission has been assigned to at least one user
• there are template files with a "-dev" suffix

So if this is expected then great, but if not, then you can prevent the alternate templates from being rendered by doing one or more of the following:

• disabling the "User Dev Template" option
• removing the template-dev permission from the system
• remove the template-dev permission from all roles
• delete alternate template files with the "-dev" suffix

 

If you are on a page that is using an alternate template due to user permissions, then you will see the PW permission cog icon:

 

I hope this visual indicator will make this functionality easier for you to manage.

[Zeka]

Hi.

Thanks for module.

After upgrading to 2.3.9 on PW 3.0.25 when debugger enabled for backend i get blank page on every page submit / save, even when i try to refresh modules.

 

Also admin login and 'site.dev/admin' - blank.

Got notice 

PHP Notice: A session had already been started - ignoring session_start() in ...\TracyDebugger\tracy-legacy\src\Tracy\Bar.php:59

Any suggestions? 

Zeka

[Macrura]

I have the same issue as @Zeka - i can't use T on backend, because of the white screens... haven't had time to figure out the issue...

[adrian]

Sorry @Zeka and @Macrura - I can confirm the issue when using the Legacy version of the Tracy core. I am not at my computer right now, but I'll take a look in the morning. If you are running PHP >=5.4.4 you should be running the Master version of the core, which I can confirm is working just fine.

Sorry that I haven't been thoroughly testing the Legacy version with recent updates.

PS What version of Tracy did you both upgrade from? I can't imagine it was from 2.3.8 - it would be great to know the last version you had that was working - thanks!

[adrian]

@Zeka and @Macrura - please try v2.4.0 - it should now work fine with the legacy version of the Tracy core selected. 

Of course I would still recommend switching to Master if you are running PHP >=5.4.4

[Zeka]

Hi.

It was 1.7.7 

Now it works without issue about blank page, but notice still present.

[adrian]

7 hours ago, Zeka said:

Hi.

It was 1.7.7 

Now it works without issue about blank page, but notice still present.

Glad to hear it's working.

As for that notice - you must have "Force Scream" mode checked in the config settings. It is expected behavior to see that notice because force scream disables PHP's silence/shutup operator: @ which is used on that line in Tracy to start the session. Personally I think they should check for the session first, rather than using @, but since the legacy version supports versions of PHP before session_status() was introduced, I guess maybe it's an acceptable alternative to the old if(session_id() == '') check.

Either way, I would recommend turning off Force Stream unless you need it's functionality for a specific debug task. Otherwise you'll need to live with that notice. I could hack the core of the legacy version to remove it, but IIRC there are other uses of @ in the code so it won't be the only thing that needs fixing.

[adrian]

For those of you experiencing slow page load times with Tracy enabled, I have some thoughts on this thanks to @Robin S setting up a demo site for me to play with.

The two key panels that seem to slow things down are the Validator and Diagnostics panels.

With all panels (except Diagnostics and Validator), load time are only about 1 second more than with Tracy completely disabled. If I enable those, then load times go up an extra 3 seconds (Validator is taking 2 seconds and Diagnostics 1 second). 

There is nothing I can do about speeding up the Validator because it requires a round trip to the validator website. Note that for me here in Canada, I find that Validator only takes 0.5 to 1 second, so I don't know how much it has to do with location. It will also be affected by how big the DOM is on the page being validated. So my recommendation is to leave that disabled by default and just turn it on in the Selector Panel when required.

Same goes for the Diagnostics panel - I may be able to improve the speed of this one (in particular the reporting of file permissions takes a while), but for now I would recommend leaving it disabled by default.

So I would love to hear from those having page load speed issues whether disabling Validator and Diagnostics makes a significant difference or not - it certainly does in my testing in certain situations.

In case anyone is interested, this is my default panel selection and order:

which results in this:

and this load time:

On the same page with Tracy disabled, this is the load time:

I am certainly willing to sacrifice the extra half second or so.

The other thing to notice about these are the MB/KB transferred numbers. The main panels in this regard is the PW Info panel - there are lots of PW objects sent to that. The other one that is potentially large is the Variables panel - if you set PW objects to your own variables, this can also become very large.

Also, don't forget to check out the load times of the various panels in the Panel Selector to help you figure out your personal trade-off between load times and default functionality. And of course don't forget about the "Once" and "Sticky" options for enabling a panel just when you need it (like I have done here so you can see all my load times).

Hope that helps, but also please let me know if you guys are having different experiences with certain panels being significantly slower than what you are seeing in my times.

 

[szabesz]

@adrian I always keep Validator and Diagnostics panels off, for the reasons you described. Actually, I only have 7 panels on, and use the very handy "sticky panel" feature when something else is needed. With this setup of mine, I always get something under 500ms execution time, with the overall page reload between 1 and 2 seconds (PHP 5.6.x). And this is on my local machine without any cache whatsoever.

[adrian]

Back again

I have been playing around more with figuring out speed and as well as the panel generation time, it's also important to consider the size of the DOM for each panel (as I mentioned briefly in the last post).

To that end, the Selector Panel now also shows the size of each panel in bytes/KB:

 

I decided to remove the Page, Field, and Template objects from the PW Info panel which in my example has taken it from 500KB down to 70KB! I figure most of you don't need to see these often and you can easily output via fl(), d(), or bd() anyway when you do need them.

As I mentioned, the Variables panel can also be very large in size (see mine above at 957KB) if you have many PW objects assigned to your own custom variables, so if this panel is large for you, I would recommend leaving it off by default.

Anyway, hopefully the cleanup of the PW Info panel and the new panel size info will help you all to have much faster page loads when running Tracy.

[tpr]

I think making those size/ms infos very light gray could improve readability. Perhaps something like #999 text color.

[szabesz]

5 hours ago, adrian said:

I decided to remove the Page, Field, and Template objects from the PW Info panel which in my example has taken it from 500KB down to 70KB! I figure most of you don't need to see these often and you can easily output via fl(), d(), or bd() anyway when you do need them.

 Actually, I did liked/used them. It is a lot faster to just click without typing first. In my case the total execution time is the same, so I lost functionality, gained nothing. Can you please provide another setting to optionally turn it off? I'm thinking of beginners here. They also need these, while pros might not.

[adrian]

8 hours ago, tpr said:

I think making those size/ms infos very light gray could improve readability. Perhaps something like #999 text color.

Thanks again my style guru  - that is definitely an improvement - it was looking pretty messy and hard to read the panel names.

 

8 hours ago, szabesz said:

 Actually, I did liked/used them. It is a lot faster to just click without typing first. In my case the total execution time is the same, so I lost functionality, gained nothing. Can you please provide another setting to optionally turn it off? I'm thinking of beginners here. They also need these, while pros might not.

Sorry about that! I'll look into making it configurable. I actually think it is time to split the config settings into collapsed fieldsets - it's becoming a bit unwieldy, so I will do this which will also make it easier to add some more panel-specific config options which I think will also be useful.

[adrian]

Hi everyone,

I just committed a fairly significant update to the config settings allowing you to have much finer control over the content of many of the panels. I have initially focused on those panels that can have high performance hits: ProcessWire Info, Variables, & Diagnostics, so be sure to check out the options in those new sections. I have set the defaults for best performance so in general I would recommend leaving as is.

Please let me know if those of you experiencing slow load times find that these new changes improve the speed.

 

 

@szabesz - you know have the option to turn the Page, Template, & Field Objects back on in the PW Info Panel.

I have also done an overhaul on the Variables panel - now by default it expands all variables set to PW Objects into arrays of values, using PW's getArray(). Not only is this a huge byte saving (in my test example from 950KB down to 17KB), but it is also much nicer to read. If you need the full object output back, it is a config option.

The Diagnostics panel now by default only shows the Folder permissions. The File permissions and MySQL settings are disabled. You may want to change this if you generally have this panel disabled anyway and only temporarily enable it now and then. But at least now the new default setup loads very quickly if you do happen to want it enabled all the time.

Please let me know if you have any problems with this new version or if you have any ideas for other config settings you'd like to have.

[tpr]

I like the idea of grouping/categorizing items but I'm afraid this is a usability step backwards. Now it takes much more time to find a setting, and even if you find it, on save the sections collapses so you need to find it again.

I would suggest adding a hidden field to store section open states and update its value with JS, and on page load restore them. This setting could also be saved to local storage, I guess you got the idea. I see that such quantity of setting is hard to handle, perhaps this could improve it.

Plus how about adding " float: right" to those KB/ms items? Maybe "margin-right: -12px" could be also beneficial, and I'm not sure the parenthesis are really required

 

[adrian]

50 minutes ago, tpr said:

I like the idea of grouping/categorizing items but I'm afraid this is a usability step backwards.

Fair enough - I don't honestly change the settings very often at all so I didn't think it was a big deal. I don't honestly think it's worth hacking on something to remember the state of a fieldset after saving (although I do think it would be a nice core addition). For the moment I have set all fieldsets/sections to be open by default. I think just having the fieldsets defined really helps to categorize the settings anyway.

I have made those tweaks the s/KB items - thanks.

I have also just added a couple of other new things that continue to improve page load speed.

• Debug panel now by default respects the $config->debugTools setting. You can configure this to show all regardless of the setting if you wish. This has the potential to speed this panel up significantly if you don't display all the tools.
   
• Button to "Delete Logs" on the the Tracy Logs panel. This panel can start getting quite slow if you send lots of PW objects to the log files, so this provides a quick/easy way to delete them all and get the panel running fast again.

With the changes from the last couple of days, using the defaults that are set when installing Tracy, I am seeing a less than a 100ms increase in page load time with vs without Tracy enabled.

I am pretty happy that it's now running really fast and shouldn't be noticeable. If anyone is still having significant slowdows, please try it without SessionHandlerDB installed and also completely disable xdebug and let me know if that makes a difference - thanks!

[bernhard]

hi adrian,

+1 for having the fieldsets open

i'm still having the slow loading problem, though:

my setup:

• local vagrantbox (connected to web)
• custom host, not online: example.dev
• tracy 2.4.6
• pw 3.0.24

LEGACY

• 3.17s for ?id=1250
• all others fast
• overall 3.84s

MASTER

• 3.03 for ?id=1250
• 3 more slow files:
  
• overall 5.77s

OFF

• 1.31s for ?id=1250
• all others fast
• overall 1.95s

on my live server i don't have those problems and the whole pageload is a lot faster. nevertheless tracy is slowing down every pageload from 2 to almost 6 seconds so i can't leave it turned on...

don't know if that informations are helpful - i don't want to steal your time and even when i have to switch tracy on/off it speeds up my development so once more thank you for that great tool!

edit: just tried it with sessionhandlerDB ON... no difference

[adrian]

@bernhard - thanks for those details - is there any chance I could get access to that live server? There is obviously something similar between your local dev and the live server if both are getting slowdowns like that.

These are the times I am seeing for those tracy files so there has to be something weird and presumably fixable.

[bernhard]

sorry adrian, i was unclear. i meant that the live server loads a LOT faster! i don't have the problem there.

i bet it has something to do with my vagrant setup and maybe some virtual network timings... although it is weird that tracy slows it down so much...

[adrian]

Just now, bernhard said:

sorry adrian, i was unclear. i meant that the live server loads a LOT faster! i don't have the problem there.

i bet it has something to do with my vagrant setup and maybe some virtual network timings... although it is weird that tracy slows it down so much...

Sorry, I read this:

17 minutes ago, bernhard said:

on my live server i don't have those problems and the whole pageload is a lot faster. nevertheless tracy is slowing down every pageload from 2 to almost 6 seconds so i can't leave it turned on...

and assumed that even though the page load is faster, Tracy is still making the page load around 6 seconds.

So am I right in assuming that on the live server you can actually leave Tracy turned on?

So a quick question for you - on your local dev setup, what are the page load times for the same page:

1. with Tracy completely uninstalled
2. Tracy installed, but with the "enabled" checkbox unchecked
3. Tracy installed and enabled, but with no additional panels enabled
4. Installed, enabled and with the default set of panels
5. Installed, enabled and with all panels enabled

Can you also post a screenshot of the Panel Selector when all panels are enabled so I can see those s/kb values?

Thanks again!

[bernhard]

18 minutes ago, adrian said:

Sorry, I read this:

40 minutes ago, bernhard said:

on my live server i don't have those problems and the whole pageload is a lot faster. nevertheless tracy is slowing down every pageload from 2 to almost 6 seconds so i can't leave it turned on...

and assumed that even though the page load is faster, Tracy is still making the page load around 6 seconds.

yep, sorry... it's late here  on the second part of the sentence i was talking about dev...

18 minutes ago, adrian said:

• with Tracy completely uninstalled
• Tracy installed, but with the "enabled" checkbox unchecked
• Tracy installed and enabled, but with no additional panels enabled
• Installed, enabled and with the default set of panels
• Installed, enabled and with all panels enabled

• uninstalled
  
• installed, off
  
• installed, all panels off
  
• installed, default set
  
• installed, all panels on
  

 

i'm measuring the page /admin/page/ so of course i had to turn tracy on for the backend.

enough for today  

ps: