[SOLVED] Tracy Debugger newest version 4.26.42 - PHP Console does not work anymore

[nurkka]

Here is a quick report regarding one of the newest versions. I tested 4.26.42.
In this version, the PHP console doesn't work anymore: The output window only shows "0:".

Tested on two different hosting providers with three different PW installations.

Downgrading to Tracy Debugger 4.26.26 fixes the problem.

[adrian]

Hi @nurkka- sorry you're having issues. Can you please try if a modules refresh fixes things? 

[nurkka]

Thanks @adrian , refreshing the modules did not change anything, but I could narrow the issue down a little bit, because it just occurs on websites of the same "type" I was making. I.e. they are using the same set of modules and a lot of the same template code. I think I will now search in my template code first ...

[adrian]

Interesting - does the console panel work when you using it from the PW admin, rather than the frontend of the site?

If you can't figure out the issue, perhaps a trial and error approach of going through the Tracy versions to see where the issue starts occurring might be the quickest in the end. Choose a version in the middle between the current, ie  4.26.34 and if that works, split the difference between it and .42 but if it doesn't, go for .30 - you get the idea and hopefully it won't take long to figure out which one breaks things.

[nurkka]

I tested all TracyDebugger versions back to 4.26.26 and the issue starts with version 4.26.27. It is the following line in /panels/ConsolePanel.php:

# /panels/ConsolePanel.php line 406
xmlhttp.open("POST", "/", true);

When I change the line to it's previous version, it works for me:

xmlhttp.open("POST", "./", true);

Could that be some hosting specific issue?
Could it be triggered by .htaccess rules?

Okay, I deleted my ready.php and it works too, so it's likely a correlation with some crazy redirect stuff I am using. I'll test that ...

Edit: Yes, my redirect code in ready.php caused the error. Thanks for your help @adrian – and thanks again for the great TracyDebugger module. I couldn't imagine to ever work without it again!

[adrian]

Hi @nurkka - thanks for narrowing it down. The current version uses: $config->urls->root which in most cases should return "/" but it was changed from "./" to fix this: https://github.com/adrianbj/TracyDebugger/issues/96.

I am curious what crazy redirect stuff you have in ready.php that works with "./" but not "/" though. Can you figure out something I can change it to to work with the redirects you have?

[nurkka]

I am using ProcessWire as CMS for a shop system. I wanted to prevent ProcessWire-URLs from getting called directly, so I redirected all requests, which were not from the shop system, to the start page of the shop. That includes also POST-requests. Now, I restricted the redirects to GET requests only, and that works also with the newer TracyDebugger versions.

Also, I have a condition which checks if the request goes to the frontend or to the backend. I think a request to "./" is to the backend and therefore it worked, but now "/" goes to the frontend, which is redirected in any case.

[gebeer]

On 11/20/2024 at 5:08 AM, nurkka said:

/panels/ConsolePanel.php:

# /panels/ConsolePanel.php line 406
xmlhttp.open("POST", "/", true);

When I change the line to it's previous version, it works for me:

xmlhttp.open("POST", "./", true);

 

We were experiencing a similar issues because the POST request now goes to / root instead of the current page loaded like before with ./
In our case the console result frame would load the homepage of the frontend instead of the actual results.

I solved it for our case (a hook to PageView::execute on /) by returning if it is a tracy request

$wire->addHookBefore("ProcessPageView::execute", function (HookEvent $event) {

	// do not redirect if tracy request
	if(isset($_POST['tracyConsole']) && $_POST['tracyConsole'] == 1) return;
	// alternative
	// if (isset($_SERVER['HTTP_X_TRACY_AJAX']) && $_SERVER['HTTP_X_TRACY_AJAX']) return;

	if ($_SERVER['REQUEST_URI'] === '/') {
      ...
      session()->redirect("{$lang}{$marketName}");
    }

We need that redirect to determine language and market based on a request to GeoApify API.

I think that others might potentially run into this as well. So if the change of xmlhttp.open("POST", "./", true); to root / is not strictly necessary for Tracy to work, it might be better to revert that? @adrian   

[adrian]

Hi @gebeer - please try the latest version. I have modified to use $_SERVER['REQUEST_URI'] which I hope should solve things when you guys have these unusual redirects in place and well as @Jonathan Lahijani's issue from here: https://github.com/adrianbj/TracyDebugger/issues/96

Please let me know if you can now work without that modification to your hook.

[gebeer]

3 hours ago, adrian said:

Hi @gebeer - please try the latest version. I have modified to use $_SERVER['REQUEST_URI'] which I hope should solve things when you guys have these unusual redirects in place and well as @Jonathan Lahijani's issue from here: https://github.com/adrianbj/TracyDebugger/issues/96

Please let me know if you can now work without that modification to your hook.

Thank you very much for the fix. I can confirm that Tracy s now working without the modification.

I think, for larger corporate sites redirects that route from root to a specific language/market URI are not that unusual. So it is great that you made things work for those use cases.