Profiler support when using Slim 4

[UlrichEckhardt]

Greetings!

In the past, I have been trying to get Clockwork to allow profiling a Slim application and couldn't get it to run. Since that app uses a fork of Clockwork and is generally a bit special, I didn't bother investigating further. Anyhow, I just cobbled togethere a quick demo project and it shows the same behaviour. Note that there is also #617, but that is relatively unspecific and lacks quite some info.

Debugging through the code, I found a few things that may be involved:

• XdebugDataSource -- It looks like this needs to be registered. For Laravel (your main target framework?) this is done automatically, but not for Slim 4.
• xdebug.start_with_request=yes instead of trigger seems to make a difference, too. With it set to yes, sometimes I don't get the message that "Profile is not present for current request." in the browser, though not always. Instead, I get the message "Processing profile..." and a rotating dot, but no profile.
• Looking at the request data, I see that it contains "XDEBUG_PROFILE=; clockwork-profile=; XDEBUG_PROFILE=1" in the Cookie header, note the double XDEBUG_PROFILE there. Sometimes it's only "clockwork-profile=; XDEBUG_PROFILE=1" instead, not sure why.
• I see that in some Clockwork storage files, the profileData is set, so recording of that data works.
• A verbatim URL your.app/clockwork in the browser doesn't work. Neither does localhost:8080/clockwork. It seems like this requires some support which wasn't implemented for Slim yet.

At this point I'm a bit stumped and am looking for help here...

Uli

[itsgoingd]

Hey, I guess you've ended up figuring this out based on the other issues.

The Slim integration is definitively our weakest one. The only reason it exists is because I used to use Slim when I first started writing Clockwork. I have stopped using Slim like 10 years ago, so the integration also fell behind, only receiving minimal effort updates to support Slim 3 and 4 (which I have never used on any project myself, lol).

Honestly, at this point it might be a better idea to use our vanilla integration, which is way more up-to-date and should play nicely with Slim's PSR-compatible router.

[UlrichEckhardt]

I'd agree here, a PSR-compatible, generic implementation is better than an unnecessarily specific one. The only thing I'd do is review the documentation and perhaps to deprecate the Slimp-specific code.