Module Tracy Debugger

[Mike Rockett]

Hey Adrian,

Just started using this for Jumplinks, but not able to dump anything using any of the available methods (classes and shortcut methods not found). However, I'm using PW 2.8 for this, and I see that your module doesn't declare compatability. Should I switch over to 3.0 for this, or is there another way?

Class 'TD' not found in /var/www/jumplinks-two/public_html/site/modules/ProcessJumplinks/src/Jumplinks/Traits/HandleTrait.php

when using \TD::barDump(...).

[bernhard]

i have no problems on one 2.8.28 installation.

i always use shortcut methods like this (you have to check the "enable shortcut methods" checkbox for this

// test tracy dump anywhere in your files
bd('tracy dump working');

 

5 hours ago, Mike Rockett said:

when using \TD::barDump(...).

im not sure about this backslash... i get the same error on pw3 when using TD::... everything works when using shortcuts

[szabesz]

13 minutes ago, bernhard said:

im not sure about this backslash... i get the same error on pw3 when using TD::... everything works when using shortcuts

Same here.

[Mike Rockett]

@bernhard - Shortcuts are on (by default anyway). I use the backslash as I'm using a namespaced environment with Jumplinks. As I need to call TD's methods inside a trait, I need to refer to the root namespace.

[adrian]

Hi @Mike Rockett - firstly, the bd() and other shortcuts should be available from the global namespace, so I don't think there should be a need to call \TD:barDump() but maybe I am missing something there.

Now to that Class TD not found error - my initial thought is that maybe you are calling it from inside the init() method in your module, rather than after ready() ? Or perhaps your module is simply being auto-loaded before Tracy. 

Any chance I you could PM me a copy of jumplinks 2 so I can see if I can fix this?

 

[Mike Rockett]

As with JL1, I'm hooking a handle() method from the init() method. However, with JL2, the handle() method is in a trait. Not sure what the difference between ready() and init() is...

Oh, and I only tried the TD way as bd() wasn't working, nor was \bd().

[adrian]

So does Tracy work with JL1 in the same place?

I think it's because you are making the bd (or whatever variant) at a time before Tracy is loaded because everything is loded in ready(), not init() - this is because I need info that isn't available until ready(), but maybe there is something I can do as a workaround?

[Mike Rockett]

I haven't tried it with JL1, but I assume it won't work.

I'll send you a private copy of JL2 tomorrow some time

[adrian]

1 minute ago, Mike Rockett said:

I'll send you a private copy of JL2 tomorrow some time

Great - thanks - and please leave the bd() or TD::barDump call in the spot where you are trying to use it.

I have also just reminded Ryan about a request I made some time ago for making it possible to specify load order priority for autoload modules, which might also be relevant to what you are seeing.

[adrian]

@Mike Rockett - I decided to do some testing here and I think I have a working version for you. There was a lot of code reordering to make this work (needed to put lots into init(), so I need to test some more to make sure I haven't broken anything in the process, so won't push live just yet, but I'll PM you a copy of the version I am testing - would be great to know if it works for you too. 

[adrian]

Ok, I have tested further and can't find any problems, so I have committed those changes. You should now be able to use debug statements before page ready which should help significantly with module development.

Please let me know how this works for everyone and also if you notice any problems elsewhere in Tracy as a result of these changes.

[Robin S]

2 hours ago, adrian said:

You should now be able to use debug statements before page ready which should help significantly with module development.

Do you mean that we can debug in module init() now? That would be really cool but I just tried it with v2.8.2 and got " Call to undefined function bd()..."

[Mike Rockett]

Thanks Adrian - all is working now. I'm just wondering if you shouldn't indicate PW 2.8 compatability in the mods directory?

[adrian]

1 hour ago, Robin S said:

Do you mean that we can debug in module init() now? That would be really cool but I just tried it with v2.8.2 and got " Call to undefined function bd()..."

Mostly yes - I expect the issue you are having is due to the module you are testing being autoloaded before Tracy. I have raised an issue with Ryan to try to get the ability to specify load order priority.

However, just to be sure could you also test in the init() of some other autoload modules. It worked for the ones I tested and it sounds like it is also working for @Mike Rockett - so I do think it's a random load order issue, but would be good to confirm.

 

30 minutes ago, Mike Rockett said:

Thanks Adrian - all is working now. I'm just wondering if you shouldn't indicate PW 2.8 compatability in the mods directory?

I will do - we don't currently have a 2.8 option in the modules directory.

[Mike Rockett]

20 minutes ago, adrian said:

I will do - we don't currently have a 2.8 option in the modules directory.

I think that actually isn't a problem though, as the system doesn't mention anything about incompatiability - I mean, if it works with v3, then there's nothing I'm aware of that'll prevent it from work on v2.8. That said, it something that people would have to 'know', instead of it being specifically stated.

[tpr]

I've also got similar error loading modules in modal and using bd(). I'll report if the latest updates had solved it, though this may not be the same issue.

[tpr]

No success with modals:

Uncaught Error: Class 'Tracy\Debugger' not found in /var/www/vhosts/xxxxxxxxxx/site/modules/TracyDebugger/TracyDebugger.module:519

This happens even if I add no bd() calls at all. I guess something is not loaded in modals, perhaps there's a $config->ajax condition somewhere (in core).

I've tried a previous release (commit "Simplify setting User-Agent within Validator panel...") and the error comes up only if I use bd(), otherwise not, so seemingly only the last commits breaks it.

I'm using AdminOnSteroids to open modules in a modal.

[Robin S]

3 hours ago, adrian said:

However, just to be sure could you also test in the init() of some other autoload modules.

Of the autoload modules in my testing installation, bd() worked in 5 and failed in 7 when called from init(). Probably the random load order issue you mentioned.

[adrian]

4 hours ago, Robin S said:

Of the autoload modules in my testing installation, bd() worked in 5 and failed in 7 when called from init(). Probably the random load order issue you mentioned.

Thanks - sounds like that is probably the case - will see if Ryan can help get Tracy loaded first all the time.

 

5 hours ago, tpr said:

No success with modals:

Uncaught Error: Class 'Tracy\Debugger' not found in /var/www/vhosts/xxxxxxxxxx/site/modules/TracyDebugger/TracyDebugger.module:519

This happens even if I add no bd() calls at all. I guess something is not loaded in modals, perhaps there's a $config->ajax condition somewhere (in core).

I've tried a previous release (commit "Simplify setting User-Agent within Validator panel...") and the error comes up only if I use bd(), otherwise not, so seemingly only the last commits breaks it.

I'm using AdminOnSteroids to open modules in a modal.

Actually I intentionally prevent Tracy from loading in modals although I do see why the last commit has changed when you get that error. I can easily have it loaded for modals again though. I was disabling because I thought it was superfluous and looked ugly, but maybe it's important, especially if the modal contains an iframe - in that case having Tracy enabled would be the only way to debug the content of the iframe.

 

[adrian]

@tpr - the latest commit fixes the "Uncaught Error: Class 'Tracy\Debugger' not found" error in modals. I have also changed the behavior slightly. Tracy is now loaded in normal modals, but not inline ones. I think this is a good balance, but let me know if anyone has any strong thoughts on this. FYI - an example of an inline modal is the "Usage" section of a template settings page.

[tpr]

I think it's better this way, thanks! 

[bernhard]

On 26.8.2016 at 8:07 PM, adrian said:

Working on this module is starting to become a full time job!

related to the helpdesk topic i want to suggest that you offer the possibility to support this awesome project (module seems like an offense in that case) with donations and mention the donors somewhere in return. what do you think of that? I'm really thankful for what you built here as i learned a lot and i don't know where i would be today without all the help of tracy opening my eyes. maybe it's just me because tracy came in right in time and i've never used xdebug or the like - but i have the feeling i'm not the only one

thinking a bit about it i'm asking myself if that wouldn't be a good feature for the modules directory? offering a donation button connected to the devs paypal account and showing the donors automatically ranked by amount?

if that is getting too offtopic don't mind creating a new topic for it... my first intention was related to tracy though, so i'll leave my comment here

 

[Robin S]

4 hours ago, bernhard said:

thinking a bit about it i'm asking myself if that wouldn't be a good feature for the modules directory? offering a donation button connected to the devs paypal account and showing the donors automatically ranked by amount?

Personally I don't think the tracking and ranking of donors is necessary or desirable. I support the idea of a donate button in the modules directory (if a module developer chooses to enable that for their module) but when donations become public information then it's inevitable that people start comparing the donations between modules and it creates a "winners and losers" effect that can do harm to the non-commercial motivations that led to a developer releasing an open-source module in the first place.

Better to have donations be a private thing that can be a pleasant surprise for a module developer rather than a focus of attention.

In the short term please bring on a donate button in the Tracy config screen.

[szabesz]

6 hours ago, Robin S said:

In the short term please bring on a donate button in the Tracy config screen.

+1

[adrian]

Firstly, thanks to everyone who has suggested a Donate button - I am still thinking about this - not sure what my thoughts are yet.

Just a quick update on the ProcesswireUpgradeCheck module and the Modules Disabler panel. Ryan has fixed the problem in the latest PW core commits today, although he is still warning (https://github.com/ryancramerdesign/ProcessWire/issues/1990#issuecomment-243401979) about disabling modules. See my next comment about @tpr's approach of storing module settings when uninstalling - as I mention, I am not sure this is without problems as well.

I'd like to see a bullet-proof solution, although I am not sure there is one. At least for now, this panel should be a little safer than it was, but I am definitely keen to improve the approach used if anyone has any great ideas!