 We're going to show you a lot of demo, because the best way to see and, well, experience this place really is, well, to see it. So, that's the first slide. Okay, show you your turn. So, it's still my turn? Okay, I'm sorry. Very important thing, we are Crimson Crew members. That's our van. Somehow our boss managed to crash it somewhere in Germany, so we came with another van. So, well, we're Drupal Ninjas. All right, the outline. So, now that you know how crazy we are, the agenda for today, we'll talk about the philosophy behind the S. Why was it built? Then, as Mr. Sventl mentioned, we have some demos going from the very basics in this place with really more advanced stuff. We'll also touch on the search integration, some advanced use cases. Then the combination with panels, which is quite powerful. And we know that a lot of people think it's a competition, but it's a powerful combination, if used well. Then we'll go to a slightly more technical level with the API and performance. Very important too. We'll quickly touch on the future and there will be time for some questions and answers. All right, philosophy. So, why did we write this place? We started, I think, three years ago now, where we had really large, complex websites at work and we were getting quite frustrated. I mean, I'm a developer, he's a teamer, so we have to work together all the time. When we had those large projects, we had a lot of complications, especially when your project is live, then you get new feature requests from clients and stuff like that. And then we really get into trouble because changing stuff with the Drupal teaming layer is extremely flexible. For example, you can do basically anything. You have teaming functions, you have template files, you have pre-processed functions, you have your template files. Then you have also teaming settings. So, there's a lot of stuff scattered around. You also have views. You can also use views to add fields to a page and stuff like that. At the end, you don't know anymore where your content is styled. So, you really have to have your own roadbook because when a client comes in and asks you for a change, you can be really in trouble, especially if you haven't created a project yourself. If you take over a project from someone else, you can be really stuck sometimes. You really have to search in a lot of possible places. I've seen some really, really cool stuff. We were really frustrated with that. We started thinking. One of our first goals for this place feed was the ability to manage your layout from one central place. You would have an interface where you have one page and then you see all your objects in your Drupal website. Those can be nodes. Those can be users. Those can even be views. It sounds weird. We'll see a lot of stuff later in the demo site. Also, it eliminates template files, which sounds weird. As a developer, I became a little bit frustrated because I had to provide the template files for my teamers because my teamers don't know that well PHP, which is ... Oh, sorry. Other teams. No, not to generalize this, but it can be really frustrating because I'm not really interested in theming stuff. I just want to make cool modules and hack into core and stuff like that. I don't want to provide my teamers their template files. Also, PHP code, if you went, for instance, to the security session, there's a lot of stuff that you can misuse with PHP exploits and stuff like that. I've seen template files with queries in them, which is ... Whoa. Please don't do that. Our goal was also to eliminate template files. I have a really cool point here, focused on ease of use, portability and manageability, which I completely forgot why I wrote that. Very important, this play suite is not a CSS tool. I'm getting a lot of questions on my issue queue. I'm doing this with a class and stuff like that. That's not what we've built this for. If you want to use CSS, use Sweaver or something like that. A little marketing. All right. I'll hand over to Jean-Yves now. He will be showing you a lot of demo stuff. We'll have to switch as well. Switch. Cheers. Before we show this play suite, I just want to give a quick demo on how you can manage your layout without this play suite, using the normal field UI and templates. For that, we've created a very nice Chuck Norris fan site. Any fans that are here can applaud or cheer. I don't know. A lot of fans. That's good. What you normally have, if you look in Drupal at structure content types, you get a managed display link. What you see here is body image, and you can move them around. You can hide them, but that's basically it. The options are there, but they are quite limited. From the moment you want to fiddle with your post dates, comments, all the other extras that are printed, you have to go to template files, which is nice to have this, but if you can't go 100%, then it's quite useless, in my opinion. If you look at the slides again, this one, yep. You get a mix of template files and field UI. Disadvantages are that template files are not, in my opinion, theme-friendly. It's not because you can write CSS and HTML but you should be able to manipulate PHP files. Maintainability is an issue. You have some stuff in your database, some stuff in template files. The limitations, you can't add extra fields, extra view modes. And then the fourth point, you add it. I don't know what it means. The way to mess containers. We'll just skip that one. You can't, indeed, use templates. So you have your fields in a list, but you can't say put this one left, this one right. So you'll have to write some complex CSS for that, which can be a pain. In comes Display Suite. I'll just give a demo first so that you can see what it's all about. Back to Chuck Morris. It's a module that consists out of three, one core module and two submodules. And that's Display Suite. And then two extra modules, extras and search display, which I'll add on later. Voila. If I go back to the same screen, structure, content types, I have the same link here. Everything looks exactly the same, but I have now the option to choose a layout. I'll just open the page itself. So let's say the acting career of Chuck Morris. This is your default node. You have your submitted date, your content, all the images in a row. Not really fancy. Comments at the bottom. So let's start to fiddle around with it. If I choose a layout, I'll just take the one column, a very simple layout for this demo. I'll switch to full content. So this is the full content page that I'm looking at. My mouse is reversed. It's nice. So full content, body image. I select my one column layout. I'll leave the rest as is for now. Save. And then all of a sudden you get all these extra fields. Every field that's in your nodes is now available for displaying or hiding. So let's say I want my body, of course. Don't care about the post date. I want my image in my body. You've seen six or seven images on the page, but with a simple click, I can just show the first one. I'll even add some image cache to it. Medium, link to nothing. Okay. Comments should be at the bottom. Voila. And then save. And let's look at the page. Voila. So I have my image here, my body. The comments at the bottom. This is the very basic use of DS. Just manage your fields. Fill around with it. The main benefit here is that you don't have other stuff sitting in your template file. Stuff that you can't manage like the dates, like other small things that are added in the node template file. You don't see them here. It's just what you manage is what you see. Wow. Thank you. So there's more to this plate feed, of course. We've moved around these fields. You can also add custom fields if you want to. We'll start with a dynamic field. The names are a bit different. Difficult, I mean. So what you have, you have a code fields, plain PHP. You get your element that you want. You can play around with it, add tags to it, manipulate it. Use tokens, indeed. Then dynamic fields. I'll show you an example. This gives you the C tools layout, or the panels layout, as you might call it, to add custom fields. You can add entire blocks into your object. And P process field is way too technical, so I won't touch on that. Dynamic fields. This might look familiar to some people. I'll call it all images. It's a node entity. Save. What I have now is this all images field. I'll just add it above my comments. Then I'll select content for it. I go to my node image field. There should not be a label for it. And the formatter should be image. So the image style here is tunnel. That was the one I was looking for. And link it to the file. Finish. Updates. Save. Then reload my page. And I get all these images nicely at the bottom. I've added some CSS in preparation just so that you know. It is not a CSS tool. So we've added fields. I could add block field too. I'll just take a very simple one. With a very proud to use Drupal. So I'll use the Drupal block nodes. You see all the blocks here that you get in your block overview screen. So I'll take the powered by Drupal one. You could choose a layout being rendered the full block or just show the title and content or just show the content. It's a detail but we've had it as use cases. So I'll just leave it as default. Voila. Added between my content and images. Save. Reload. And voila, it's here. So in this way you can really manage your node template. You can add whatever you want. You can add custom fields. You can add dynamic fields, block fields. You can really mess around with it. Then let's look at the home page because we have some teasers there. Not so useful. Voila, the short way. So these are teasers. I've mentioned view modes before. For those who don't know what view modes are by default you get several view modes offered by Drupal and they are in fact a certain perspective on the same type of content. So we have in this case the teaser, which is this. We have the full content, which is your typical node detail. And there are some more technical ones but teaser and full node are the main used ones. But I don't like the layout of this so I'll play around with it too. Select my layout first. I'll take my favorite, the fluid three column stacked. You can hide empty regions, which is nice in this three column version. You can hide left or right if you don't have any content. The rest stays as is. Voila. I can put my image. On the left, then the body in the middle. Maybe post it underneath it. Voila. And the title of course. Voila. It's linked. You have several extra options like link it, which wrapper do you want, which class do you want. But it's okay like that. Voila. Save. Reload. It's better. Oh, my images are still here. And that's because I haven't changed this to one. And this to the thumbnail version. Voila. This should be better. Nice. Now this teaser looks great here. But if I go to my active career page, I have a list of other articles in my sidebar. But it's a bit too busy for me. I don't want to show all the text again. I don't want to show images. So in this case, this is a typical use case for an extra view mode. You want the same content, but displayed otherwise. Normally, if you use views, you would select views fields. The disadvantage in that case is that you have different HTML output. It's really frustrating as a teamer to have HTML printed by your node template, for example, and then views HTML. You have the same content, but different HTML. So duplicate CSS. In this case, let's add a view mode. We'll go to structure, display suites, view modes. We'll add a custom view mode. I'll call it small teaser. Voila. Node. Save. If I now go back to my article, I can activate it, small teaser, so that we can use it for this specific content type. Save. And you just get it next to the other tabs. So what do I want? A very simple layout. I'll use one column. Save. Just give me the title. Make sure it's linked. Voila. Save. Now, if I go to this page and I change my view, this is where we jump to views integration, which is quite important too. Normally, in views, you have the option to choose or to print custom fields, or to use a view mode offered by Drupal. In this case, we also have display suites. If I activate that, you get all your display suites view modes. So there's a lot more options there than just full content and teaser. So I'll change the small teaser here. There are some more options here, which I'll show later on. Voila. Apply. Save my view. Voila. I just get a nice list of titles. Next up. Just have to think, because it's quite a big demo. I have to cheat first. Home page, view modes, views integration. Yeah. Okay. Views integration. Let's go into more details on the home page. It's a typical use case. It was one of the use cases for this in the beginning too. You have this home page. You have a list of six items. But the designer wants the first item to be different. There should be an image in there. More content. It happens all the time in our business. So we had to invent some way to do it too. So if you go to views, and then this is the front page, which I'll be changing, I will choose to use this place view too. On this view. By default, it should be the teaser. So the one that we saw just now. But you can also choose alternating view modes. Which gives you, for every item, that you show on that page. In this case, it's limited by the pager. So I've added only show six, and then show in pager. So for every item, you can choose which view mode you want. I'll leave it to teaser, teaser, and then change the others to small teaser. Voila. Save. And nothing happens. Because why? Was I too quick? Caching? Just try. It shouldn't be the issue normally. Yeah. It should be the right view. And I've saved it. It's not the articles you have to use. No, no, no. Give me one more chance to save my demo. Display suites. Apply settings. You haven't. Yeah, okay. That's a usability issue. Voila. Bad usability. I'm sorry. Voila. Save. And now... Yes. Nice. Okay, so that's views integration. There's also grouping in views. There's also a load of other plugins. I'll stick to this. Then we've worked on nodes for now, but you can also work on other entities, such as comments, profile. I'll give a quick demo of the profile. I've made... If you look at the views, I've created one view called about me, which basically shows... I'll show you. Display suites too. And the... I think it's teaser. Voila. Save. What did I do? I think you selected the random facts about me. Indeed. Okay, so I've messed up my random facts. No problem. I hit it. Okay, it's been set already. User accounts, okay. So even for this profile, this user view, you can choose a view mode. If I look at the homepage, Voila, I get this nice block with a fantastic picture of Chuck Norris, the fastest, strongest, and deadliest man alive. It's a small use case, but it happens. So this was built, I think, for two years now. And every time we have a use case, we try to fit it in the module. Then comments. Another simple example. I'll go to the acting career. Voila. You have this by default as comments. I don't like the program link. I don't like the submitted by. So let's look how we can change it. I go back to my articles, manage display, then I get a tab, comment display. And the same thing here. I can choose the... Maybe this one. I hide the empty regions. Save. I can use the user picture. If we have one. I'm not sure if we have one. Title. Don't care. Comment itself is important. Voila. And all the rest. I don't care about. Voila. Reload. A very nice picture of me. And then the comment itself. So again, whichever entity you have in Drupal, you can manage it. It's the same interface that you get. It's the same place to do it. And the same ease of use. And I think that's it for the basic part. Maybe just look at the HTML. For those who care about that. I'll use Firebug. Which isn't installed. Okay. I won't use Firebug. Sorry. Can I get a good demo here? No. I won't bother you with the details then. One of the benefits is in fact that your HTML is the same. You get the same classes on your notes, on your comments, on your user profile block. And that's a huge benefit for teamers. Very consistent CSS is a huge, huge benefit. Especially for maintainability. Then back to the slides. Slide show. The extras module. So we've had a lot of options already, but the things that we couldn't fit into the DS module, we added into the extras module. Some examples, which I'll show you too, is field templates. Again, targeted at teamers who don't like all the HTML that Drupal prints out. Because it can be quite a mess. You can move your regions from DS to a block. I'll show you a nice use case too. Contextual links is very useful. It's a small one, but very useful. You can override your page title. You can switch between view modes on the front end. You can even manage your views in the same way as we did with the notes. And there's a lot more, but you'll have to try it out yourself. So templates. If I go to modules extras. Save. Then I get a nice set of options under structure, display suites and extras. The first one is field templates. I'll just enable it. If you do so, it's aimed at teamers. So most of you won't use it, I'm guessing. But for my type of developer, it's quite useful. So we have two options, all you reset, which means strip out everything that you can. Make it as clean as possible. Or stick to the Drupal default, which of course we don't want. Reset. There's advanced options linked to field templates, meaning you can use hooks to create your own field templates and stuff. But that's, again, too complicated to show. So if we save it, then we go back to the article. I hope I can show it in the HTML. Let's go to acting career. Yes. Normally this image would have been wrapped in the filed items, field items, field item image, whatever HTML that you could imagine. And now... Yes, stop indeed. So what you get here is this diff. You get your simple diff that wraps your node, which you need anyway. As a theme, you get node articles, so your content type, and you get your view mode. So with this combination, you'll be able to really target your CSS. And then in that, you only get the image tag and the text, so no other clutter, which is really a nice achievement. It's been added, I think, only a few weeks ago, but it was a really nice addition. Then next one is... Switch view modes. You can, I won't show it, but you could select a specific view mode for one node. So all your nodes look the same, but then that one specific node shouldn't have images, whatever. You could switch view mode just for one node if you turn this on. Then with this link, you could... You can add a link to a certain view mode and say, let this one switch from teaser to, for example, small teaser. There was a use case, I'm not sure what it was again. I think it's to do with a shopping basket or doing a product in text and then switching to the image version of it. So with some imagination, you could really make a nice use case out of it. Contextual links, I'll just enable it because it's so useful. Page title options, I'll enable it and show it and regions to block. This is contextual links. One click and you go to your layout. So no searching which layout did I use on which part of my site. Really useful. Regions to block is also a very nice one. Let's say I want this image displayed on the right in my sidebar, a different region altogether. Then I go to my managed display. I have to add a block region which I'll call sidebar. Not being very creative, but hey, Voila. Okay, prepare to hard, apparently. Sidebar 2, save. Voila. If I go to my blocks page, choose no, I can continue. I get my sidebar here, so I'll put it where I want it to be shown which is the sidebar and yes, indeed. I've prepared this demo. And if I then go back to my article, I'll go here, manage display, the full content view. I get this as a region, so I can drag which ever field I want into that region and then to then be exposed to that block in the sidebar. This is very useful to link content together on one page and yet show it in different regions. So the image I'll have to take it from here. Voila. Move it to the sidebar. Save. And home. Acting career, Voila. So this block now appears in the sidebar. A very useful feature too. The other one was the page title which I can show too. It happens in some cases that you just want this page title to be something else. And if you want to do so, you'll have to go to your page template with Drupal Core. And then you'll have to write some dirty hacks if this page, then this title, not really maintainable. So for this full notes, you can choose page title, show it, hide it altogether, or manually set it. And you have some nice tokens. So I can... Voila. Copy this. I'll call it... Article. Voila. No title. It's a typical example. And then your page title is changed. So no hacking your page template file. Just leave it as is. It's all possible. Then a very nice one too. One of my favorites is View This Place. It's really powerful if you want to build complex pages. So what you get, I'll show you what you get. Structure. This place reads. View this place. You can add any view to this list so that it can be managed by this place. I'll take the front page page, for example. Add it in. I get the same link managed layout. If I choose Fluid 3.0 stacked. Voila. Again, gets all the views, fields separately to be managed to be played around with. Somebody's happy? Yeah. Okay. It's a very nice one to manage your pages. And it could be a replacement for panels. If you don't need panels, you could use this to just fiddle around a bit. You get your footer, your header, your pager. We've had use cases where we show a list of stores on one side and then the attachment is shown on the right next to it with some extra information. So you can really play around with that one. I think that's it for the extras. Yep, indeed. So it's back to Swentil for the search integration and we'll switch chairs. Yes. So who has tried to team search results in this room? Who failed? Well, okay. Yeah, maybe I should skip. You have been talking a long time already. So I'm going to skip. I'm not going to skip this. I'm going to not talk a lot about this. So anyway, I'll just go back to our demo site here and let's go to modules. As Jean-Yves already explained, DisplaySuite comes with an extra module. It's reverted, yeah. DisplaySuite comes with an extra module called SearchDisplay which allows you to take over your search results. So this works for a Drupal Core node search results. It also works for Apache Solar. There's a couple of other search solutions out there. It should work out of the box normally. So you have to do a couple of stuff. First of all, again, you go to structure display suite. There's a new item here called search. And it tells you, first of all, there's a nice help page here. You have to go to search settings of Drupal Core itself. What we have done is we've created a new, well, search option. There's an extra hook now in Drupal 7 core which allows you to create your own search engine. So we do that too. So it's called SearchDisplay. So you can activate it and then it's the default search module. So we save that. Let me go back to structure display suite. Let's add this to the toolbar. It's easier. So let me go back to search. So you can configure a couple of stuff here. First of all, this is a search engine. I don't have Apache Solar on my box right now. But if you would use Apache Solar, you can choose Apache Solar here. So it will query Apache Solar with a little single function and then just push out the results to this display suite to start teaming it. So you can also select another view mode. So search in Drupal Core. There's a search result view mode, but it's not really consistent. I mean, if you would drag the fields around and then look at your search results, it won't really look like you want it. I mean, it's using the search result TPL file. With this display suite, we're completely overriding that and you can really manage it like you want. So for the demo, we're going to use the teaser view mode. There's some extra stuff that you can do here, like total results. That's actually a pre-process variable which you can, if you would like, overwrite. I'll probably add some options here to make it configurable with tokens and stuff like that. There's a couple of more, but search is really cool right now. So let's search for Chuck. Chuck the man is not going to work. So this is now how our search results look like. So this is an article. These are facts which we added to the website. If I would go back to display suite and go to layout, actually, let's do it differently. So we've added the... it doesn't work here. Okay, this is the contextual links. It should work on this one as well, but this is going to... Okay, it's right. Why isn't it showing the image on the left? Because there's only one article in the image. Okay, right. Bad content. Okay, but you get the idea. I mean, it's really easy now to overwrite your search results and to have a consistent search result. Otherwise, I mean, if you have a lot of content types in your website, then it's really hard to fill in the search result TPL file and have a lot of if switched statements to say if this is the content type of this, then put that on the left and blah, blah, blah. And you go on and on and on and on. I've seen search result TPL files which were really, really, really big and really ugly. So let's search. Really easy. It works out of the box. It has some nice stuff that works with Apache Solar, like say filter on language. If you have a multilingual site, which we have to do a lot, then if you're on the Dutch website or on the Dutch, then you filter directly on Dutch articles. If you're on the English one, you get a picture. So let's search. Let's go back to the slides. Okay. It also works on users. I'm not going to show that. I mean, if you would use the user search result in TPL Core, it just shows you, I think, the username and the email. With this place, it overwrites that and you can really create beautiful layouts from user search results. So there are advanced use cases. I don't think we have to go very long in it so quickly. Just quickly. With what we've shown, so views, notes, comments, profiles, whatever, you could really come up with some nice use cases. One that's used quite a lot by ourselves is in slideshow. The front page, big slideshow with different content types. So you would want a news item in it, an article, a photo gallery. But in that case, we just make an extra view mode called slideshow, for example. And for every content type, we just arrange the fields like we want to. So slideshow will never break, so to say. A very simple use case, but really handy. And I think it's maybe up to you to think of a good use case if you want a very cool, cool t-shirt like we do. So start thinking. And if you can challenge us, you will get a free t-shirt. All right. DisplaySuite and panels. This has been a very hot topic at the beginning. Someone mentioned to Earl, or Merlin of Chaos, that DisplaySuite was the anti-panels. Luckily, he tried it out himself. So he gave a presentation like two weeks ago in Drupal Camp LA, and he did this quote, so I'm very happy with that. So DisplaySuite is not the anti-panels. Actually, Earl has really pushed me to look at the panel's editor, which if you install panels, you don't get nothing. You only get the editor. You have to install a couple of other modules. The typical use case is the page manager. There's also the panel nodes. There's also mini-panels. So with panels alone, you don't have nothing. So with DisplaySuite, you can actually use the panel layout editor on the view modes, which is a really cool integration. You can actually use them together. So for some view modes, you would just use the field UI, but if you have really advanced use cases, or you rather want to use the panel's layout every time, you can just use it. So I'll show you how it works, or how it looks like. So the panel's integration is something that I've put into the extras module. So you just go to panel view modes, you toggle this, and then if you would go to layout and say article, then you get your panel's layout editor right here. So if I would go to full content, it's still going to be in field UI because we have already configured it. But we can switch to the panel's editor if you want to. So let's say switch to panels, we choose a layout, let's say the two column layout from panels. You can add some default fields already if you like. Save your layout, and there you go. So you can now use the panel's editor on the view modes that come with Drupal Core. So you can basically choose if you like. That was one of the biggest critics that we got every time because in a way what we do with DisplaySuite is adding the other fields as well. Panels has more options that come through Ctools, of course. We solved that a little bit with the dynamic field as Geneva as well has showed. So the dynamic field is actually using all the content types that are available through the Ctools integration. So panels and DisplaySuite, everybody loves it right now. So let me go back almost at the end of this session. So I'll just... Maybe just one small addition to the previous slide. I mentioned that panels and DisplaySuite are a powerful combination. And you should see it, or the way we use it is that panels is used for the page layout. So your header, footer, whatever, just completely take it over with panels. But the content itself is managed by DS. So you say that you want to see your nodes in that region, for example. But the node itself is managed by DS. So if you use the two together, you get full page control with panels and content control with DS. So the two work together very, very well. That's it. All right, I'm going to skip this very fast. DisplaySuite, as you have seen, you can really... Well, configure it through the user interface. There's a lot of hooks that we have for developers because, as we said, we want to bridge the gap between teamers and developers. Developers can implement hooks to create the display fields. So that's something that's really interesting. Display fields are fields that just go into output some content which do not have any form input. So if you have your node form, you have all your typical fields, but you want to do something with that. So those are really those display fields. You can have extra hooks for that. So you have extra hooks, I'm sorry. You can implement a hook to create the view modes. You can also create your own custom template files if you like. So you're not limited to the template files that you've been shipping by default. You can create them either in your theme. We even have a Drush command to really quickly create a skeleton. So really easy and really handy. Which is also very cool. Everything is exportable now in 7, the Dribble 7 version. There are some problems with the Dribble 6 version. It has support for features integration, but it's sometimes a little bit buggy. In the Dribble 7 version, display 3 depends on C tools and everything that you have seen from settings. So if you have configured a layout, then you have a lot of settings. All the view modes, all the fields, all the whatever I've probably missed are now exportable either to features or the bulk export that comes with C tools. So you can easily now use version control and put all your settings into SVN or Git or whatever you like. So I'm not going to talk a lot about this. We're almost done. Performance, that's always the number one question, especially with the Dribble 6 version. Dribble 6 had some implications. Dribble 7 has been completely rewritten because of the fact that especially field UI, which is basically CCK came into core, which is good for me. Or for us, let's put it that way. It's good for me because I get all the questions every time. So I've completely rewritten the stuff. So if there are any performance impacts, it's just because now it's Dribble core that is going to be the overhead. In fact, if you would look at the template file, it's using the same technique as Dribble core. So there's not really any overhead anymore opposed to the Dribble 6 version. People always ask me, okay, so you've seen the demo where we have configured a view and where we just added the views title. In that case, it's probably better performance-wise to use that technique. But as soon as you would add a field API field onto a views, then views will always load the full entity, which is due to the fact that field API is built up. Earl is really pissed about that, but he has to load the full entity to get or to display stuff with views. So on that part, well, there's not really a big problem anymore. Entity Cache is a module written by Nathaniel Cachepro. It's something that you should really install anyway on your Drupal site, even if you don't use DisplaySuite. That module is going to cache any entity into the cache table. So it's going to, if you use just the database, it's going to be in the cache tables you can use memcache and stuff like that. So you should always install that module anyway. If you don't going to use DisplaySuite, we are not going to force you, but that's a really cool module. So in the future, I'm probably going to skip that. I mean, it's almost time. Some resources. So FirstLink is a project based on page on Drupal.org documentation. I've created 11 videos last week, which was really a lot. So everything that's in DisplaySuite, every single little feature is on those videos. We have a little booklet, I think. Do you have booklets? We have little booklets at the back, which describes every single video and the URL is underneath it. Just watch it. It's really handy. And under two other links, it's my website and also his website, where we talk about DisplaySuite and announced stuff and stuff like that. So that's it. Any questions? Yeah. So the question is if DisplaySuite takes over the views template file, if it's going to battle with semantic views, I think it's not going to battle. I've looked at the classes that views also spits out. And there's especially a couple of classes that are really important for views to work, especially the Ajax integration. So it shouldn't clash. I haven't tested it actually, but I'm pretty sure it should work. Maybe he knows? No. I would think it would work. Yeah. It should work normally. Because I know that I had some troubles with the Drupal 6 version that I didn't add all the extra classes that views needs for the Ajax integration, for instance, so it should normally work. So the question is why an extra hook for those display fields? I've looked at the hook field extra fields hook, which is kind of limited. Because if you enable this, if you choose a layout, you get the title field, for instance. Sometimes you want just to have a title with some rappers or no rappers of stuff like that. So with the display fields, you have the opportunity to create formatters for those fields. So that's basically the main reason why I did that. I've looked at other possibilities. I've talked this through with Eve Shadma, but it wasn't really possible to do it in another way. So I haven't really tested the profile to module at this point. Because, well, with the entities now in core, you can manage fields already on the Drupal core. So we haven't used profile 2 for Drupal 7 anymore at this point. We haven't really used it in Drupal 6 as well. So at this point, I don't know. I haven't tested it, so yeah. I'm going to first. To control the node edit form? No, that's not our intention. I've had that question a lot, but for that, we're maintaining field group as well. Field group module for Drupal 7 has been also really rewritten from ground up. And it's much more powerful than the Drupal 6 version. So in Drupal 7 with field group, you can add extra vertical tabs, horizontal tabs, or accordions and stuff like that. So we really want to separate those two things. So no, the space feed is not going to take over those forms. So the question is responsive, mobile and stuff like that. In the Drupal 6 version, this is a module called mobile tools, which looks at the headers of the request and then just going to render stuff in another way. So I know the developer and I've given him a patch where he exposes another build mode so that you're actually allowed to say, okay, if you're going to use mobile tools and you have this place we'd installed and you're looking at an article on a mobile phone, use the, he called it the mobile view mode, I think. So there are some tools already available to do that, I think. We haven't really had a lot of experience with that yet. I hope to have some experience with that in the future. But it should be possible to just say, okay, if you know that your request, which is coming in, is coming from mobile, you can just pass on the node or you can change the view mode, for instance, and then just, yeah, you just configure it, of course, in the backend. So it should be possible, yeah. What about node references? So you have a node within a node, can you use the space feed for that? Yeah, so you don't really even need the space feed for that. I think the patch is in already, so the references project for Drupal 7 originally only had two formatters, I think only the title and the full node. The patch that now went in just exposes all the view modes which are available. So you just drag the reference in the right and then you select the view mode. The option to duplicate stuff. Well, you can with the dynamic field. So you can create either your own custom field. I think, yeah, you have to use a custom field, I think. I don't know if a token is available, but if you have a little basic knowledge of PHP, you can just create a custom field, put PHP in there and then just drag and drop around it. So it's not in by default because we didn't have the use case yet. I think we did an attempt to do so a few weeks ago too, but you realize it was just too complex to get it in. It's quite crowded already and to add another clone option and duplicate fields and it's too difficult. So yeah, custom fields, dynamic fields are the way to go. So question about context and arguments. If the dynamic field is actually using the Ctools integration. So if you add a dynamic field on, say, an article which is a node, it's going to pass in the node context by default. So you have that full context to use. So for instance, what we've done last week is we created a view which had an argument. And then we created a dynamic field and with the views content paints, we selected that view and then you could automatically choose, like say, the node NID to pass in as the context. I'm working with Earl right now to put the context and variance as well on the view modes, which if you know page manager and stuff like that, so that will be available quite soon as well. So you should be able to add any sort of kind of context that you want. A use case? Anybody? No. A challenge for us? Okay, then thank you for listening. Hope you learned a lot.