 and there's a correct line. This session is Living, Breathing, Drupal, the Biology of the Request. My name is Kenny, webgenny.d.o. I work for Hacquia, where the enterprise value is drupal, so we provide support and professional services related to drupal as well as training in our great partner program. So if you own a development shop, you can become your partner, come see the after session. There's my obligatory pitch. So today we're gonna talk about first of all, if you have a mobile phone, you're gonna tweet with a hashtag for this session is DCL Supply. So today we're gonna talk about basically how drupal works end to end. When drupal makes a request from the time of the request it received to the end of the request. That's actually shown today. So, first let's talk about drupal as a system. And like many systems, it's built on traditional design patterns. Design patterns, they're everywhere in this platform. And so, if we really understand the patterns, then we can really learn how drupal works. One of the patterns that drupal is based on, thank you Larry Dahlfield for his great blog post on this, is observer and visitor. And like drupal's hook system, subjects contain objects called observer that listen and respond to events. And those are the builds on the idea that objects can be extended. So very much like the hooks in drupal. When drupal sevens do database layer, you can find the patterns of factory command objects. There's several variations in the factory pattern, but they all boil down to the same idea. One object, a client, or another object, the factory is for an appropriate implementation of a piece of logic. It doesn't care what it is. And the command pattern, the process of the quote doing something, is wrapped up in an object which create a new instance of the object, configure it, execute it, and then cause the action to take place. The dependency injection pattern is where things are sent to the object rather than requesting it on its own. Think of the variables passed into most drupal functions by reference, right, that little and sign. What if we don't know in advance what the time and information or context we will need, or if it will vary? One common solution is a variant of the concept of something called broker and migration. This doesn't feel like it's working. This doesn't feel like it's working to you. It must be a better way to explain this. I am serious. Let's reboot. You guys ready to have some fun? Let's have some fun. First, let's meet the request. Ladies and gentlemen, eight-bit drift. A round of applause for eight-bit drift. Drift is gonna take us through a magical journey through drupal today. We're gonna go end-to-end through the overworld of drupal and we're gonna learn all about how it works. And we're gonna leave all that boring design pattern stuff where it belongs on the first four slides. I present to you the legend of drupal. I know you recognize this. I know you do. When we start off, we start off with something called the bootstrap. All right, so when drupal first takes the request from a web server, it has to bootstrap. And really, that's just a fancy way of saying it. It has to load the minimum requirements that it can require to serve what you've asked for. So the bootstrap is a special file called bootstrap.include. You can find it in the Includes folder. I highly recommend it if you're really interested in the underpinnings of drupal that you go to that file and take a look. And that's how I wrote most of the steps, honestly. And it's broken into seven distinct phases. Now, I'm gonna do a little disclaimer here because I'm gonna go through these phases in the way that they are laid out. However, you should know that if you really wanna know how this works, they sort of bounce between them. You know, like the database phase happens. So first is the configuration phase. So just like the legend of drupal or any of your famous video games, you always start off by entering your name. That's a variable. So it's an important variable to our request. And basically what the configuration phase of the bootstrap does is it has custom error handling, it's prepared, the settings PHP file that you could find gets loaded, and some PHP variables are modified. So those are those old in-sets that you see in, you know, where you send your memory limit and digs in that basin. And then key variables that are used later in the request are initialized. So that's configuration. Now, phase two is the paid cache phase. In drupal, there are two of these. There's a early-page cache and a late-page cache. For now, all you really have to understand is that if it finds the page that you're requesting in cache, it will return it and the execution of the request will end. So to give you a little bit of that idea of the difference between early and late, basically early means that it's, you know, early on in the bootstrap and late means exactly what's been later on in the bootstrap. And the real distinction between those is that later on in the bootstrap, there's this function called hook-to-upline-earlier. So that's when you click that aggressive setting and your performance page and it complains and it says XYZ module's not going to be compatible. That's why. So just like most video games, if we've already saved this game at the end, there's no reason that the game is, the drupal database stays. It connects to your database, it loads the appropriate database, include file you've assigned, and it basically now makes a cache to it. And this way, it can do its queries, and you know, because everything in drupal is the database, right? And so, however, though, if for some reason your database isn't available and it fails, like if this is where you're in Nintendo in 1988 and the database failed, it might look simple like this. So, luckily, drupal provides a much nicer site offline message and you also don't have to blow into the cartridge and use a Qtathon to get it to work. Before I move on, let's do a regal. Many years ago, the evil Prince darkness chicken stole one of the tricorps with power, the golden hooker. Prince's drupal had one of the tricorps with wisdom. She traveled to the end of the island to hide it from kitten before she was captured by his evil army. Don't find the crystal node, Dries, to save her. So, our entire journey today is gonna be based around finding the crystal node. There's our hero, ready in the overworld. All right, so, here we go. The next phase of the bootstrap is the variable state. This is where drupal initializes its locking mechanism. It loads its variables. It's got the cache along the way to see if it can save any time by loading those variables. And the last thing that drupal does before it calls the bootstrap function is it resets the variables that came from your sevens PhD class. So, very much like the inventory in an RPG game. This is where everything is essentially loaded. These are all the things that you're gonna carry with you throughout this request. And of course, everyone in here knows Dries, and you know he doesn't go anywhere without me, Joe. Next is the page header phase. This is where what boot is called for all the participating modules. And if drupal's not on the command line, like brush, for example, an HTTP header is sent. All right, and this is the thing. I mean, when you really get in the drupal, if you really wanna see how it works, it's got to look at the code. And really, when you hear page header phase, that sounds really fancy. But really, it's just that function right there. How many lines of code is that, six? So essentially, all it's really doing is it's just, like I said, it's bootstrap and vocall, which we'll talk about a little bit later to talk about in vocall. But that calls all of your hook boots. Every time you see your vocall, you can basically add hook to the beginning of whatever the word is next to it, and that's what's gonna happen. And that, of course, like I said, if it was on the command line, it was not on the command line, it sends a page in. All right, so next up is the second phase. All right, this is where drupal determines if there was plus as a login user or not. And remember, when you're logged in, there's never gonna be a cached page. But one thing to remember as a little sidebar is that that only applies to your page cache, right? That can be frustrating. Sometimes you're logged into the administrator, your menu's unupdating, your variable's unupdating. You don't understand because you're logged in. Well, that really only applies to page cache. Every other cache mechanism in drupal doesn't respect that. So you literally have to clear your cache. The next phase is the language phase. This is where the translation of drupal interface takes place. This is where the key function that you define if you're a great programmer and all of your modules. This is where all that happens. And one of the things is that drupal has hundreds of translations that are available for, and that's on localized.drupal.org. And that's the phase where basically we write the language of the entire interface. We've been taught a new magic language. And now he's going to get rid of the name. This is Rufus. All right, but this is very fun to do. Is that clear to side? Excellent. And our next phase, we're going to talk, well, the next thing we're going to talk about, that's the seven phase of the bootstrap. So the next thing we're going to talk about is essentially where it's going to go. And so the question about the menu system as well, how does it know where to go? When you request your food flash bar, how does it know what your food flash bar is? And so when a request comes in, assuming that you have, assuming that you have the path module, a lot of you may have aliases, it basically looks up the path alias as it's regular. And then it goes to a table called menu writer. And inside the menu writer table, Drupal is essentially every design path that is in the system. And that can be a very good table. And that's also a really great way to, when you're having menu problems, is to dump the contents of that. So the menu system is, you know, broken down into a lot of different ways. And I mean, how are these treats going to know where to go on this big island? Well, according to our buddy, Link, you should just press the left for the map. So the first question is, where are we going? Where are we going in Drupal? And you know, this is, what you're seeing here below is, that is the code that essentially tells Drupal in your hook menu, where it should go. And you're passing an item to Ray, and you know, that's the path that could be any path at all, it can have slashes in it, it can have arguments in it, it can have anything in it. And that gets written to the menu writer table. And so this is where it determines where we're headed. The next question we're going to logically ask is, you know, can we get there? I mean, are we going to be able to actually get there that we have the right keys to how we know? And that really is broken down into a function called the access callback. This is the property of your array. And inside the array, it's just, you know, if you can put anything in there, actually, you could put three, or there's one of those things that you didn't care if everybody had access to. Most people will use user access and some of the access callback to do some complicated logic. This is essentially what determines whether or not you can access the path. If so, you proceed, if not, execution stops and you get a call. And now the last question is, how do we get there? So how do we actually travel from where we are now in the hour of Drupal all the way to the castle on the L? And what takes place between UP and A essentially is what's called the page callback. That's a function that you need to find that just tells Drupal what it should do when it finds that path. And that's how Drupal decides how it's going to render the page. And somewhere in Drupal, a function is defined for every single path, if it's a node path, a constant path, there is always something like this. Our next stop is on the hook system. Our favorite thing for Drupal, because when I really got this, I really was able to sort of graduate into a Drupal lesson. You know, it's one of those things that you go along, go along, go along building sites. You kind of understand what's really done. Once you really understand how they work, you really can register power, and that's what we're going to talk about now. There's a lot of animation here with me. So the hook system of Drupal, you know, you recall earlier if you were awake when I said this, that I referred to something called dependency injection at the part of the session. And that's basically, this is a variant of that design pattern. What it means is that as Drupal goes through it's defined in hooks that it executes each one, it inserts or injects the variables that are found in what's being passed in a function. Right, so that's that little ampersand, dollar sign, too. So for example, and so how does Drupal determine which one is going to call first? Well, basically it does it in two ways. It determines by the weight of the actual module, which is defined as a magic cable called system, I highly recommend you learn it. And that basically has the weight, that's the very first thing. And so weight is just simply an integer, it can be anywhere from negative 99 to, so of course it orders it by that. And then if something has the same weight, like if everything has zero, like it usually does when you install Drupal, it goes in alphabetical order. So very much like an inventory in our game as variables are passed by reference, their attitudes. So for example, the form variable and the form alter, in this case, Rhys has picked up a shield and now it is part of the hook. And so hooks, they don't just have, sometimes we use hooks to take things away from something. So in a hook form alter, we might own set five or six form variables because we don't want that to show up. So hooks can basically modify for all terms. And if we want to remove things, we can do that too. Major bonus points if you could tell me what game. All right, so let's talk about this function. This is basically modular vocal. As far as I'm concerned, this is one of the best functions in Drupal. Because to me, Drupal documentation is excellent, right? The API is 100% oxygen, so it covers all any standards to it and that's how it's generated. Unfortunately, what isn't always great in document, contributed much. Really, this is the magic function of Drupal. If you're having trouble finding out what hooks you can use in a contributed module, a simple search, using graph or any of your favorite text editor tools, can, of the modules folder, return this. So if you're looking for module in both all and you find like 15 instance of it in the OGM folder, then that's every hook that is, so it's a really useful way to be able to sort of go through and understand what each module has to offer if you can modify them. And again, you know, this is one of those situations where the code really isn't all that big of a deal. The only function here that might seem a little scary is that callUserFunk array. It's really not that big of a deal. It just means that it can pass any arguments, any variables at all to this function and it'll just pick them up. But at least the scene system of Drupal comes into focus. This is where all the presentation decisions of Drupal are made. So assuming that you have built the correct, all of your presentations should be taken. It's the Drupal 7 core maintainer, Nancy Webchick-Pyman. She's here to teach our hero all about the theme system. All right, so again, the theme system is the presentation layer. First, let's talk about the theme loading process. So when Drupal gets to a class, it goes for all of this, it's going on all these hooks, and everything else, it has to turn what theme to load. Is it going to be gallery, is it going to be logic, is it going to be some kind of theme? And what that essentially allows Drupal to do is then being able to know what folder has to look in for the files like temple, php, and tp, and here. So that all happens in a lot of places. Now, obviously I'm encouraging what occurs in these, and I highly recommend you, and there's a little file called theme and code. And so the next thing is after it's found a theme, it's going to load up temple, php, and execute what are called pre-process functions inside it. So just like hooks, if you remember, they follow a certain meaning convention here. The thing is sort of naming conventions, depending on what every time the node is just like the hooks. The last thing that Drupal does is it then loads your page temple files using its suggestion engine, and any theme functions. And along with that, it loads the JavaScript, the CSS, the images, and anything else that comes in technically prior to Drupal sort of requests the site, right? So that's not where the Drupal overhead is going up. So now, after the request, we've arrived at the castle with a crystal notice, and I feel like basically now we're going to complete this journey. And he's ready to prevent himself from the evil kitten and find the crystal one of them. So anyway, we're at the end of our quest, and so this next part of the session, I'm going to kind of divert a little bit, and I'm going to talk a little bit about how you can use this information to build that effect. And it's going to be pretty lively to an extent, you guys are going to do a game over screen. Now this is actually an important topic. Let's talk about the updates. So there is a sort of a side piece of policy side, a very important piece of Drupal that's a side file that we have to actually fix. So when you request a page, right, it's going to index the action, and it's installed, and the code's gone to install. It all does basically the same thing. And what it does is that it essentially goes to my favorite table in Drupal that I've talked about, which is the assistant table, okay? The assistant table essentially contains things like name, it contains file path, the weight that I talked about, but it also contains a pretty important number that a lot of people are confused about when they first see it, it's called schema. All right, that's the column. And so the schema number in that table matches up to an update function that you have somewhere or that Drupal has somewhere in its dot install class. Let me give an example. Let's say I have a module called foo, and the schema version in that, when I install is one. Now if I want to update, all I have to do is in dot install put foo update two. And when Drupal runs update PHP, it's gonna know that it has to implement and it's gonna run that. And so then I can, and so a good way to sort of do quick and dirty testing when you're doing this kind of thing is that the window assistant table and this benefits it in a while. And let's say you're on the development line, of course. So let's say you basically want a bad update. It doesn't break it, I mean, it doesn't do what you want. So how do you get to go back and rewrite another update? Well, that gets long when you debug. So the truth is, the question is, I mean, so what? I mean, why do you have to know how Drupal works from end to end? It's really important, you know, to a couple of the methods you can use to, well, I'll tell you, when I built this session, in one of the ways I did this was I just loaded up my IDE, you know, and I basically just set line by line, you know, and sure, it took me three or four hours to do that, you know, the long time. I didn't go through every single amount of code that would take me forever. But it's good to go through the general form. It's really a good idea to see, I mean, even if you just open up index PHP, there's a wealth of information there. I tend to go through the same system, I mean, Drupal is big and scary, and so you realize that it all boils down to one file that just calls all the various functions in the system. And so it's important to kind of know it and to end, because in many ways there is, you know, there's a sort of troubleshooting at the core to the problem here. They say, you know what? For some reason, the variable on this page is printing out weird PHP arrays, okay? And so you look in the modules, you look in the modules, you look in the themes list, and it's showing up right this way. So you go look in the theme, you're looking everywhere, you can't find any networks. Knowing that the theme is loaded last, what would be a really good transition instead? Change the theme, right? Change the department, change it to garmin, change it to one of the default themes. And see if the problem still occurs, and that becomes a problem higher up the stack, right? And then it's modules. Now you locate the module that may be causing the problem and the hook to that. What's happening? Well, what's the next step? Disable the module, right? Disable that. It sounds like if you go higher up the request, and you disabled a custom module, if there's a core bug, you should be reporting, and if you disable the core module, and it's still happening, then it's something in the actual file that you should be reporting. So by understanding kind of the execution order of Drupal and how it runs from end to end, you can essentially troubleshoot any problem. That also helps you build better sites, okay? When you understand my Drupal functions, you can build a better site because you know that the theme layer, all of your presentations through here. And how many folks in here are, I don't know, two years plus through both periods? I said you've seen a lot of sites. How many folks have actually picked up a site from a number development? Many of you have seen things in it. So it's because those developers really haven't, you know, they really didn't understand Drupal at a steepest level to understand, you know, you really shouldn't be putting a database query in a template. So what I'd like to do, like I did in my last session, is I'd like to kind of open for, this is a really complex software, so I'd like to open to Heather. Thank you, Learning Services person, who teaches me how to do these presentations better. The question was, can you talk a little bit about the constants in the Bootstrap Cloud? So some of these constants that are in the Bootstrap, like Drupal database and Drupal Bootstrap and whatnot. So those constants will map to certain environmental variables. One of those constants would be the CLI function I talked about. If you follow the thread of that CLI function, you'll see a constant call. So those constants are totally different times. One of the other constants might be, well, here's an important one. When Drupal Bootstrap's, not every single module in Drupal Bootstrap's, which you could tell if you go into the one aspect, and early on, if you remember when we were going to draw inventory, it basically sets a price that's saying you should run this during, so how many folks in here came from a previous, let me just repeat the question, first of all, can you give examples in the three different APIs that I talked about, the Hook API, the Theme API, Theme API and module API, where do things come and should go in a second place? I mean, a lot of that's gonna be personal style in terms of whether you're gonna put them up there, but how many folks in here have come from a previous programming language? And so you're familiar with this concept of separating business logic from presentation, right? That was deep in your head. And so, good examples in Drupal. Well, here's an interesting thing. All the theme functions that are available in the Feaning layer, they're also available slightly higher at the stack of the module level. There is a matching pre-process node function at every module level, so you could basically, if you had a module called foo, you'd be able to do foo pre-process node, and if you had a theme like R-Tec, I'd trade it on the stack to build. So the question that I often have, I don't know when it's right for you to do more. My only sort of, you know, it's kind of the best part of this thing, but my hard and fast rule is that, you know, if I need to have something showing up, if I need to have control over the feeling in the presentation of something, you know, that when the developer gets it, it's at least pre-processed. So a great example of that actually would be the stack. That's a lot of really, there wouldn't be enough for it to just fit out for values. So that's a great, you know, example of when you would put some theme logic up there in the module stack. But what is that a lot you're gonna do by putting it up there instead of like burying it in a core theme, is that it essentially allows the next developer to come around and turn it and talk. Please, I'll talk a little bit about that. And I'm gonna talk to your database, do it in the module. That's do it in the module. Once in a great while, once in a great while, you can put it in 10 for PHP for whatever reason. So there is basically a series of menu hooks in Drupal, and it's, you know, hook menu. So we're hooked with the name of the module, and inside of that is just a very simple, like it's the array API. Inside of that is just an array. Each one of those arrays has to apply. Menu, local tasks, does anybody in here know? So it's essentially just an array. Well, because you're, well, that's the Drupal interface, right? That's the Drupal interface itself. That's like the actual Drupal interface happening in a language space. See me after this, I'll explain that to you. It can be, right? And that's why, I mean, this is in a performance session, so those of you that saw me subscribe, I know I did one of those, but this is, you know, that is one of the things of Drupal, right, is to execute as little hooks that you possibly can. And how do you do that? You do that with caching. There are other ways you could do that too, right? I mean, you could take the pressure off the database and the caching table by using technology like that. So yeah, there are a lot of hooks in Drupal. There is an awful lot of execution that goes on, and that's why caching is such an important thing. Now, there are two hooks, well, there's actually three hooks that will, depending on your settings, will never run. Hook boot and hook exit, if you have an aggressive set in your performance page or external in the press call, that will never run. And if you have normal caching in it, so yeah, awful lot of overhead, this is actually a statement. There's a hook in Drupal 7 that actually allows you to rearrange the weights. So that's another way. A little short, but.