 Okay, can you hear me? Okay, I like to get really close and then do like a creepy whisper. Okay, obviously. We're gonna be talking about menus, paths, and breadcrumbs. It's a pretty simple topic. You would almost think that Drupal would do it well out of the box. But you may have found it doesn't. So hopefully I'm gonna give you some chicks and tips to make perfect menus, paths, and breadcrumbs without doing a lot of extra work. And hopefully it won't take a whole hour. How hard can it be? And then we can move on with our nights and not be here forever and have, you know, no more troubles. That's me. I didn't put a picture because you can already see me. My name is Jodi. I am the CTO of ZivTech in Philadelphia, Pennsylvania, USA. I'm also the co-founder of ZivTech. We have about 25 or 30 people there now. I've been doing Drupal for almost 10 years. I'm basically a glorified developer. But I am very interested in good site building. I do a lot of training, architecture. Mostly I focus on my team and trying to ensure the quality of everything that we do. And so one of the things that I fixate on is the quality of our IA. Because I think when you're, you know, making a website, it's pretty important to get that right. Oh, so these slides have some trickiness to them. So as I go through the slides and tell you about different things, it's going to, the slides themselves are hopefully going to reflect the harmony that I'm trying to tell you you should have on every site. So the first thing that we're going to talk about is menus. And so I'm showing you an example of a menu at the top of the page. And then we're going to talk about paths. I also snuck in an extra menu on the side. Sometimes you can display the menu, like a section of it on the side. That can be a nice way to go. Paths, I've got my little path down at the bottom of the screen. So you can see right now my path is definitions. And then we're going to talk about breadcrumbs. And if you noticed, a breadcrumb has appeared. Whom, about definitions. Okay, so starting off with menus. So I think that what you really, the mental model that will really help you understand menus on any website is to think of a tree. And to think of all of the pages of your site as belonging in one single tree. Don't have more than one tree. Fit everything into it. And at the very top is your home page. And one of the properties of a tree when you're putting all the pages in it is that you could actually only put the page in one place in the tree. Okay, so you can't put it in multiple places and you're not going to have multiple trees. Sort of an even better than a tree is to think of a file structure because ultimately that's much closer to what we're doing here. We're organizing pages into a hierarchical file structure. And ultimately there's only just one outer directory, not more than one, because you can always put them together into one. And you're not going to have a document in more than one place in this file directory. So the reason that this, the file directory system works so well is because websites, static websites really just are a file directory with all the different pages somewhere and it makes a lot of sense so you would have like your menus directory and then all of your pages within that. But of course Drupal doesn't have an actual file system where it's keeping your pages. So we have to sort of try to emulate that feeling because that's a good structure that people can understand where documents are. Okay, so once you start thinking of all of your pages being part of this one hierarchy, this one menu tree, that doesn't mean that that menu tree, which is sort of like an abstract, maybe you have it in a document somewhere represented. But that menu tree is sort of an abstract and it doesn't have to be the same as the actual menus that you have in Drupal because what you're really trying to accomplish in Drupal is to just display the menus in some certain way. So if you have a footer menu and you have a couple of links in that footer menu that maybe don't correspond exactly to where they are in the menu tree, it doesn't even really matter if you make the footer menu a real menu or you just put some HTML in a block and put that in the footer. People aren't going to be updating it a lot. It doesn't actually matter. It's just more of a display of a menu than that it actually is your real menu tree. But when you think of things as that there really is a menu tree and you try to make your main menu as closely match that as you can, then you won't end up with sort of all of these extra menus. So you see a lot of sites where when you go to the menu configuration, they'll have the about menu and the academics menu and they have a separate menu for every little section of their site. That sort of makes a mess out of things because it's just a lot harder to maintain and it's harder to think of things and remember that they're all part of one tree. However, if you're using organic groups, in that case you really do end up having to have separate menus if you use organic groups menus. You have to have separate menus because different people can manage them. So you have to be somewhat practical with what you're doing in Drupal but still maintain this perfect menu tree in your mind and I'll tell you how you can actually maintain that. So the biggest problem in terms of IA and Drupal is that you can have multiple menu items for the same page. So nothing is preventing you from doing that. You can only put a node in one place in the menu when you're editing the node but if you go to the menu administration you can add it as many times as you want to in all different places. And sometimes your client or your design is really requiring that. So a really common example is that people will say that they want the contact page underneath the about item in the menu but they also want the contact page to be in the footer menu not under the about item. So the problem there is that a lot of things depend on the menu position. So one of the things that depends on the menu position is the active menu. So once you start putting pages in more than one place it's no longer clear how the breadcrumb or how the active menu like which part of the menu is highlighted which one it should base itself on because it all bases itself by menu position. So we sort of have like a cardinality issue here because you can only have one copy of a page and it can only really have one path because you can only see one path in the little path area URL bar. It can only have one breadcrumb because you can only see one breadcrumb on it but yet it could be in the menu in multiple places. So how are we supposed to base this one path or this one breadcrumb off of it being in the menu in multiple places? And so you see all of these all kinds of contributed modules that are trying to solve this problem in all kinds of strange ways but the way I like to think about it is just we have this problem all the time in computer science we have more than one of something but we kind of only need to have one. So what we do is we just call one of the many canonical and then that's the special one that the other things are based on and the other ones exist but they're not canonical. So in order to have a canonical menu position I think the easiest thing to do is to just use if you're using a node or some other entity whatever you pick for the menu position when you edit that node you can only pick one thing there so let that one be the canonical one if there's more than one and then if you need to change the canonical one just change it there you don't need a whole other interface whole other modules. So this is a patch at this URL that does that it's like a five letter patch so I just run that on all of my projects and I don't have any more confusion. Where's the store? The patch. Which is the canonical one? The store on the menu item or on the node? Oh it's stored in the menu item so that's already actually happens the Drupal keeps track of whether a menu item is customized or not customized it actually already has that data it just doesn't really use it for much so I just favor in the sort to use the customized. Okay so one module if you don't know about it yet that you should really get into when you're working with menus is menu block so this is just an example of the types of stuff that you can do with menu block so here you're seeing on this site they have their main menu it may or may not have drop downs but it shows you the top level of the main menu and then on the side bar it's showing you this section of the main menu so since we're in academics it's showing you the academic section of the main menu so instead of making a separate menu for academics you can put everything in one tree in the main menu and then you can just set up a menu block and you can just configure it to say oh always show the second level and lower depending on which page I'm looking at where that is in the menu then show the right section of the menu and that makes it a lot easier to get around big menus as opposed to just trying to force people to use huge drop down menus where they have to hover and get around multiple levels so menu block is a great module you should yeah you just go to this question was whether you have to add custom code use menu block you just add that module and then you go to blocks and you go to add menu block the configuration is a little bit tricky but as long as you know what you're trying to accomplish you can get it right as long as you realize that it's possible to have to show different levels of a menu and it's possible to pick the starting point based on where you are right now it's pretty easy okay so kind of wrapping up menus a little bit just a couple of don'ts to do with menus hand made menus again I don't really have any issue with putting a couple of links for a footer that aren't in a real Drupal menu but some people I've seen will make their entire navigation like HTML that nobody can edit if you're working for an organization that really doesn't change its navigation very often and they want to have a whole committee to do it and deploy it then I guess that's fine but there's a lot of nice things about the Drupal menu system that make it worth using like how it you can translate it, you can also do it does access control automatically in the Drupal menu system so you can put things into your menus that not all users have access to and they just won't see those items in the menu so you can kind of have secret extra items so this is an example of a crowded menu this was a client that I worked with a long time ago and we just kept telling them they had too many things in their menu and they just couldn't seem to ever agree on combining things so in the end result they have this bar of things that just go across the top that you can barely even read because we had to keep making the font smaller and putting them closer together and it's not a big you know this is the population studies center like you would think if they have that many things in their menu that they must be like a multinational organization with 10,000 employees but it's probably just a handful of people who just can't agree on taking anything out of the main menu ultimately people don't like to spend all day drilling down in menus to try to find something they can if you put things in normal places like most people will assume that people maybe would be underneath about us and that they could just go to about us and then find people you don't have to put that in the main menu there's a lot of other things here that you can combine and make this a lot easier to deal with okay and just wrapping up menus I don't like to use a lot of contributed modules for menus other than menu block but most people like to use admin menu just to make it easier to administer your site and menu position can also be a useful module so menu position lets you take pages that you don't put in the menu and set where they should see themselves as being in the active menu trail so for example you could say all of my news items I'm not going to put each news item into the menu but when you look at a news item I want the news section of the menu to be active so you can set that up okay, paths are next so not every web framework calls them paths but in Drupal we call the part of the URL that's sort of within the Drupal site we call that our path and it's also sometimes called URL alias if it's not a system path you can have an alias for it so like a system path would be node slash five and an alias would be about so URLs I think are very important because they're actually visible on your site so you shouldn't just not take them very seriously and just focus on the rest of the page because a URL is part of what the visitors see on your site it's part of how they interact with your site and it's also an important part of your IA because you can use the path to show everyone not just visitors but developers and everyone else where you are in the tree so paths should be restful so sort of like an API should be restful paths on the internet are meant to be restful which means that just having clean URLs like Drupal promises you that it's going to give you these clean URLs that aren't going to be like question mark Q equals something something and just having human readable ones which is what path auto module gives you is not enough some of the other things that paths really should be is stateless so stateless means that if you go to the same path again that you'll get the same page so in Drupal that's not exactly the case because we let people log in and then they might be seeing a little bit of different things on the page depending on who they're logged in as so we kind of make an exception to that in Drupal but still in general they should be seeing the same page because otherwise it's impossible to send people URLs and say hey I have a problem with this page or share it with your friends or whatever there's no point in having a URL if it's not stateless you see a lot of web applications that are not stateless so you try to copy a URL from some stupid web application and then when you click it later it doesn't take you where you were at all so they're kind of sort of a sin against the internet since the whole internet runs on URLs if your URL doesn't mean anything you don't really have a website you have like a web piece of trash so they should also be hackable hackable URLs means that if you take away part of it between the slashes that you'll go to sort of a parent page and they should also be unique so you shouldn't just have multiple URLs that take you to the same page now one of the things that people get into a lot is that they have some requirement that you have to show a different URL depending on how the user got to the page okay so they'll say same people say that they want you to have the contact page both under about and not under about they might say well if they clicked on about and then they clicked on contact now I want the path to be about slash contact but if they went straight to contact now I want the path to be contact well a lot of people fall for that and they start hacking all kinds of stuff together when really you want to explain that that's not the best idea because when you talk about a URL as an address an address doesn't care how you got there so my address right now well I don't even know what it is something Barcelona but my address now is not Philadelphia, London, Barcelona nobody cares how it was that I got to Barcelona that's not my address my address is just where I am and that's how URLs are but there are times when you want to display the same information but slightly differently so an example of that would be if you were if you're selling tickets, concert tickets and you have a page that's about a venue but depending on how they came to get to that page about that venue you want to show additional information on the sidebar that's relevant to them so if they clicked on that venue after they were looking at Miley Cyrus then you want to show them some more information about Miley Cyrus on the sidebar so there's a few different ways you can do that that makes sense but so one is that you can kind of do like personalization and keep track of what the person was looking at separately from how your IAA is working but another is that you could actually have separate displays of the content that had separate URLs that showed even though they were showing the same node were not the node display itself so for example you could have a panel's page that could accept as an argument who the artist was and then it would always show as part of that page the venue information but it would also show different information by the artist so you don't always have to only display a node when you're trying to display a page and then you could have more options if you need to do strange things with your URLs okay so canonical paths is a sort of similar Drupal problem as canonical menu items so this URL is to a Drupal issue where the issue is that if you create a URL alias for your node and then you go back and edit the alias it's possible to get into a situation where the alias that you put in when you're editing the node is not used as the canonical alias when you're viewing the node so you can go in there and edit things all the time and it doesn't really have any effect because just like menu items Drupal lets you have more than one path for a page but ultimately you can only see one URL at a time right so we have to again have some way to pick which URL is canonical and so there's a little patch um in that link that just says that whichever one was the newest path I think is that we're going to use that one as the canonical one so at least we have like currently in Drupal 7 there is no system for picking which one is the canonical path there's no order by on the query that looks up the path so your results may vary if you have more than one path of which one is actually going to get displayed so I always use that path and that patch did um get fixed for Drupal 8 so Drupal 8 actually has working canonical paths another good thing about Drupal 8 is there's been a lot of emphasis done to make paths more stateless so for example in Drupal 8 if you go to slash user it'll redirect you to slash user slash one and the reason that's better than what Drupal 7 does so in Drupal 7 if you go to slash user you're just on slash user and you're looking at your account page but it's the path to slash user so the problem with that is that you can say to someone oh I've got a something isn't showing up for me on slash user and you send them that link but that's not a stateless link that shows different information for everyone who goes to slash user so if it automatically redirects you to slash user slash one it's the actual stateless URL that you can share with someone that makes a lot more sense okay so path auto I think most people will be familiar with and path auto does exist already for Drupal 8 but you have to get it from a github project which you can find in the path auto issue queue so a lot of people use path auto but don't do a very good job at configuring it probably the most important part so these are so this probably is the most best tip that you're going to get from this whole talk if you didn't already know this which is that any type of content that you put in the menu a lot you should set its pattern something like this and what that's saying is that the URL of the page is going to be whatever its menu parent is slash title so that way whenever you add a page and put it in the menu it will automatically have a hackable path that has the right structure so for example if you put the contact page under about in the menu the path will automatically be about slash contact which matches the tree of where it is so it's about slash contact and you can also set these in a custom way if you need to so if the page is in the menu more than once and then you have to try to distinguish which it is you could set your path manually to put it exactly where it's supposed to be in the tree so because you can only have one URL I think the most important thing of menus paths and breadcrumbs all working together is to have perfect paths get your paths perfect and everything else is going to fall into place so another so for the content types that you don't put in the menu typically what you're going to have is the plural form of the type slash the title that's assuming that you have an events page that has a path of events if the path of the events page was something else then put that there so you have to set up these patterns so that everything is going to fall in the right place in the tree and if there's ever a point where you can take out part of the URL and it no longer brings you up to the right landing page then there's something wrong because your paths aren't hackable and you can always if you're still doing development you can always delete all of your paths and then regenerate them all and have them straight what I like to do is I like to set in path order there are settings for what to do if the path is changing I like to set it to delete them all whenever the path to delete the old one when you're making a new path alias and then when I launch it have a couple ways to make sure this happens automatically so the old way was that we would have a launch checklist and sort of the new way is I have this module called Habitat that lets you set different modules to be on or off in different environments so I try to make sure that automatically the path auto settings change when you launch because the worst thing that can happen is that it deletes the old aliases when you're live because now you're going to lose aliases and that's really bad for SCL do you have a question? so he's saying the problem with this path auto pattern is that if the path above your page changes then you're no longer matching up and I have seen I forget the name of the module but I have seen a module that attempts to fix that although it sort of scares me what it's going to what kind of havoc it's going to potentially cause but I mean I find that that doesn't happen that often once you go live with the site they really once you kind of have a tree in place it's not that often that they're moving some big section of it and if they are you can kind of deal with it when it happens I haven't had too much trouble one thing to point out here that's kind of interesting about this is you won't even see this as an option when you're configuring path auto and you open up all the tokens node menu link parent URL but you won't see path as an option it's a secret option so like the best the best token setup is like kind of a secret option so apparently you can always put if you don't put path it puts like the full URL like HTTP and everything but apparently you can always put path after URL in tokens some other contributed modules for paths that I use a lot pretty much everyone uses redirect module these days because there's always some reason that you want to do a redirect especially if you're bringing in legacy content you have to add a bunch of redirects link it is a module for adding links mostly to the WYSIWYG as like a WYSIWYG button but what I like about it is that it's smart about the paths that it puts in so into the WYSIWYG because a lot of people have problems where clients are adding content on the dev site and they keep on putting in absolute URLs to the dev site in there or they another problem they can get into is if they put a link to an alias and then later on that alias changes and gets deleted so link it helps to make sure that they put in proper links and makes it really easy and pathologic is sort of similar in its goal but it's actually an input filter so if you add pathologic to one of your input formats then it will automatically try to like clean up the links that people are putting into the WYSIWYG and try to make them make sense you don't have those problems so there's a lot of websites out there with really bad paths the Drupal ones are usually not that bad because we have pretty good tools for paths to begin with but one of the problems you run into is JavaScript only links separate mobile sites where if you copy a URL from a mobile site and you email it to someone it doesn't take them to the same place that's sort of a crime against the web that seems to be happening less these days and then just unhackable paths where the path is just doesn't give you any context of where you are okay so probably worst of all in Drupal out of the box is breadcrumbs so the first I guess issue with breadcrumbs is you know maybe shown by the name I don't sure if they picked breadcrumbs because they already knew it wasn't going to work cause it's like when you go to a lot of Drupal sites the breadcrumbs seem to be missing completely because the birds already got there I guess or they're missing a lot of times you go to a Drupal site and the breadcrumbs always just says home like on every page I guess the rest of the breadcrumbs are gone so I guess that's why they called it that cause they're just going to constantly be missing if you go to the the website for this conference and you go to a session page or probably anywhere else you won't find a breadcrumb because a lot of people in Drupal have found that the best way to deal with breadcrumbs is to not have them because then they won't have to get endless complaints that something's wrong with this breadcrumb and that breadcrumb but a breadcrumb basically is just to me a human readable path and that's sort of what I'm trying to show in these slides so when it says that I'm now at home slash breadcrumbs and then my path at the bottom is actually home slash breadcrumbs I like to put slashes as like the the placeholder between the sections of the breadcrumb cause that reinforces the idea that the breadcrumb is really just another version of your URL if you keep that in mind then it should always be 100% clear what your breadcrumb should be saying because it should be saying the exact same thing as your URL and if it's not then that's a problem so in in Drupal 7 they base the breadcrumb the breadcrumbs on menu positions now that is a huge problem because like I was saying many positions don't have any canonicalness so you can put the same page in multiple places in the menu and then the breadcrumb will just be made on one of them right and you have no way of controlling which one the breadcrumbs being based off of so you have constant I think in earlier versions of Drupal it was even worse because the breadcrumb would only be based on menu position if you if it was in the navigation menu or something it wouldn't even work on the other menus right it's like you would just really just never the only times the only place where menu positions or breadcrumbs I'm sorry and many positions really work properly in Drupal is on admin pages they work great on admin pages admin configuration they always work great there so maybe that's why they never really get better in core because all the pages that are in core I guess they work fine right it's just the actual websites that we build that have no functioning breadcrumbs there's so many different breadcrumb modules out there one of them is called cancel breadcrumbs you can make custom breadcrumbs where you have to create your own rules for how the breadcrumbs are going to get made menu position can also be used for breadcrumbs menu breadcrumbs path breadcrumbs so ultimately out of all of these the one that I've really I tried all different ones for many years but the one that I'm really into for is by path and this is just a really simple module probably does something really simple similar to path breadcrumbs and other ones but all it does is it sets your breadcrumbs based on your URL so as long as you make your URLs right you don't have to worry about your breadcrumbs at all and they'll always be right so if my page was breadcrumbs-drupal7 it will determine if there actually is a page at path breadcrumbs if there isn't then it won't include that and then it'll put your breadcrumbs to match your path which is almost always what how it should be the other one that I I haven't tried yet but I think might be possibly even better is menu trail by path because that module says that it does the breadcrumbs by path but it also does the menu trail so that means it'll also show you which section is active in the menu and that can also do things like show the correct menu block on the sidebar based on based on where you are in this menu trail so that one might be really good too but I think basically as long as you forget about people trying to base the breadcrumbs on menu positions and just base them on URLs you will have no more problems with your breadcrumbs so in drupal8 this is a good post by Larry Garfield about how breadcrumbs work in drupal8 it's a little bit super complicated the bottom line is that they're based on paths now so you won't need an extra module and everything makes sense I tested that today it works great just get your paths straight and you're all set you can use the same path auto configuration that I showed you in drupal7 or drupal8 so basically your your process is for paths and breadcrumbs and menus it's just the only thing that you have to do manually is set where a page is in the menu if you set where it is in the menu the path will come out right and then the breadcrumbs will come out right and nobody has to really know anything or do anything special everything works great so I keep an install profile we keep an install profile at zivtech called bear and if you can look at that or fork it or use it or whatever you want but that's where I solve a lot of these problems that I feel like should be part of core and make things work well out of the box so it has a few different patches that I mentioned for paths and for menus and fixing the canonical problems and it has like the path auto settings already set right and things like that so you can take a look at that if you want because I don't like to spend time on every project trying to get this stuff right again and again that is it questions I think it's supposed to use the mic I guess if there is a recording I was just going to say again a moment ago you talked about the breadcrumbs by path so for example when you said breadcrumbs in Drupal the path would usually just be breadcrumbs Drupal because of things like in and off and under that it strips out does the breadcrumbs still follow as well so you'd lose those kind of yeah well no because the the breadcrumm will build itself based on the menu titles so it will look up those paths and then find out what it should put in for the title as like the human readable version so it comes out looking right I think it uses the menu title if there is one I don't know what kind of magic it it's doing because not everything is necessarily in the menu yeah you can also do a couple of different versions of that path auto configuration like you can do one where it takes all the menu items that are your parents and joins them all together there's a couple like different variations but it's kind of mostly similar results so yeah I mean that's sort of the simplest is if you just take whatever your parent path is and then add the title to the end but you can put like the menu item name instead of anybody else yeah can you say that try this pattern and if that doesn't work then try another pattern I think it can be a concept well one thing you can do one thing that path auto does do is you can you can put a couple different tokens in there and then if some of them come out empty it'll just skip them so you can kind of use that and then I had shown then and then something isn't in the menu it'll just show the title so that'll be fine but if you want to get into something more complicated with like if it's this then do this then you can make your own custom tokens like you can make a like hook token info and make a custom token and put all the logic you need to do in there I'm not really sure this question actually so from your presentation you said you recommend like all websites just have one menu menu tree the problem is actually if the menu goes too big what you think that's the problem and plus actually the example example you show about the website that have very huge big menu item collections why do you not recommend them to change that well the second question is easy I recommended that many times that they should change that so yeah they should definitely change that sorry the first question was who remembers that far back so basically menu is really big menu so the menu what I say is actually very heavy cached so if it's menu actually if a menu tree grows up very big it's really bad for people change the menu so when you change the menu you have to refresh the cached that's what I understand so I feel like why you suggest people the website actually only have one menu tree well first of all most sites don't change their menu that often right so maybe once a day it's certainly not like it's certainly not like they're changing their menu like every five minutes and then it's wiping their cache you know it could if that was the case on your site then you have to you know look into special ways of caching that but so typically that's not really like a big issue and also in terms of administering a big menu I think there's a module called big menu that makes it easier to administer it when you go to the menu administration page and you can kind of open up sections of it to deal with because otherwise it gets to be hard to drag it around if it's huge but the main reason that I think you should usually just put things into one menu is because it makes a lot easier to do things site-wide like you can just say oh site-wide I'm gonna have this side block that shows the sub navigation instead of saying oh I'm gonna make 12 different sidebar navigation blocks depending on which section of the site you're in and then if somebody wants to change the styling on them or something else about them we have to go back and change all 12 of them right so I'm just trying to think of your site as much all the way through the same as you can just makes it a lot easier to deal with your site yeah I think the menu approach can be a bit of a problem with dynamic content that really shouldn't be in the hierarchical fixed menu so I think it's mostly for static content I guess if you do this menu like you don't want to have a menu with all Facebook users or with I mean Facebook users are easy because they shouldn't be some hierarchical it's just user that's it but there are other sites where you have a lot of dynamic content but that has some kind of implicit hierarchy but it doesn't have this fixed menu you don't want to put that all in the menu right so you don't have to put everything in the menu tree well you don't have to put everything in the actual Drupal menu but it can still exist in your conception of where it is in the menu tree right so you don't put every news article into your Drupal menu but you know in your IA plan that they all fall underneath news so you can make as long as you can make your paths reflect where they are in your sort of mental model of the menu tree it's okay if they're not actually in the menu I think that that works if it's just one level below the deepest menu link so if they always have one parent that one direct parent that is in the menu like for instance if you have products with taxonomy then at least you would have want all the taxonomy terms to be in the menu so if you if you get one level deeper like if you have one level of terms that is so many terms that you want to put them in menu and you want to make the breadcrumbs best on that for the product pages and maybe the product has one sub page where you see some aspect of the product I think then you no longer in no longer work with this menu position stuff well that's what I'm saying to do it all by path so just do the breadcrumbs in the menu positions all by path and then it doesn't matter what you actually put in the Drupal menu or didn't put in the Drupal menu and it all just matches the tree okay anybody else okay please hit the evaluation unless you didn't like it and then just don't worry about it alright thank you