Module Tracy Debugger

[adrian]

Sorry it is proving slow for some (maybe all of you guys). Wish I was seeing the problems here so I could debug. Does anyone have a live server that is running slow that they'd be willing to give me access to so I can take a look? I'd really like to get this sorted out so no-one feels the need to have an on/off toggle.

Are any of you running xdebug? Does disabling it completely make a difference?

 

[Macrura]

Quote

 Just to clarify - you say ToDo wasn't enabled in the settings but was showing on the bar - did you fix by clicking "Reset" on the Panel Selector? If so, then it must have been enabled via the "Sticky" option at some point.

I guess i might have done the sticky thing, but i assumed that meant it would show up in the selected panels in the module settings;

If that's not the case, then it would be hard to 'undo' a scenario where an enabled panel under sticky mode was causing epic page loads, how would you get to the frontend panel to turn it off?

Quote

now that you have excluded those directories, I'd love to hear if you find the ToDo panel useful - it has definitely made me start using the 'todo', 'fixme', 'pending', 'xxx', 'hack', 'bug' tags in my code more often now that I have a simple way to keep track of them on a page/template basis when viewing the site.

i probably will use it only in the regular template files, it will definitely come in handy - many thanks!

[adrian]

5 minutes ago, Macrura said:

I guess i might have done the sticky thing, but i assumed that meant it would show up in the selected panels in the module settings;

That's not the behavior - sticky changes to the panels are stored in a session cookie. Maybe that is confusing, but it was designed to be a way to have panels display temporarily, but for more than one page reload.

 

8 minutes ago, Macrura said:

If that's not the case, then it would be hard to 'undo' a scenario where an enabled panel under sticky mode was causing epic page loads, how would you get to the frontend panel to turn it off?

Maybe what I need to do is have saving the module config settings clear that session cookie (same as clicking "reset" in the selector panel on the frontend) - that seems like a logical solution to me - I'll implement that now.

 

10 minutes ago, Macrura said:

i probably will use it only in the regular template files, it will definitely come in handy - many thanks!

No problem - let me know if there are any changes that would help with your use case.

[adrian]

@Macrura - just to follow up, I have committed that change - now when you save the module config settings in the backend, the list of panels is reset to the permanent list in those config settings - ie, the Sticky list of panels is Reset.

Hope that helps to avoid confusion / problems for others also.

 

[tpr]

I can also feel a little slowdown but it's not critical. I use a maximum of 1-2 panels, and PHP 7. There was a server with PHP 5.4 and I remember Tracy performed much poorer, so perhaps it's the PHP version?

[tpr]

Sorry it's me again

I can't get ToDos work in module files, does it work for you?

Update: it seems Tracy is looking only inside the site/templates dir so there's no chance for module comments to appear. Is this by design? If so, there's no need to list "module" in the allowed extenstions.

Another thing I noticed is that there's an error if you empty the ignore dir list for ToDos, this should be easy to fix.

[tpr]

A quick idea (feature request): mail panel. 

Here is a topic @ Nette forums where are links for the Mail panel and 3rd party solutions.

https://forum.nette.org/en/22057-native-support-of-debug-mail-panel-for-nette-mail-in-nette

https://github.com/nextras/mail-panel

https://mailcatcher.me/

Such a panel would be handy to see emails without jumping back and forth between the email and the browser.

Or do you think it would deserve an own module? 

[adrian]

10 hours ago, tpr said:

Sorry it's me again

Don't apologize - feedback is what I need

 

10 hours ago, tpr said:

I can't get ToDos work in module files, does it work for you?

Update: it seems Tracy is looking only inside the site/templates dir so there's no chance for module comments to appear. Is this by design? If so, there's no need to list "module" in the allowed extenstions.

Another thing I noticed is that there's an error if you empty the ignore dir list for ToDos, this should be easy to fix.

Yeah, good point about modules - I think it makes sense to have the option to scan the modules directory too - I don't recommend this for most users as it can slow things down a bit, but the latest version now includes a config settings checkbox to allow this if you want. I also fixed the error if you empty the ignore dir list as well as improving some other elements of comment parsing.

 

[adrian]

14 minutes ago, tpr said:

Such a panel would be handy to see emails without jumping back and forth between the email and the browser.

Or do you think it would deserve an own module? 

I guess I am a little confused about the purpose - the https://github.com/nextras/mail-panel seems to capture outgoing messages sent from the server, but https://mailcatcher.me/ seems to display messages sent to a particular email address in a web interface. What functionality are you actually looking for? Maybe if I know more I'll have a better idea about whether I think it should be in Tracy or not.

[tpr]

Thanks for the include modules checkbox, now I' busy adding exclusions

Another notice: how about using simple Inputfield instead textarea for ToDo ignore dirs and allowed extensions? The textarea seems too large for me. Or maybe setting their rows to 2, that would be probably suffice.

