Twig is a wonderful tool to build templates for your Drupal 8 themes. It can be easy to pick up, but certain problems can leave you frustrated and unsure of what to do. Don't fret, we'll be talking through some straight forward solutions to most of the problems that you'll encounter.
In this session you’ll learn how to:
- Debug variables and find the right values for your template.
- Understand why your changes are not appearing on the page.
- Avoid and resolve PHP errors.
- Fix a White Screen of Death.
- Develop a checklist to fix common problems.
- Understand and interpret a problem that may require more advanced help.
You'll leave this session prepared to work with Twig templates and resolve issues that appear. We'll be spending most of our time within Twig templates and the theme file. This session is perfect for those who are new to Drupal 8 and Twig.
Transcript
Larry Walangitan: This is Taming Twig. Thank you for coming out to meet here. It's always exciting to be here and to present with everyone. Make sure that you can grab the slides at the link at the top to follow along. A little bit about me. My name is Larry Walangitan. I live here in Chicago. I usually tweet very rarely, but I threw it up there just in case. I work for a company called Chromatic. We're a distributed team. We have team members all around the world, so check us out.
Now, let's just dive right into the subject matter today, Taming Twig. In my own experience of using Twig the past few years with Drupal 8, there're some common problems that I've experienced and they have been really frustrating. When I look at my Stack Exchange or Stack Overflow, if you look at all of the problems, which I did in the past few weeks to see and try to distill them into the same categories, there's four common categories.
The first one is that your changes just don't appear. You try to print something on the screen with Twig and it doesn't appear at all.
The second one is that when you call a variable in the Twig template, your output just isn't what you expected. You try to call in the field and it doesn't appear. The third and fourth ones are that your site is unavailable or that it's just unresponsive at all, so you're unable to actually work with the site anymore.
For the talk today, we're going to talk about how to address those four common problems. First, we're going to talk about how to debug Twig. Second, we're going to talk about the values that you can find within your template. Third, about resolving any sort of PHP errors and how to avoid them. Fourth, the dreaded white screen of death when your site becomes unresponsive and finally when something is too difficult to solve by yourself and where to go for that sort of problem.
First, debugging Twig. Let's talk about our debug setup. We got services.yml file in sites/default, we are able to change some values so that we can make sure that we can debug Twig and have some tools available to us. Under twig.config, we have to make sure that debug is set to true, that auto_reload also set to true, and that caching is set to false.
All of these things by default. If you were to copy the default/services.yml and rename it, it will be the opposite of these. Now, for a production site, you want to make sure that it's the opposite of these but when you're locally developing or working on a development site, and you're trying to figure out what's going on with your Twig templates, make sure that these are set as seen here.
Now, the output when you inspect something with a Chrome Inspector with those value set in your services.yml file will look something like this. You'll be able to see the files and suggestions that Drupal and Twig are looking through in terms of what file or what Twig file is being called in and the kind of files that you have available to you. In this case, we can see that it gets as specific as node file with the node IDs, so you can alter a specific node or you can use a node type.
In our case, we'll be using the basic page template. We have node--page available to us here and finally, we have our basic node.html.twig file. services.yml is really helpful to just know when you're working with a lot of different templates and different fields and things are being called in. You'll have a better idea of what Twig file to work in to address the issue that you want to address.
Now, available to us also is the dump file with Twig. Here, we're just calling dump on content.field_header. Here, we're just going to be calling in our field header and if we want to look at what that looks like when it's printed out by default, we just get this array of a bunch of different keys. Now, we can call in these different keys, we can manipulate them, in order to pull in the values in Twig that we're trying to find.
Now, another tool that's really useful and pretty common is to use to Devel. Devel comes with a bunch of great things, Devel, in and of itself and there's a module in it called Devel Kint. This allows us to use the kint function which we call in the same way that we use a dump function. Here, we're calling a kint on classes, which is a part of the page.html.twig file and it outputs on to the page in a similar way as our dump function except that we have these nested arrays that we can dig into.
What gets loaded is, instead of having that ugly dump array, which is just a bunch of keys, you can actually go and find your key, select it and find more details about what you're trying to find out there. Now, when using kint-- I don't if people have experienced it here but in my own experience, I found that it's not as performative as dump and that there's usually a bunch of problems. Sometimes you're trying to do a kint on a file or a variable and things just-- the site doesn't load, your memory gets timed out.
There's another tool that I just found out in this past year which is-- It takes the best of both worlds. You have the ability to use dump, which usually is pretty consistent in terms of its memory usage, and you also get a nice output like this where you can click through and find the values you're trying to find within a nested array. That tool is this contributing module called twig_vardumper.
Here, you have the ability to call your Twig variable and to cycle through it, and find the values that you want to do just by going through the nested array to find the specific values that you wanted to find. Now that we have these tools, these are the tools we'll be talking about today, let's talk about how we actually find the values specific in Twig when working with Drupal. We're going to talk about first is just the generic feel when you're working with a node template or an entity template of any sort.
A popular one is using nodes, using taxonomy-terms, a contributive module called paragraphs is being more and more common. These are the sort of entities that this applies to. You have, when you work with a Twig template, a content object. Within that content object, you have all the fields that are on that entity. We're using dot notation here, so content.field_name in order to call our field and to output this markup and data that we have. In terms of a vanilla approach, this applies in most cases. Just call in content. your field name.
Now, we're going to look at a few different examples that are a bit different than just the content.field_name. For example, when we try to find our links-- If we were to have a field called field_link, that's just a generic Drupal field that we use for links, when we call that, it outputs both our link and the text or the title associated with that link, which in a lot of cases, maybe that's what you want. You just want an anchor tag with a link and some text, but if you want to add a class or you want to do something to those links or to modify them, it requires a bit more effort.
Here, we want to add a button class so that we can present our link in a nice way that looks like a button. Now, for this just to call content.field_link, we wouldn't have access to this, so we can split that up by accessing an array within there that has the URL key and the title key. We can split certain objects within Twig and manipulate them how you see fit.
Now, taking this along-- Now, this is also very specific. When you're working with Twig, usually you use dot notation for all fields, so content.field_link. an entity or .image or something, but for fields, it's specific to fields where you would use the array notation here to get within there. Now, to find this, this is done by using Twig and the debug functions to find the use cases for this but this is a very prominent use case. Now, similarly, if we want it to work with our files, we have to make sure we're calling the file URL.
Here, we're just ensuring that, in our template, we are separating out the file URL value and calling the file_url function to it to make sure it parsed correctly. We're still using dot notation. We're calling node, which is an entity, .field_value to get-- Sorry, excuse me, .field_file to get our file field.
We're calling .entity to grab the file entity that's associated with our file because, for example, in Drupal, if you're using a standard Drupal file or image field, those are entities or objects that are stored on the fields. As we change these dot notations from node.field_file to the entity and on that entity, we can get the URI, and within there, you can grab the value of the URI which allows us to translate it into a URL.
With images, it's essentially the same story. We call our image field, we grab the entity on there, we can grab the URI, and we turn that into a value. With images, it's a little bit different in that images have the image file, which is just like a file, but then there's also titles that you can associate with images, there's also alt text for accessibility that you can use.
If we want to do special things with this-- In particular, a really good use case for using this sort of approach is when you are working with lazy loaders. Sometimes they require different attributes within the html, and in order to parse in what it wants, we're going to have to dig a bit deeper. We have our generic image approach with turning our image into a URL. We're grabbing an alt field here.
This is really particular with how we do it. You would think that the image field and the alt tag or the title that's associated with it would be on the images itself. That seems to be-- That's what I thought for a long time until I finally discovered that the alt and the text associated with it is on the image field and not the image file. That's a clear distinction of how we would go dig deeper into the values that are available to us within image field in order to grab content from there.
Here, we're going to talk a little bit about the without filter that Twig has available to us. In a lot of different templates, if you were to look at the default implementations, you could see that there's a content variable there, and it doesn't usually have any dot notation that links to fields or have anything associated with it. Usually, it's just content.
For the most part, that could be good if you just want to output a lot of different fields in how you've configured them within Drupal site builder configurations of a node or a paragraph, or an entity type. We have some use cases where you want to include all the content except for one. You want to separate one of those fields out.
Now, using the without filter within Twig, we can parse in the machine name of a field to make sure that that field gets excluded from the render and so we can use that field name somewhere else. Here, we are just printing out all of our content within our main dev and outside of that, in a sidebar, we're going to put in our field name. Here, we can start to put the pieces together of how we would separate out different pieces of content that are output in our Twig templates.
Now, there's a few use cases where we have these two different variables within a Twig template that are a bit different than how you usually approach an entity type, like a node or a taxonomy term, or a paragraph. For example, here, we have items and items is usually a field. For example, a list field with text where there's multiple items, multiple different values associated with it. Now, in this one in particular, we're talking about a field that is a-- It could either be an integer list filed, it can either be a string on collection.
We're calling our field-machine-name, whatever it's called so for example, field- list.html.twig and we're calling a for loop on the items to make sure that we are iterating through each and every item. Then on each item in and of itself, there is content, and content is attached to that specific field item to output each of those things. Now, how is this valuable? If you opened up a field within Drupal and just looked at the default implementation, it would look exactly like this.
If we wanted to do more with it, let's say that you wanted to loop through your items and apply different classes, those things are available to us. It's outside of the scope of this talk in particular since there is a loop index within Twig that we can go through and apply different things but within this context, using debug functions, you'll be able to find what's within the content variable to explore what's in your field specifically.
Rows works in almost the same way. Views is a common tool that we all use when we're building sites with Drupal. Within the rows object, we have a row and within there, there's content. Now, that content is usually defined by the configurations that we have set up for our views, whether we're calling in fields when we set up, our views or if we're calling in a view mode to output different node types.
Digging deeper into the content variables is something that-- It took me a while to figure out and to understand that the content variable is available almost everywhere but each implementation is slightly different. Using debug functions will be really helpful in terms of finding out and understanding exactly what you need to do to output the content that you want. Let's put all of these together and take a look at an example of a field called neighborhoods that just has the neighborhoods of Chicago.
In our row, we're going to exclude that neighborhoods field because we want to do something specific to it. Here, this might seem super intimidating in terms of what's available within the content variable. If we were just good to go and step through it, we have rows, which is all the different pieces of content available to us within the view. Within the content of that specific row, we have a view key that gives us access to a few different things. If you change the style_plugin and pull in the render_tokens--
Let's take a little bit of a step back in terms of what all is going here with this view. The content that we have available to us is a part of this view key and what we're going to be parsing into it is going to be the Twig markup, that field that views is going to be outputting. In the end, we're going to be calling our field_neighborhoods as a variable, as we see at the very bottom before the endfor. It's the same notation as if you were working directly within a Twig template.
You have to have the double curly braces on both sides. It's a bit different because with a lot of how we would work with these things, you would think that you could just parse in the name of the field in and of itself without the curly braces but that doesn't work since we're calling render_tokens before that.
Now, the loop.index0 means what key or what number of row you're outputting. It starts at zero, one, two, three. All it's doing is just making sure that it is iterating through each and every row available to us. The style_plugin is what allows us how to access this content.
Now, there's a really handy contributing module. The way that we talked about everything so far is just, if you would download Drupal 8, install it out of the box, work with some of the default things or check out any of those things, that's how you'd approach it. There's a contributing module called twig_field_value, and it gives us these various specific filters where, instead of having to dig through the content variable, instead of having to dig through these things, we can parse in filters on these fields in order to output the content that we want.
We have field_label. It's all very straightforward in terms of what it's doing. It returns the label. The value just returns your field value without any of the wrappers, without any of the devs or things that are associated with them. We have field-raw, which is just the straight raw value that's being stored within your database. Then we have the special one called field_target_entity. Now, this returns your referenced object of a field. Now, keep this target entity in mind because it will come in useful in the next few slides.
We're talking about our neighborhoods field once again. Using twig_field_value, we can get the label and we can get that value, and get the output that we desire to get. We just see neighborhoods, we see that we are in Lincoln Park. It's very straightforward in terms of doing that. It's a matter of preference in terms of how you do it yourself. If you're working by yourself with Twig, or you want to approach this thing.
I know that this can be contentious with development teams in terms of some teams might not want to use this contributing module or have that dependency with the projects that they're on, so it's a discussion you need to have. Some people might feel comfortable with Twig using these filters instead of the dot notation to get the values that we're looking for, but I would lobby in the sense that you could do both. They're not mutually exclusive.
If you want to have both your codebase might look a bit messy because you'd have filters and dot notation calling in field values all over the place. It might not be the best approach to do so, to combine them, but the field_target_entity filter that's available to us allows us to do really cool things. This is why, if I were [unintelligible 00:23:11], if I were working with a team and lobbying for this contributing module, this, to me, makes it way more accessible for someone who's less experienced with Twig to start to deal with some of the common issues when we got into more expert use cases like reference entities.
Here, we have a piece of content, a node, that has an article reference and if we were to call that, we would just get the whole article in and of itself. Let's say we just want a specific value, we just want one field on that entity. If we call in and use the field_target_entity filter, that gives us access to all of the fields that are available on that entity in and of itself.
If you're using nested entities with your nodes and your paragraphs, this is a really great use case in order to control the markup and to have easier access to some of the values within those entities without having to do anything with the preprocessor, because another approach to this would be to create a custom module or have theme hooks that manipulates the reference entity, loads it, grabs its field, prints it out.
There could be a lot more code to do what this does with this contributing module in and of itself, so I think it's a really cool and valuable, and useful tool if you are working with reference entities. In terms of addressing the issues with finding values, these are the four basic steps in terms of how you would approach it in your own development environment. First, always, as with almost everything related to Drupal, you have to make sure you clear your caches before you reload your page.
Just make sure that caches are cleared so that your memory's cleared, the site loads the latest version. Next is using the Twig debug tool and inspecting the elements, and seeing that you have the correct template, that what you're trying to do is within the same naming conventions that Drupal is trying to use. Make sure that you have the right field machine name and the property. If you don't, if you have typos, if things are a bit off, nothing will appear. Finally, you can use the vardumper call to debug variables and to inspect elements that way.
These next portions of this talk we're just going to be talking mostly about how to address some issues that are a big headache, in my own experience, as I've worked with Twig. First is just avoiding PHP errors. Now, when we encounter these sort of errors, there's usually two main reasons why they're happening, for the most part. If you're just working with Twig or you're working within the theme, there are two primary places where things can go wrong. The first place is within the preprocessor.
This might be a common sight when you're working, you're making active changes locally and things seem to go wrong. You get this unexpected error page, "Please try again later," which means fix it, and so just reloading the page. Preprocessing issues is the first place to look in terms of if there are errors on your site and you're just working with Twig, check there first.
Now, within the database's log configuration, we can go in there and see what error we have. In the error before, I'm parsing in an incorrect render key and it's causing problems in the array. That's why we have that error. You can dig a bit deeper and see exactly what's happening and try to run the [unintelligible 00:27:24] that way so you're not flying blind.
The second place to look if you're encountering errors with Twig is just within Twig itself. It's usually pretty forgiving but if you have any syntax errors, then you're going to encounter some problems. If you're using your filters incorrectly-- Some filters within Twig and the documentation only accept a certain number of parameters that you can parse in, like field values or that sort of thing. If you're encountering these issues with Twig, those are the two places to look.
We also can see that in our database logging where, here, we have a syntax error because there's an extra curly brace outside of the context of what Twig is trying to render, so we're not using our filter correctly there. A checklist for PHP errors. First, just make sure to clear caches. Sometimes that could fix it if you think everything else is okay. Second is to make sure you can check your admin/reports and recent log messages; going into the database logger to see the error messaging that you see.
Third, determining whether it is the preprocessing functions or the Twig file itself that's causing the problems. Then finally, try to address that problematic line or the name of the file if it's a Twig issue. Now, if you go through all of these steps and you're still having issues, one great way, that I'm sure we all have experienced, is just to copy the error and paste it into Google and see what other people have done.
That usually will give you enough tools to start to help find out the issues that you're encountering and seeing if they're novel; if they are something that's no one's experienced, or if it's something that a lot of people will have and you can deal with it that way. Now, in terms of all the errors that you encounter, like a white screen of death, when you're developing is just a big headache.
It can be a big time sink, especially if you're only working with Twig or the theme and you're not doing anything intensive on the backend and you come into the errors, it can be a huge headache and hassle. Early on with Twig, when I first started, I would encounter these issues and I wouldn't know exactly how to address them.Now, a big part of why we encounter these issues is not necessarily Twig itself but because of the tools that we're using in conjunction with Twig.
This is probably something that you've seen before. I see it all the time. It's really frustrating where
you try to look at your site, and you get a fatal error. It says your memory usage is being exceeded. Now, there's a few reasons why this happens in the first place but the biggest takeaway is that Drupal 8 is object-oriented and there's a lot of arrays and there's a lot of objects that are being loaded.
When you try to call a debug function on certain variables within your files, the memory usage that it's trying to output-- It's not just outputting the field like you'd expect but there's a lot of metadata, there's a lot of different things within an object that causes your memory to overflow. That's essentially why this is happening is, in this specific example, we're calling kint.
Now, I used to love kint. I'm a big fan of Twig vardumper just because kint seems to consistently give me these problems no matter what project I'm on or development environment I work within. One is just to maybe not rely on kint as much and use some of the other tools available to us. First, let's talk about the dump function that's available out of the box without any contributing modules.
White screen of death. Now, this is not mine. This is credit to Morton in terms of addressing the issues. The primary issue, you're calling a debug function, your files, your site isn't working, you can't even work with or see anything being debugged on the page. Now, within every single Twig file, we have this special keyword variable called _context. Now, _context is just an easier way of when you call the dump function without parsing anything in. It's going to be calling _context each and every time.
Now, parsing that _context into a loop allows us to do some cool things. Here, all that we're doing here in this code is going into that context, so all of the things being loaded by Twig on that file, and getting the key and getting the value. You're just going through the array and seeing each and every item. We're dumping out the value associated with the key so that we can see the values we have available to us, the keys that are causing us problems.
This is a great tool to put in if you're encountering the white screen of death thing, and you just want to find a value, just want to find a field and put it somewhere and you can't seem to do that with the debug function, this will help you get you in your way to doing that. Now, we'll talk about kint, in particular, there are some things that we always have to remember and it's to make sure that you parse in a specific variable.
If you don't parse in anything, it's going to try to load everything and it's usually-- There's been issues in the issue queue to address this but sometimes, you encounter the issue if the memory starts to overflow. If you parse in a specific variable, it's going to help you to load in just what you want into the debug functions.
For example, if you're trying to debug the content variable in and of itself and not the classes, not the metadata, the other things associated with the template, you just make sure you pass that. Don't try to just call kint with nothing in it. That will help you overcome the issue with the white screen of death.
Finally, credit: thpoul in terms of managing the levels that kint has within a preprocess function. This would be within either a module file or a theme file. You can paste in this kint requirement. Make sure you have kint class available to you and then set the max levels. Kint by itself is just going to try to load in every single item and metadata associated with that. If you have a node, it's going to try to load in your fields, it's going to try to load in any entity references and the fields associated with that.
There's a lot of different levels that kint is trying to do for you and if you have unlimited memory, you'd be able to see it all but in our own environments, usually, we're limited to the amount of memory that we have. Making sure that our max levels is set gives us enough leeway to dig a bit deeper into the content variables and what we have available to us so that we can still work with kint, still debug, and go through the process without not being able to access our site at all.
Now, a few other tools that we have available to us for a white screen of death is memory usage. If you have a modern computer and you're working locally, you can increase your memory usage by a lot. I wouldn't necessarily recommend it unless you get super frustrated, which I found super frustrating, and set the max 16 gigs, [unintelligible 00:35:06] load it.
[laughter]
speaker: Still didn't work.
Larry: Yes, still didn't work. [laughter]
If you want to manipulate your memory usage, and sometimes that can help, you can do that in your setting.php file. There's other ways to do it, but this is a really simple, straightforward way to do so. Finally, if you've tried all of these things and you're still having errors in your settings.php, you can turn on all of the errors to see all of them on your page to see what's happening. Is it something different, if you're working with a team, that someone else makes something that you can go to them for and find assistance for.
Our checklist for white screen of death is to, first, one and always, make sure we clear all our caches. Next is to resolve the scope of the debug functions. Parsing something specific into your debugger so that it's not trying to load the whole tree of objects. Third, the opening and closing tags of your Twig or preprocess functions or files. Make sure that they're there. Sometimes, you can accidentally delete them and you swear that they're there but they're not. It's happened to me a lot.
Another is to increase your memory usage temporarily, and finally, just to display all of the errors that are there. We're going to talk a little bit about where to go when all of these things within the checklist don't seem to help. When you've tried using debuggers and you still can't seem to find the values or fix the issues when you're working with Twig. Where do we go for this advanced help? Now, first, I want to describe what I would say advanced help in the context of what this talk is.
First is your site stops working completely. You make a change or you pull down a change from Git or from whatever version of tool that you're using and your site just doesn't seem to work at all by any means. It's completely unresponsive, you get a white screen of death. You try to log in and go to the admin page and look at the database log and it's blank too. You check your database and data is logging there. There's nothing new there. The site is dead. It's just completely dead. That would be one of the definitions of seek out some additional help.
The second is that the log page-- Database logging seems to be disabled, and nothing comes through. Finally, your memory usage is just out of control. These are all issues that with the sort of tools that we have available to us in terms of managing kint or managing our dump functions, or manipulating configuration files with how our development environment is structured, if all of those tools don't seem to work, that's the time to find some advanced help. You're to find and see if you can find someone that can help you.
Now, there are some resources to find that advanced help. These are some great resources that I personally have used and encountered in terms of resolving some very specific use case issues with Twig. Let's go and look at a few of them. Now, the first one is, Drupal Twig has a Slack. If you're not part of the Slack channel, make sure you sign up and join.
There's a lot of incredibly intelligent and smart, and helpful people there that if you have a problem that seems to be novel, something that you can't find and you googled it, people are there to help. The IRC channel is another one that's there. Drupal-twig, you can find that you have people talking great things about it or being really frustrated if you look at the hashtag. Finally, Stack Overflow is another place to find and seek out that advanced assistance with Twig.
Now, if you really encountered an issue with Twig that it seems to not being anywhere on the web, the best place to check is on the GitHub for the Twig project in and of itself. There's a lot of different contributors from Drupal, from Craft, from a lot of different PHP CMSs that are active and working on Twig to make it better and to address these issues. If you encounter something that seems to be like, "Oh, I don't know if anyone's ever seen this," make an issue in the issue queue or search it to see if it's there because it might be there.
Now, finally, with Twig, there are some really great ways in terms of leveling up, so like taking our Twig skills to the next level. These are just a few plugs of tools and things that I found super useful. The first one, if anyone is going to DrupalCon North America, there's a Theming Drupal 8 training. This has been consistent in terms of all the DrupalCons by the folks at Drupal 8. Last year, we sold out, by the time it was main camp-- I think right now there's still some slots.
If you're interested in learning more about Theming Drupal 8 and working the Twig and JavaScript and [unintelligible 00:40:09] those things, I'd recommend checking them out. Drupalize.me is another really great resource, in terms of learning more about how Drupal works, but also Twig in particular. They have some really good contents to dig a bit deeper into some Twig and some advanced usage.
KNP University, Ryan, and Lee are there, they're really super folks that have some great tools. Not just with Twig, but with Symphony and Drupal 8, a little plug for ChromaticHQ, a company I work for, we have a blog that we spend a lot of time curating and working with this sort of-- and writing about debriefing about the issues that we encounter in and of ourselves and we are working with Twig so be sure to check it out, and subscribe to our newsletter.
Finally, a really good way and probably the best way to level up your skills in Twig or anything is to go to a Sprint. We have a Sprint in this room tomorrow on Sunday. Anyone that wants to contribute or wants to check it out I would encourage everyone to join. I know the first time that I went to a Sprint, I was brand new Drupal and I felt like an impostor like I shouldn't have been there, but I would really recommend anyone that feels that way to just give it a try because people here are so kind in terms of getting people involved in the community, going through issue queue, and looking at different things.
Early on in my own career, I learned so much by finding mentors and finding people to help me, and a lot of them were from camps and conferences. Big shout out to the Sprints that are happening on Sunday and also throughout the conference. We have a bit of time for some questions and answers at the end. Thank you all for being attentive.
[applause]
Speaker: Do we have the URL for the slides again?
Larry: Yes. I notice it's not a great color there. The slides are up there. I notice that there are a couple of changes I've been making to those slides, the link will stay the same but the slide will be updated, I know there's one or two typos there.
Speaker: Hey, what was the [unintelligible 00:42:38] for the Twig filters that were special, so the field values, field label, reference entity, what was the name of that module?
Larry: It's--
Speaker: And why did I have to come to your talk to learn about it since you work for me? [laughter]
Larry: A little secret within the community, yes Twig field_value. I only discovered it earlier this year, so--
Speaker: Yes, good excuse.
[laughter]
Larry: It's been super good. We'll go through all of them, so it's right here?
Speaker: I have two hopefully really quick ones. On the first debug page, it was the list of all the templates and they all had asterisks except for one that had an X. Is that the one the template that's actually loading?
Larry: Yes.
Speaker: Okay, and then you used a loop.index0, and a loop.index later on. What's the difference between an index0 and index?
Larry: Okay, so let's find [unintelligible 00:43:29]. loop.index0, index0 is just the counter of the loop.
Speaker: Okay, so that's the [unintelligible 00:43:54].
Larry: Yes.
Speaker: It's the index that you use later on?
Larry: loop.index--
Speaker: Oh, there you go.
Larry: we're wanting to find the specific value equal to two, so we're not going through each and every one in the array.
Speaker: The first one we start at zero and it goes through all of them, and this one's [unintelligible 00:44:23] two.
Larry: Yes.
Speaker: You're only matching that value so it goes multiple.
Larry: This one, yes, were calling it just to match that one specifically.
Speaker: Why are you using index versus index0, what's the--
Larry: This is a good question.
[laughter]
This is a really good question. I've only used this in-- for the recording and everything the question was, why loop.index on this slide in particular and not loop.index0 == 2. For [unintelligible 00:45:05] I just like using the wholesale from Morton just copy and paste it and it always works so I've never gotten into the difference of why, but I know that this works so I would just use this.
[laughter] Sorry if I-- yes?
Speaker: I just googled it. It looks like the index0 starts at zero and the index starts at one.
Larry: Great, so index0 starts at zero and index starts at one so we [unintelligible 00:45:35] here in the slide to two. Yes?
Speaker: I was wondering if you've ever used on the Twig Tweak [unintelligible 00:45:43], sounds like it's very similar to Twig field value, it's one that I've used before. If you've heard of that one or if you've got opinion about that or--
Larry: Yes, so question is why I didn't talk about Twig Tweak or the difference between Twig Tweak [unintelligible 00:45:56] module and Twig field value. I think that, you can correct me if I'm wrong but Twig Tweak does a bit more than the field value. There's a bit more tools available to you to use that.
I'm not a big fan of the field value just because of the [unintelligible 00:46:12] reference sort of the easiness of that, I haven't used Twig Tweak [unintelligible 00:46:15] references in that context so I'm not sure it's as straightforward in terms of changing the values there, but Twig Tweak is an interesting module. I haven't had as much time using it as the others. Yes?
Speaker: I think he stole my question.
[laughter]
Larry: Here, Chris?
Speaker: In Drupal 7 I used KPR function a lot. One thing I liked about that one was that we run through and find the variable that you're looking for but you're able to get the relative path pretty easily. Is there any way to get a relative path with either the vardumper or kint or any of these other ones?
Larry: The question is the relative path using KPR is pretty accessible and is it as accessible with dumper or vardumper? First, just to clarify, the relative path of what in particular?
Speaker: To the particular variable. So in KPR, it spits out all these things, but when you've found what you're looking for you could double click it and it give you [unintelligible 00:47:37] objects or a raise, but how to get to this particular value. With kint and these other ones, these newer ones, seems like you have to draw your own map all the way to the belly that you're looking for. If it's nested six levels deep, you'd have to keep track of which array, objects, this, and all that.
Larry: I will say dump is not good at helping you find that in and of itself. Kint is a little better vardumper with the tool that we have here. It's a bit of both worlds, so you can try to click through and create that sort of pathway, but it doesn't always work. I think that an easier way of doing that is combining the debug functions with some of the standard Drupal calls.
In our use case, we're talking more specific within a pre-processor than like a Twig debugger in and of itself. Combining an approach of first, always try to see if you can retrace it using the same methodology you've had with KPR, but if that doesn't work, usually there's some things we can do to release the object that we find in there to find specific value or to find something using get or value or something like that.
Speaker: Okay, thanks.
Larry: Yes?
Speaker: Often when I dump the variable, I still have a hard time finding things like value I want [unintelligible 00:49:23] other than memorizing zero dot whatever.
Larry: Yes, usually the first approach is just to make sure you're calling your field name. [unintelligible 00:49:45] sometimes you don't have access to configurations to see the machine name of fields, but if you do have that access to call that and just call the value to see what gets output or to parse that into a debug function.
If not you can go deeper or try to open up the stack a bit more and just calling the content variable to see what's available to you.
Oh, sorry for the recording. The question was how do you-- It's not always clear how to get specific value for a field in and or itself like with this presentation in particular, with the URL. That's like the line that's probably that odd man out in terms of field values and then lists, select list fields. Those ones usually are a bit different in terms of how you approach them. Most of the time it'll be like your entity or content. your field name. value to find that value. Yes.
Speaker 2: Towards the beginning you had [unintelligible 00:50:50]. I'm assuming that [unintelligible 00:50:59] Drupal specific Twig function, and if it is, what are the Drupal specific [unintelligible 00:51:05]?
Larry: Yes, that's a really good question. The question is in this talk we had file_URL as a Twig function and that is a Drupal-specific function. There's a handful of Drupal specific functions. An easy way to do this, we just looked at the Twig documentation online. I think that it's less than-- it's like a handful of Twig functions are very specific to Drupal and file_URLs is just one of them, so just the Twig documentation for Drupal will have those filters and functions be to you. Yes.
Speaker: I don't think you had it in your slack but I encountered a problem where I had to Twig debugger, and I was trying to get the value for this Boolean. When I output the value to an actual like Twig debugging text will be in there as well. I had to convert it to a string and then strip it and then look for faults. Is there any way to remove that from the dump when you're getting just true or false value?
Larry: Yes, so the question is when we work with boolean fields, sometimes when we try to debug them or try to assign a variable to true or false nature, there are always usually populated, like when you try to check for it, there's things usually within there. That's been a huge frustration personally with mine. My own brute-force approach is to pre-process it, and do custom approach in terms of like creating a custom variable and then using that to determine whether there's true or false, so those values.
The consistency of using some of these things like there's metadata or other things associated with those content things that are like [unintelligible 00:53:08] specific and like somewhat frustrating to dig a bit deeper into but I would just try to pre- process it instead of trying to handle it within Twig and using the var or using all these different filters to go through it. Yes, if you want to talk afterwards, you can talk through the--[unintelligible 00:53:29] Any other questions? If not, thank you very much for having [unintelligible 00:53:36].
[applause]
[00:53:48] [END OF AUDIO]
