SymfonyCasts stands united with the people of Ukraine
If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeGoogle for "Drupal Devel": it will lead you to a project on Drupal.org that has some nice tools in it. What we're after is the webprofiler module. Copy the installation link address so we can install it! In the future, you should be able to install modules via Composer. More on that later.
For now, click install new module, paste the URL, press the install button and wait with great anticipation! When it finishes, follow the enable newly added modules link. I'm only interested in the web profiler. Check its box and press the install button. It'll also ask me to install the devel, module which is fine. Hit continue... and watch closely.
On the very next request a really cool web debug toolbar pops up at the bottom. This is the oracle of information about the request that was just executed - in this case - a request to this admin page. It shows us tons of stuff like database queries, who is authenticated, stats about the configuration, the css and js that's being loaded, the route and controller that's being used for this page and - somewhere in there - I'm pretty sure it knows where my car keys are.
Before you go crazy with this, go back down on this page to the webprofiler. Expand it and click "Configure". Here, you can see that there's even more information that you can display if you want to. Check the boxes for Events, Routing and Services and then press the "Save configuration" button.
Ooo look: a few new things on the toolbar. If you click any icon, you'll go to a new page called the profiler. It turns out that the web debug toolbar was just a short summary of the information about the last request. The profiler has tons more.
If you want to see all of the routes, click the Routing tab. This is the same list that the Drupal console showed us.
There are lots of other treats in here: it's like a Drupal Halloween! For example, Performance Timing checks how fast the frontend of your site is rendering. The timeline is probably my favorite... and for some reason it's broken in this version. Wah wah. It normally shows you this great graph of how long it takes each part of Drupal to execute. It's great for profiling, but also great to see what all the magic layers of Drupal are.
If you follow the documentation for the webprofiler, you also need to install a couple of JavaScript libraries to help the profiler do its job. But it seems to work pretty well without them, so I skipped that part to save us time.
Now that we have this, click on the admin "Structure" page. Obviously, this page comes from Drupal. But how does it work? Go down to the toolbar and hover over the 200 status code. Ha! This tells us exactly what controller renders this page:
Drupal\System\Controller\SystemController::systemAdminMenuBlockPage()
If you see the D\s\C stuff, that stands for Drupal\System\Controller. The web profiler tries to shorten things: just Hover over this syntax to see the full class name.
If you wanted to reverse engineer this page, you could! I'll use the keyboard shortcut shift+shift to search the project for SystemController. Here's the class! Now, look around for the method systemAdminMenuBlockPage(). And this is the actual function that renders the admin "Structure" page:
| ... lines 1 - 24 | |
| class SystemController extends ControllerBase { | |
| ... lines 26 - 184 | |
| /** | |
| * Provides a single block from the administration menu as a page. | |
| */ | |
| public function systemAdminMenuBlockPage() { | |
| return $this->systemManager->getBlockContents(); | |
| } | |
| ... lines 191 - 343 | |
| } |
In fact, if you add return new Response('HI!') and refresh, it'll completely replace the page! Try this and see if your co-workers can figure out what's going on!
We don't know yet what this systemManager thing is or how to debug it, but we're going there next.
I just think it's really cool that we can see exactly what's going on in the page, dive into the core code and find out how things work.
Hey Akshit,
You can do this in a few ways, but the JS dependency will eventually be stored in the package.json file. We do it via Yarn in our tutorials, e.g. if you want to add a jQuery as a JS dependency to your project - you can execute "yarn add jquery" - then the package.json will be created - similar to composer.json that we have in PHP, and there you will find your dependency. Also, Yarn will create yarn.lock file that has the same purpose as composer.lock in PHP. So, basically, Yarn is a package manager in JS world as Composer is package manager in PHP world.
I hope this helps! If you need more info about it - I'd recommend you to watch our JS tutorials first: https://symfonycasts.com/tr... , because install a JS dependency this way isn't enough to be able to start using it, as it will not be available on frontend. You need a tool like Webpack Encore that will allow it for users. I'd strongly recommend you to watch the course about Webpack Encore first: https://symfonycasts.com/sc...
Without Webpack Encore, the only way would be to do like devs did before, just download a JS library file, put it into a public folder to which users will have access, and add a script tag that will include the lib in your HTML pages - but that's much less cool than doing it via Yarn and Webpack Encore.
I hope this helps!
Cheers!
Hi Ryan,
I'm currently experiencing an issue with Web Profiler.
I have a fresh D8 instance ( Version 8.5.4 ) with the latest version of Devel plus libraries (D3 and Highlights).
The problem is quite weird...
The Profiler bar is visible only on /admin/modules/ page and sometimes appear/disappear in other sections..
example: admin/structure, front page..
I checked browser console.. No errors :-/
Soooo weird.
Have you ever seen something like that?
Hey Fabrizio S.,
Hm, weird... Do you have HTTP cache on the pages where you do not see the web profiler? Btw, could you double check you have a valid HTML structure in the source code, i.e. you have opening/closing html and body tags? You may probably try to validate your HTML with this validator: https://validator.w3.org/ . And try to "tail -f" your logs when load the page, probably you'll find some errors in logs.
Cheers!
Hi victor
Thank you for your kind feedback.
I don't know actually if this problem is somehow correlated to the Zend Opcache extension.
I checked the list of module reported issues on https://www.drupal.org/proj... and, somehow, the "Stopwatch is incompatible with OPCache" made me ring a bell.
I made a test by disabling opcache extension on my environment, after that, going back to my drupal instance and reloading the pages... voilà, the toolbar is there!!
Still bit weird by my opinion. But it works!
Hey Fabrizio S. ,
Glad you got it working! Hm, probably a temporary issue, or you need to upgrade stopwatch / opcache to the latest version.
Thanks for sharing your solution with others!
Cheers!
// composer.json
{
"require": {
"composer/installers": "^1.0.21", // v1.0.21
"wikimedia/composer-merge-plugin": "^1.3.0" // dev-master
}
}
How to install javascript libraries?