Conflict with TracyDebugger

[Notanotherdotcom]

Describe the bug

I have TracyDebugger switched on quite a lot of the time on my account.

If you change the main admin page process from ProcessHome to Dashbord, in Chrome dev console, if you wait a minute it throws this error:

Fatal Error: 	Uncaught Exception: Missing parameter: key in /site/modules/Dashboard/Dashboard.module:300

#0 /site/modules/Dashboard/Dashboard.module(234): Daun\Dashboard\Dashboard->renderInstanceByKey(NULL, NULL)
#1 /wire/core/Wire.php(414): Daun\Dashboard\Dashboard->___execute()
#2 /wire/core/WireHooks.php(951): ProcessWire\Wire->_callMethod('___execute', Array)
#3 /wire/core/Wire.php(485): ProcessWire\WireHooks->runHooks(Object(Daun\Dashboard\Dashboard), 'execute', Array)
#4 /wire/core/ProcessController.php(337): ProcessWire\Wire->__call('execute', Array)
#5 /wire/core/Wire.php(414): ProcessWire\ProcessController->___execute()
#6 /wire/core/WireHooks.php(951): ProcessWire\Wire->_callMethod('___execute', Array)
#7 /var/www/htm (line 300 of /site/modules/Dashboard/Dashboard.module)  

This error message was shown because: you are logged in as a Superuser. Error has been logged.

It doesn't matter if you have Tracy "on" or minimised in the bottom-right, if Tracy is running it throws that error after a minute or two.

I wasn't sure whether to list it as an issue with this module or on the Tracy module Github page, but I think this is the first module I've seen this sort of error with before so I've posted it here for now - I hope that's alright?

I think a "simple" fix here would be for whatever background JS call is running on the dashboard to simply not run if Tracy is running? Because in theory on a live website Tracy would be switched off.

To Reproduce
Change /admin/ to use Dashboard as its process

Context
Latest ProcessWire dev branch
TracyDebugger installed

[Notanotherdotcom]

I think a quick fix would be to wrap the $.post request in this to fix this:

if (typeof(Tracy) === 'undefined') {

As we don't need panels to reload if Tracy is running - the only reason for Tracy to be running is usually on local dev copy (where I would still be building dashboards) and on live as a final sweep for any code issues. After that it should be turned off, so I think this "fix" of disabling the panel refreshes if Tracy is detected is acceptable.

But let me know if you'd prefer me to raise this with the Tracy author instead :)

[daun]

Good catch. The issue was not verifying and executing on ajax requests that weren't directed towards the module itself. I released v1.1.1 which should solve the issue.

[adrianbj]

I was actually meaning to report the same error when using Ryan's User Activity module (which makes regular AJAX calls). I am assuming this fix will likely take care of that also?

I wonder if changing the process for the admin page is actually the best approach for making the dashboard the default view - would a simple hook to redirect to the dashboard avoid some of these potential problems?

the only reason for Tracy to be running is usually on local dev copy (where I would still be building dashboards) and on live as a final sweep for any code issues. After that it should be turned off

I don't really agree with this - Tracy logs errors with a full stack Trace (stored in the logs/tracy directory) while the site is being used - I find this very useful, along with it's emailing notifications of errors.

[daun]

I was actually meaning to report the same error when using Ryan's User Activity module (which makes regular AJAX calls). I am assuming this fix will likely take care of that also?

@adrianbj I'd think it will solve this as well, but let me know if it doesn't.

I wonder if changing the process for the admin page is actually the best approach for making the dashboard the default view - would a simple hook to redirect to the dashboard avoid some of these potential problems?

The main advantage of changing the default process is that clicking the logo will open the dashboard. All other methods I tried haven't been able to replicate that. Then again, I haven't done too much research as I haven't run into any major problems with the way it's done currently.

[Notanotherdotcom]

Thanks both.

the only reason for Tracy to be running is usually on local dev copy (where I would still be building dashboards) and on live as a final sweep for any code issues. After that it should be turned off

I don't really agree with this - Tracy logs errors with a full stack Trace (stored in the logs/tracy directory) while the site is being used - I find this very useful, along with it's emailing notifications of errors.

I should have phrased that as "the only reason for me to usually be running..." etc :)

[Notanotherdotcom]

@daun I've just had the latest version running for a few minutes and it works perfectly with /admin/ set to the Dashboard process - thank you!