 Dobro vse, da je, da se predeljezaj, da se izgledaj na konferenci, z njim, je ta je vse, da se predeljezaj. Zdaj značo. Značo, da se predeljezaj, da se predeljezaj, tako da je Drupal izvaj je z nekaj boljših, z njimi oččel. Z Nluka, v Italiji, z Nluka, v drupalj kompani, ki je tudi spar fabrik, ki je basila v Milani, v Nitali, in ki smo vse predstavili, nekaj. Zelo sem zelo vse modulje za Drupal in Drupal 6. Zelo je web profiler, monolog in nekaj nekaj nekaj, ki je vse vse vse vse vse vse vse vse vse vse. If you want to contact me, I'm Lusso Luca everywhere, so it's easy. Okay, just a couple of time on this slide. Sparfabrik is a tech company. We are engineers, developers and designers. Our main topics are cloud-native deployment, deployments, Drupal development and native developments, React, Angular and so on. And we are committed to open source. We work only with open source tools and technologies. So we are here to contribute something to you. Okay, so basically, let's start. You may know that all pages in Drupal are built in the same way. Okay, so someone sent you a request and the response is produced and returned to the browser. Everything in Drupal follow exactly the same pattern. So in this session, I'll try to explain you how Drupal turns an HTTP request to an HTML response basically. Okay, maybe it's magic. Okay, so let's say we receive this get HTTP request for a path in our Drupal website, some magic happens and then we receive some response back. How this is possible? Okay. In this presentation, we are using this example. This is a custom model I wrote just for this presentation. You cannot find it anywhere, but if you want, you can commit it somewhere. If you want to try it, it's the most useful model in the world because it displays weather information. For this model provides a custom page. This is not the output of a node provided by the node system of Drupal. This is because the node system is too complex to be analyzed in this short time. So I create a custom entity that it's called city. Okay. This custom entity used to store the description of the city. Some geographic coordinates. And on this page, we retrieve the city. We call some external services to collect weather and forecast information. Then we build the output of this page. So we are looking how this page is built from Drupal. Okay. So why we have to understand how Drupal builds pages in so much details. Maybe it's not necessary. You can do your work probably without understanding everything. Maybe if you are a front-end developer or site builder, why? It's not a problem at all, if you don't. But if you are curious enough to go down to the rabbit hole, I try to explain how many levels your request cross. Before the response is created. So we get to take the red pill. Okay. The point here is that we want to discover what Drupal does without looking at it from the code side. We don't want to set up xdebug, go step by step to understand because there is a lot of code, a lot of layers. So we try to instrument our Drupal installation to see, to retrieve those information from the outside, basically. Instrumentation is a typically concept of engineering in the context of computer programming. We want to measure performance and information from a system from the outside, basically. Instrumentation is typically done on three levels. We can profiling a website, tracing what the website does or analyze logging. In this session we will concentrate on the first two points. So we are profiling our Drupal website and we are tracing our Drupal website. Okay. First of all, because we are trying to analyze the system, probably we want to disable of the optimization that Drupal has out of the box. So we can maybe reload the same page without receiving the response from some cache system. And this speed up our inspections. Hopefully from Drupal 10.1 this is quite simple. So you can go to the web UI of Drupal to this admin slash config slash development slash settings page and disable cache for the markup, enable, tweak the bug, disable the tweak cache and so on. You can do that to speed up the analysis. Then you have to turn them on when you are in production. Okay, starting from the profiling part. We will use a module, one of the module that I maintain. That is called web profiler. At the beginning it was a straight part of the web debug component from Symfony. So if you ever use the Symfony every time when you are on the development environment on Symfony, you have a toolbar at the bottom of every pages with some information. 14 years ago I started a project by parting this module to Drupal, the component to Drupal as a module. And we will use this module to understand something. It depends on the devil module and on a module that also I contributed, it is called tracer because we saw later some information that are useful for web profiler are also useful for other external systems that can be used to trace information, trace what happens on a Drupal site. You can download it, it's a module and I have a short video about it. So I have installed it. If you require it with Composer and then you install it, you will have this toolbar at the end of every HTML pages with some widgets on it. Then let's see if this works. Okay, so there are a lot of widgets on the bottom, there are a link at the right end where you can go and configure web profiler itself. There are some configurations and a list of the active toolbar items that is shown on the toolbar. You can enable, disable what you need. In this case we are enabled someone to collect information about front end, HTTP request, routing services, the theme layer translation. When you saw the configuration, the toolbar now has some widget more. You can see information about requests, about time, memory, database queries, services, assets, JS and CSS, events, forms, external HTTP calls, performance on the front end, the theme, routing, translation. If you click on one of those widgets, you go to the dashboard where all the information is shown. Here you will find all the information the module collects about the request, database queries, probably click on everyone, on services, assets or you see CSS, JavaScript libraries, toolbar settings, events, forms and so on, front end performance, team information, routing information and translations. On the reports page, we list all the profiles we have collected for every page you visited. So you can go there and see for every page you visited in the past, you can go to the profile of that page. Okay, so everything in Drupal starts with this unique file. So this is the only file that Drupal expose to the outside basically. It's the index.php that is in the route of your Drupal installation and what it does, it requires the composer outload file to load all the information from vendor or modules that expose classes or objects. Then it creates a new Drupal kernel. It handles the request, build the response, return the response and then it terminates. This is what it's called a front controller pattern. It is quite typical in web application. So this is Drupal basically. All the magic happens when the request is turned into a response. Okay. So there is another concept that is implemented in the core of Drupal that comes from a project that is not Drupal. It is stackphp.com and this is used to decorate the kernel, the Drupal kernel when the response is converted in the request is converted in the response. It's decorated by a set of middle words that it used. They are used to add cache information. It's used to negotiate if the response should be HTML or hijacks or whatever. So the request cross a set of layers. Then it will be handled by the Drupal kernel that converts it in a response. Then the response cross all the layers back in the opposite order and the response is returned. Okay. We can use web profiler, for example, to list all the middle words that the request cross before reaching the Drupal kernel. All the layers have a priority. So, first of all, Drupal negotiates the type of response if it's HTML, for example. Then there are a couple of middle words that the tracer and web profiler modules add to do something. And then there are some middle words that deals with caching. The latest one starts the user session and the request is handled. Okay. So, after the request cross all the middle words, it is handled by a router that will find the correct code to generate the response. Take the request and generate the response. We can use, again, a web profiler to see which code has been used. In this case it's a controller. Basically, 99% of the time a response is built by a controller in Drupal. In this case the controller is called Forecast Controller that has a method, that is called Page. If you configure the web profiler according, if you click on the name of the controller it will be redirect to your ID in the file and at the line where the method is so you can inspect the code directly. We will see this in a later slide. One other information using web profiler is the name of the route that has matched. The route system in Drupal is used to match your URL that comes from a request to a specific controller that will handle the and generate the response. Every route in Drupal has a name. So, in this case the name of the route so we can go to our code base and find and try to look where this route is defined. And we will found it in a file called weather.routing.yaml where weather is the machine name of the module that contains this route. Here we will find the definition of the weather.forecast route. We will see that the path for this route is slash forecast slash curly brace city. Then some default information, some requirements and some options. The important part here are the default parts and the option that we'll see in a moment like in the... Before this the web profiler also list all routes that are present in your system. We can use it to check if this route does not exist in effect there are so the weather.forecast the path and the controller that handle this route. Okay. Let's start with the option part of the route definition that it's used to convert the parameter that you receive from the URL to something that Drupal can manage. If you look at the node system when you go to slash node slash 27 Drupal will not receive the controller that will handle Drupal 27. It will receive the node object that Drupal has loaded from the database that has 27 as node ID. This is called Drupal called this parameter converter or parameter upcaster and it used to convert part of the URL to something more useful for the system. In this case an instance of the city entity that I defined for this module. Okay. Again if you look at your code and try to find something called weather column city you will find this class somewhere again in the weather module that has two method one is called applies this route match the parameter converter and can be used to upcast the parameter and then the important part is the convert method that takes the value from the URL in the curly brace city part that in our case is lild and it use it to retrieve the entity from the database basically. So it loads the entity type server service load the storage for the city entity and then load the entity by label. This is useful because if someone try to go to a page to a city basically that you don't have the Drupal automatically manage this and return a 404 error page because it cannot upcast parameter to anything. If we go to the service collector, the service page of the web profiler module we can check that this weather city converter exist it comes from the weather module and it works Drupal can find it because this service has been tagged with this parameter converter tag. It's a parameter converter and it use it to upcast parameter. Ok. You can also use web profiler to see database queries so we saw here that we saw here that Drupal performs a database query to load the city and you can find it in the database collector where all the queries for a specific page are collected and for every query you can for example swap placeholder so the query on the top is the same of the query on the bottom with placeholder showed the second one is exactly the query that Drupal execute on the database you can copy the query and pass in some database client to check the result for example you can also run explain on the query to see if you can optimize it in some way. Ok. Turning back to the route definition we saw the parameters section the requirements section is quite easy because just check for the permission of the user then there are two defaults information one is the dash controller and the other is title callback let's start with this second one the title callback so you can have somewhere on your system a class called forecast controller that has a method that is called you look at your code somewhere you will found it and this is where having a parameter converter is useful because the title method does not receive lil as a string but it receives an object an instance of the city entity that I've defined so you can it's more type safety you can be sure that you will receive a valid city in your code and you can use it for example build the title of the page because city is a standard dropal entity that automatically generate the label method and you can use it to retrieve the label ok the other information from the same file is the controller that it used to build the page we can see the code from that controller it's more longer but it receives the same city entity that you can use and then perform something to produce the response ok the first thing that this controller does is to use some service in this case this weather client service to contact an external an external service service in dropal is a PHP class standard PHP class that can be used to perform some useful task for example sending an email authenticate user service like in this case the core of dropal has more than 500 services by itself so there are a lot of functionalities that you can use that already been defined in the core of dropal we already seen a couple of them before because middle words are services and also param converters are services in this case we have a service that is called weather client defined again in the weather module that will contact in this case open weather map that will return as the forecast for the next days ok so we can use again web profiler to see if the list of services that are defined weather dot weather underscore client is one of them the class where the service is defined is the blue one defined by the weather module and so on again if you click on the name of the class it will be redirected to the your ID directly to the page to the file where the code is ok another useful information that we can grab using web profiler in this page is that dropal performs an HTTP request to another service to open weather map to collect weather information so we can see the URL that is be contacted the request that we send to the external system some statistics about the request some information about the response we can use it to understand what it happens every time your dropal contacts some external services ok so we have our page built forecast controller is the file that built the response not really because forecast controller returns the title of the page as some array it does not return html it does not return all the markup of the page it does not return the blocks around our information it does not return css or javascript ok so where all those information comes from basically by the render pipeline of dropal what the controller returns is a render array basically render array is just a multi-dimensional php array with some convention because keys that start with sharp are properties of the render array keys that does not start with sharp are nested render arrays because you can build render arrays of render arrays ok one important information that you must always declare on a render array always is the cache information because this is used to tell dropal how the output of this render array should be cached to be reused when it can be reused and to be rebuilt when it has to be rebuilt in our case we said that the max age of the response is 3 hours because we collect forecast information for the next 3 hours we add some cache tag and we say that the response of this controller must be different by URL and you must have a different cache ok we are using this tam hook that is called weather underscore forecast we can try to inspect dropal to find the list of all available tam hooks that we can use yes this is provided by the devil module but you have it because it requires it the devil module provides you a list of all tam hooks that you can use in your controller when you return a response in this case we are using this weather underscore forecast that has been defined in our weather module in here we will found the variable that you can send to the template the path of the template ok in our case if you look at the weather module in the weather.module file itself you will find the definition of the weather underscore forecast tam hook that accept this for variables the forecast, the units metrics or imperial the description and the coordinates that it used to build the page itself is built by a twig file so at the end dropal will use this may be too small but at the end dropal will use this twig file to convert all the information you retrieve from open weather map and from the database of dropal in the final html so here we are using information from the forecast information from the description or the coordinates that are on the ct entity and at the end your controller returns this render array with this team information but this is still not a response this is still some array with some information from the render system of dropal the latest part is managed by dropal that is the event system because in dropal a lot of systems are loosely coupled and the communication between these subsystems happens using the event system so at some point the dropal kernel takes the response from the controller that is a render array and it dispatches kernel.view event how we discover that is this the event that has been dispatched by tracing the page so we have profiling the page until now now we try to trace it to trace a page we can use for example this module that is in very alpha stage but it works that is 7y for observability the observability module uses data collected by the tracer module that the web profiler downloaded also and they use this information to send trace data to a software called open telemetry that is an open source system to collect telemetry information from a system then open telemetry wrote all the information that it collects using this another open source tool that is grafana tempo and then we can use grafana itself to build dashboards to analyze the information that we traced and in this case we discover that at some point just after the dropal build the controller perform the HTTP call in dropal calls the kernel dot event sorry kernel dot view event web profiler has a page where all the events are collected so you can use these to discover which class will response to the kernel dot view event you can go there and you can see what dropal does when the response returned by a controller is not a response by itself but is an array for example and this is not the end because there is another event just after the kernel dot view that is this one render dot page underscore display underscore variant underscore select you can use web profiler again to see where this code is and you can look at the code just to discover how the dropal adds all blocks around your content so basically in this event subscriber this code that respond to the event dropal will load all the visible blocks per region and then add the information from the block system so that your controller has returned ok web profiler has a page that collects all blocks that are used on a page both the block that are loaded but not rendered because some visibility rules and all the blocks that are effectively rendered so you can discover this information too ok and at the end the index dot php send the response to the browser and it terminates the kernel in effect it dispatches some other events when the kernel terminates and then you can use those information to perform some clean up or whatever ok there are some other useful data collector that web profiler offers after the page is returned to the browser that you can use for example to inspect the rendering call graph of all twigs files in this case we can see how weather dashforecast.html.twig the time that Drupal spent parsing and converting that file to HTML and so on this page is way longer than this one you can also see the list of all twig filters and twig functions that are available on your system that you can use in your twig files our template uses a couple of them for example and you can see the assets collected for the page there is the list of all CSS files or javascript files that has send to a page and in the latest version of web profiler you also have the list of libraries that you have attached to the templates for example in this case we have those to weather slash base and weather slash map libraries that are used to to style the page basically and there are way more information that you can collect from web profiler for example you can list that the latest version of web profiler also collects and list all the single directory components that we have used on your page and the latest Drupal with the umami profile where they already replaced some templates with sdc components you can see in the toolbar of the web profiler those components you can also extract core web vitals information only if you are on chrome because they work basically only on chrome so you can see cumulative layout shift and other information useful for optimizing the front end you can see all the Ajax calls that a page performs for example to download the toolbar when you are logged in on Drupal the toolbar of the contextual information are retrieved using Ajax you can retrieve information about forms about views and then you can you can see if your page has been redirected from some other page or forwarded from some other page you can see all the information from that request and you can also see information collected by the request that Drupal does to the big pipe module if you know how big pipe module works it performs some subrequest from the main request to retrieve all the difficult to cache part of the page that will be returned asynchronously but if you want to have more information about the latest version of web profiler there are two tech blog on the tech blog of Superfabric and check there and the latest thing I wrote a book so if you are interested in the front end part of Drupal and what happens when Drupal builds a page render the output and so on just for today 20% off so go by the book you also will find chapters about single directory components about next.js so build the couple front end using Drupal and integration with story book so there a lot of information ok we are at the end there are a lot of work in Drupal so please come to contribution sprints and contribute whatever project you want web profiler itself needs some of love so if you have time of whatever feel free to contact me and thank you I think we have some time for question otherwise I'm here if you want to see a live demo of all of these why not this one this is the most important slide of the presentation can you talk with the because otherwise in the online maybe thank you very much this seems like a silly question when you're running that you're getting all the data back but you've got the admin module running everything toolbar so can you stream it right down so the question is if you can collect information about anonymous users because in the presentation I'm always logged in in the website of course there is a permission to show the toolbar to roles so you can show the toolbar also for anonymous user but you don't have to the toolbar is just a side effect of collecting information so information are collected in any time for every page then the toolbar is loaded in Ajax after the page is returned so you can navigate the website as anonymous user and then on the reports on the reports section you will find also those information and for all profiled information you can go to the profile so all the collected information for every page exactly also it is API call because it works exactly the same way there used to be a timeline in display but I could not find it is it replaced by something the timeline display in the previous the question is where is the timeline that will be in the the previous version, the Drupal 9 version the Drupal 8 and 9 version as a timeline like the one from symphony that show all the same information that now you can find using no, not this, using Grafana for example that is here this is mainly because that version is built using D3JS in javascript and I don't know how to use it the Drupal 10 version is completely different from the Drupal 9 version because the symphony version is different so the underlying code of symphony has changed between symphony 4 and symphony 6 so it rebuilds all the module but I don't know how to rebuild the tool the timeline so if some of you is skilled on javascripts and timeline in javascripts but now you can use if you want you can use this module send all the information to tempo in grafana and then use grafana that is way more cool that my version thank you again