Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi guys!
For a long time (apologies for not reporting it until now) - the webprofiler - on multiple projects and versions of Drupal 8.x - has shown 0ms with no graph for the timeline in the profiler. This seemed so obviously broken, that I assumed that it's something wrong with my setup. But, if it is, I keep making some mistake over and over again - this never works for me :/.
Attached is a screenshot of how it looks. The "time" data coming from the profiler *is* all 0.
Thanks!
Comment | File | Size | Author |
---|---|---|---|
#12 | 2721363-d3-3.patch | 510 bytes | fgm |
#10 | timeline.png | 59.92 KB | fgm |
Screen Shot 2016-05-08 at 8.10.24 PM.png | 141.44 KB | weaverryan |
Comments
Comment #2
weaverryan CreditAttribution: weaverryan as a volunteer commentedThe reason things are zero is because the profiler is *started* in the TraceableContainer. If you don't enable that, it never starts.
However, even after enabling it, I see a lot of errors - it's as if this feature just isn't working.
Can anyone confirm that - after enabling the TraceableContainer as described in the README - that they can or cannot see a working timeline in the profiler?
Comment #3
lussolucaHi Ryan,
did you add:
to settings.php?
Which kind of errors do you receive? On which version of Drupal?
Comment #4
fgm@lussoluca: with an equivalent line (different path) in settings.local.php, the duration is indeed no longer 0 (Total time 344.6 ms Initialization time 21.6 ms), but it still doesn't show the usual SF2 timeline. No error, and nothing in logs.
Comment #5
lussolucaHave you added the d3.js library to your project? Take a look at the module README.MD.
With the latest 8.x-1.x-dev and a Composer based workflow the download of d3.js is automatic.
Comment #6
fgmYes, I have added the libraries manually, the requirements no longer show either of them as missing, yes I'm using a composer-based workflow, and no, neither library is downloaded automatically.
AFAIK this only works for PHP libraries, unless specific JS-related magic. I tried adding the repos to the project-level composer.json and add a dependency, but then the downloads produced the source repositories, meaning an extra JS builder step would have been necessary.
Actually, in the meantime, I have a number of situations where the WebProfiler causes fatals, mostly because it tries to invoke WrappedListener::getSubscribedEvents(), but WrappedListener does not implement EventSubscriberInterface. This happens notably on error pages, during handling KernelEvents::TERMINATE.
Comment #7
lussolucaDid you have any javascript errors?
Feel free to open a new issue for this other problem.
Comment #8
fgmJust one JS error: "Uncaught TypeError: Cannot read property 'linear' of undefined". (multiple times).
Comment #9
lussolucaWhat is the output of
in your browser javascript console?
Comment #10
fgmSee image for details.
Comment #11
lussolucaAre you using d3.js version 4?
It seems that a lot of APIs were changed in this version.
If so, could you please try with d3.js version 3? I'll update documentation to point out that Webprofiler works only with d3.js version 3 for now.
Comment #12
fgmGood catch. I had 4.2.2. Switching to 3.5.17 did the trick. Attached is a tiny README patch for this.
Comment #14
lussolucaCommitted and pushed to 8.x-1.x
Thanks a lot!
Comment #16
lussolucaComment #17
fgmNote that this doesn't fix the fatal errors like the one below, just the lack of a timeline display when things go well otherwise. But as you said, maybe this is another issue entirely:
Comment #18
lussoluca@fgm I've opened a new issue: #2791749: Call to a member function getReasonPhrase() on null, could you please try the attached patch?
Comment #19
fgmThe error in #2791749: Call to a member function getReasonPhrase() on null no longer occurs these days on 8.3.4.
One thing I noticed, though, is that the instructions in the README are not always accurate: if settings.local.php is at the end of a symlink, the directory used in the addPsr4() call may not be correct, so it is safer to always use an absolute path, or at least make sure the path resolves correctly.