My idea for a mail panel is that when testing forms, the outgoing emails would be intercepted and its details (subject, from/to address, contents, etc) would be shown. So very similar to the nette mail panel addon. The obvious benefit of having it inside Tracy is that it could be shown in a panel. I often end up deleting tens of emails and saved pages of form submissions (though BCE is of great help). Of course it can be that it's only me and others have better luck setting up their forms

[bernhard]

55 minutes ago, tpr said:

now I' busy adding exclusions

adrian, what do you think about adding a regex field so that everybody can decide on its own what to exclude? i would leave the textarea (or textfield) for easy exclusion as they are but before adding lots of custom options (also scan site modules, also scan this, also scan that...) a simple regex would be more versatile. and every module developer should be familiar with regex

55 minutes ago, tpr said:

My idea for a mail panel is that when testing forms, the outgoing emails would be intercepted and its details (subject, from/to address, contents, etc) would be shown. So very similar to the nette mail panel addon. The obvious benefit of having it inside Tracy is that it could be shown in a panel. I often end up deleting tens of emails and saved pages of form submissions (though BCE is of great help). Of course it can be that it's only me and others have better luck setting up their forms

i'm using vagrant together with mailcatcher so i thought i have no need for this. but sometimes i make little changes on live sites and there such a feature could come in handy... sometimes clients want me to do little changes to some of their forms. right now i do such changes live and just do a test submit. that submit triggers a regular mail to the client. it would definitively be better to save the client from receiving some "testbooking xyz" mails

so on a second glance i would support thinking about such a feature. this would be similar to the concept of switching templates, if i understand it right, @tpr?

edit: how can i mention someone in my post like @tpr?

[tpr]

It's just simply the "@" character plus the name, I guess

Yes, catching test emails not to reach the customer is a good point. I often solve it adding an if-else condition to set the dev email if logged in as superuser, but it's not that professional.

I guess getting email details from WireMail shouldn't be hard. My bigger concern is how to show details for ajax submitted emails - I know Tracy is capable, but they are shown only after page reload, right? So it won't be "live".

[adrian]

1 hour ago, tpr said:

Another notice: how about using simple Inputfield instead textarea for ToDo ignore dirs and allowed extensions? The textarea seems too large for me. Or maybe setting their rows to 2, that would be probably suffice.

Done!

 

1 hour ago, tpr said:

My idea for a mail panel is that when testing forms, the outgoing emails would be intercepted and its details (subject, from/to address, contents, etc) would be shown. So very similar to the nette mail panel addon. The obvious benefit of having it inside Tracy is that it could be shown in a panel. I often end up deleting tens of emails and saved pages of form submissions (though BCE is of great help). Of course it can be that it's only me and others have better luck setting up their forms

Makes sense - let me take a better look at that existing panel. Unfortunately most of the existing Tracy plugin panels require the entire Nette framework, so it is unlikely I will be able to use that one directly. I initially started with someone else's ToDo panel, but even after I had stripped out all the requirements for other Nette components, I still didn't like the way it was parsing out comments, so I ended up writing a new one from scratch

 

21 minutes ago, bernhard said:

a simple regex would be more versatile

I guess I am not totally sure how this would help. At the moment by default, it only scans files inside /site/templates. With that new checkbox, you can now expand this to include /site/modules, but I doubt many will want to add this option. I am think most will want to scan all of /site/templates, but simply exclude some parent folder like /site/templates/scripts/libraries/ where they would add all third party js libraries. Can you explain what folders you might want to exclude that a regex could help with - that would help me better understand how to implement.

 

2 minutes ago, tpr said:

My bigger concern is how to show details for ajax submitted emails - I know Tracy is capable, but they are shown only after page reload, right? So it won't be "live".

I am not totally sure on this either - you'll notice when you have Tracy enabled in the backend, there is an additional bar that shows up when the admin makes ajax calls (like for getting menu subitems), so theoretically I could have an "email" panel also show on the ajax bar - currently I disable all of the custom panel (except performance) from appearing on the ajax panel, but I can make an exception for an email one.

 

1 hour ago, tpr said:

My idea for a mail panel is that when testing forms, the outgoing emails would be intercepted

I am guessing this shouldn't be too hard - just need to hook into wireMail.

Perhaps you guys ( @tpr and @bernhard ) could come up with a list of required features?

[tpr]

Thanks! Inputfields instead textareas is a great relief

Features for a mail panel - I will try to think about it but at first I would only need to see what values would be sent, nothing else. And a big button for toggling it on/off

[adrian]

8 minutes ago, tpr said:

And a big button for toggling it on/off

Is that necessary - surely it would only capture sent emails when you are logged and Tracy is in Development mode (or forced development for superusers)?

Maybe I am missing your point though

[tpr]

Without the big button I would need to switch user to test how the email lands in my inbox  Sometimes it's necessary, eg. in case of newsletters.

But I can live with the user switch solution, or perhaps toggling it in the panel selector.

[adrian]

44 minutes ago, tpr said:

perhaps toggling it in the panel selector

I feel like this would be the most consistent solution - it sounds like a panel you won't need most of the time, so just activate for when you need it.

I'll definitely add this to my list - the more I think about it, the more I am realizing how useful it will be.

[adrian]

Hey @tpr and anyone else interested in the Mail panel. I have the first version up and running locally, but thought I would post a screenshot first to get some initial feedback before committing the code. 

Features:

1. If the Mail Panel is enabled, it will intercept any outgoing emails - they won't be sent out, but instead, displayed in the panel.
2. Each email sent gets its own entry which is great if you have one sent to the user and one back to the admin (or similar).
3. You can toggle the body in text, html, and html source versions.

Any initial thoughts on the layout or functionality?

[tpr]

Just what the doctor ordered!  

I'm sure I'll have some cosmetic requests but at first seems very nice.

[bernhard]

great! no need (and time) for testing, but i will definitifely do that asap

[adrian]

Ok, the Mail Panel is now available!

I have also added a new related panel called "Event Interceptor" that let's you define any Hook that you want to intercept. Much like the Mail panel, this new panel prevents the chosen hook from being executed, but instead, returns that contents of $event->object and $event->arguments in the panel instead. This may be useful for debugging all sorts of things, but my primary motivation for adding this is to prevent pages from being created when testing form submissions, by using Pages::save.

Both of these panels (unlike most of the other custom ones - because there is no point, not because it's not possible) also work via AJAX calls - note that both their icons appear in the AJAX bar in the screenshot below. 

Note that the Mail panel will be active and intercept emails sent while it is enabled. The Event Interceptor will only work if there is a hook entered and "Set Hook" is clicked. To clear it, click "Remove Hook". Hooks need to be entered like so:

Pages::save

Both of these panels should be considered alpha at this stage, so please don't use on a live site just yet.

 

 

Mail Panel icon colors:

Green - no emails intercepted
Red - at least one email intercepted

Event Interceptor icon colors:

Green - no hook set
Orange - hook set, but nothing intercepted
Red - hook set and event intercepted

 

As I mentioned above, please consider these two panel alpha at this point, so please test carefully and give me your feedback - I expect the functionality of these to possibly change significantly based on everyone's ideas.

[tpr]

Looks nice, thanks!

I have a problem here, no emails are catched. I use WireMail and while there is no emails sent, the panel is not showing anything. 

I have an unusual setup for forms, using my own module and Nette Forms, plus using vanilla JavaScript instead jQuery. However, I can switch on/off ajax submit, but in neither modes show anything in the panel. I don't even get the second ajax bar below the default. Detecting ajax was an issue before ($config->ajax didn't work), but setting 'X-Requested-With' in JS solved this.

In no-ajax mode there is a redirect going on, maybe that's why there's no catch?

When I disable the Mail panel emails are sent right. I also removed all other panels just to make sure.

I guess I'll need to let you my PW install to check things, let me know if you need this.

As for the Interceptor do I need to trigger Pages::save manually just to make it work? In my module I don't have such hook by default.

[adrian]

Quote

I guess I'll need to let you my PW install to check things, let me know if you need this.

Sounds like that might be the easiest option - thanks. I am not sure what is going on for you - the hook is on WireMail::send (https://github.com/adrianbj/TracyDebugger/blob/master/TracyDebugger.module#L273) so it should work. I am sure if I can have access I'll be able to figure it out.

 

5 minutes ago, tpr said:

As for the Interceptor do I need to trigger Pages::save manually just to make it work? In my module I don't have such hook by default.

Nope - the panel adds a before hook to whatever you specify, so if you type in Pages::save, it will hook whenever a page is saved (via the admin or API - I have tested both successfully), prevent it from being saved, and simply return the event to the panel so you can view what it would have done. Please try this out with your form and let me know how it goes. 

[adrian]

9 minutes ago, tpr said:

In no-ajax mode there is a redirect going on, maybe that's why there's no catch?

There might be something to this - I actually hook into session::redirect for the Event Interceptor panel for situations like this - looks like I might need it for the Mail panel as well.

 

10 minutes ago, tpr said:

but setting 'X-Requested-With' in JS solved this.

Yeah, that makes sense - if you're not using jQuery, you will need to manually set this or the Tracy AJAX panel won't be triggered - nothing I can do about this unfortunately, short of storing the emails in a cache so that they are available after a page refresh, but I think the AJAX bar is a nicer solution for the most part.

[tpr]

Thanks. I think there should be something extra to be added to the Ajax request to be catched by Tracy.

What if someone tries to intercept WieMail::send? Wouldn't it replace the Mail panel's functionality?