 Okay. All right. Thank you everyone for coming. I think we're getting a little bit of an echo on this thing. This session is Multi-Headed Drupal. My name is Larry Garfield. You may know me as Krell Online. I'm a senior architect at Palantir.net, or a Drupal development shop based in Chicago in the United States. I'm an advisor to the Drupal Association for Drupal 8. I'm the web services and context co-initiative lead. I was the co-author of Drupal 7 Modular Development from Pack of Publishing. Who here is actually also does programming? Okay. Wow. This is a site building track, right? Okay. Making sure. And I talk about software architecture a lot and shoot my colleagues with Nerf guns. That's pretty much all you need to know about me. At Palantir, we work mostly with institutional not-for-profits. So universities, museums, newspapers, and newspapers are not-for-profits these days, right? Okay. A couple of people in here who used to work for a newspaper. So it's like the Journal of Foreign Affairs, Field Museum of Natural History in Chicago, sort of ours, one of the largest natural history museums in the world. And it's called JournalSource.com, which is run by Red Hat. We helped build that along with Acrea. Marketplace.org, which is a major public radio station in the United States. And a lot of the institutions we work with run into a common problem where they want lots and lots of Drupal sites, but they don't want lots and lots of Drupal sites. And so you've had to figure out what to do with that problem a number of times. And I refer to this as multi-headed Drupal, multiple Drupal heads. Okay. Never mind. So let's have an example. Let's say you're building a site for a university. Who's built sites for universities before? Yeah. You probably know everything I'm talking about here. So they've got three different colleges within the university, or maybe they have 30. And each of those colleges has four different departments, or maybe they have 40. So you have some small, some large number of different subgroups within the organization that all have different needs, maybe. And you have an IT department who, because of the university, are woefully underfunded and woefully understaffed, and they just want to keep things simple for themselves. They don't want to have to coordinate a thousand different websites, that's what they're trying to get away from by moving to Drupal. Of course, each of the departments wants to be their own unique special snowflake because they're academics. And so of course they are special and important and different than everyone else in the exact same way as everyone else in the university. Who has run into this problem before? Yeah. I feel your pain. So how do we go about balancing these different needs? There are a lot of different ways to do that, actually. As in everything else in Drupal, the answer is it depends, and you have options. There is more than one way to do it. What we're going to talk about in the next hour is a variety of different ways that you can go about addressing this problem of I want one site, but I want many sites at the same time. And try to provide a framework and a guideline for how you go about deciding which of these is going to be appropriate. If you're here looking for a silver bullet, I apologize, you're not going to find it because there isn't one. Uh-oh. If people are laughing, was that people who are looking for a silver bullet? The really important slide with the information you want is at the very end, so you can't leave yet. We're not talking about hard rules here. We're talking about guidelines, about a heuristic for deciding which set of tools is appropriate for each case, and all of them will have their use case. So option one is don't unify them. Just go ahead and run a bunch of different Drupal sites. There's nothing inherently wrong with dealing with a single web presence by having lots of different sites. Biggest advantage? It's simple. Anything you need to know, you already know or have gotten from some other session already. And you can just give each department, each organization, each subgroup, whatever, their own Drupal install. And maybe you centralize the build of it, maybe you don't, but it's just a separate Drupal, don't complicate matters. This is a viable option. Benefits of that. You have a standard platform in Drupal. You don't need to worry about some people on Drupal, some on Joomla, some on SharePoints, some on WordPress. It's all Drupal, and you still have that standardization, and that still helps your IT departments. There's no added complexity. Everything you already know about Drupal still applies. Everything you know about views is the exact same way this way. It's just more of it. Everything you know about panels or context module or fields, whatever you're doing, you already know all of these things. It also means each implementation, each site, can be different. It means you can have different content types on different sites because they are different. It also means you can mix Drupal versions. Who here has worked with a client that has wanted to roll out a couple of sites over the course of two years? And in two years' time, you really want to be working on whatever the next version of Drupal is. Two years from now, I plan to be using Drupal 8. If you have that kind of situation, this is the only option that will let you say, these sites are on Drupal 6. These are on 7. These are on 8. If you need to do that, you have to make them separate sites. On the downside, though, you really don't get any economy of scale. You're not taking advantage of any of Drupal's ability to centralize things, aside from the fact that it's all Drupal. And you don't automatically get any standardization. So just because you know how the content structure is on this department site doesn't mean you know anything about this department site. The history department and the biology department have nothing to do with each other, so it's harder to retrain administrators from one to the other. And if you're an admin, then it's more work for you, because if a new security release comes out, that's 5, 10, 15, 30 sites, you have to go and update. And QA before you update, right? You're all nodding your head? Ways to improve that and mitigate some of these downsides. Features module. Has anyone not heard of the features module? Good. Features module, we all use at this point dumb configuration to code, builds packages of functionality. And then sometimes you can easily distribute that. We've done this for a client where we rolled out a multi-site for them at one point really early on. And then they wanted to add some functionality to all of their sites, so he said, OK, built a new feature module for them, emailed it to them, and they just dumped it on each one of their sites and enabled it good to go. And had a content type or two, a couple of views, some new module dependencies, worked great. Install profiles. If you're rolling out a lot of similar sites, these are really helpful. Install profiles have been around since Drupal 5, thereabouts. And as of Drupal 7, they are almost modules unto themselves. There's a few differences, but for the most part, you can treat them as if they were a complete module, which means you can do anything you can do in a module with an install profile. They can implement hooks. Especially implement alter hooks. At Palantir, we have a small install profile that we use that doesn't do a great deal, except it formultors out the promote to front page and sticky flags on all node forms. Because really, who uses those anymore now that we've got the flag module that isn't limited to just administrators. So you can do that kind of stuff in an install profile. You also get, however, a complete install wizard. These can be really simple or really complex. You can have them create content types for you just as part of the install. And in fact, if you just run the normal Drupal install process, the content types you get out of the box, page and article, those come from the install profile. There's nothing baked in to Drupal about those. You can create default content if you want. So if you want to pre-populate some sample contents, if you want to pre-populate every department is going to have an about page that works almost exactly the same, go ahead and throw that in there. It makes life easier. You can set up user roles if you want to and users. So you have five administrators who are part of every site. Go ahead and set up that user just as part of the install. Anything that's a variable in the configuration, where you get the system settings form, you can set those. Pretty much anything in Drupal that has a solid API, which is unfortunately not everything, but it's most things, you can pre-configure in an install profile. These can be really, really simple or really, really complicated. And when you combine an install profile, especially the more advanced ones, with features, you get distributions. This is probably where you want to go if you're rolling out a bunch of similar sites internally in your organization. A distribution is a web application that happens to have been built with Drupal. That's pretty much what it comes down to. One of the earliest was OpenHVM. People heard of this before? OpenHVM? It's a project management tool built on Drupal 6 that doesn't look a great deal like Drupal. Managing news, another early distribution, it's good for content aggregation and stuff, for building new sites. Drupal Commons is an intranet in a box from Aquia. More recently, things like OpenScholar are aimed at academia for an academic department. So if you just want to roll out a bunch of different academic department sites, just install this and be done with it. It covers a lot of what you need. Who actually has seen the DrupalCon website? Why did it take so long for you to raise your hands? I hope you've all have seen that. That's running a distribution called COD, Conference Organizing Distribution, which is used by, at this point, all DrupalCon sites and most DrupalCamp sites. It's a distribution that, out of the box, offers session management. It offers tracks. It offers voting on sessions, all that kind of fun stuff, just right there for you. Open Academy is a fairly recent one. It's similar to OpenScholar in that it's targeted at academia, but it's built with panels top to bottom. It's kind of cool to have a look at it. And you can build your own. These are not difficult things to build. It's just an install profile and a couple of features modules. It can be as simple or as complicated as you want. And there's 200 SUMOD listed on Drupal.org. If you want, these slides will be online. You can follow these links or just go to Drupal.org slash projects less distributions. And see if any of these Drupal in the box solve your problem or are close enough to solving your problem. Good example here. The Field Museum, I mentioned earlier, we built a microsite system for them. They wanted to spin up a brand new website for each one of their exhibitions they had. And the horse was their first exhibition. And we just built an install profile for them that covered 80% of what they wanted for any given exhibition. Base theme, some basic content types. Media module came pre-configured, WissyWig already set up, don't need to download anything extra. All of their text formats are configured with the right tags they wanted to allow, the custom user roles they had, just all of it done out of the box. And they can then build a new exhibition site in an afternoon. Building a Drupal site in an afternoon is pretty cool. OK, they all look alike. They wanted them to all look alike. Very often, that's fine. Another option though, if you want to get some efficiency, is multi-site. In this case, you've got a single Drupal code base, but split configuration, split database, separate content, separate users. This has been a feature since at least Drupal 4.5. I came into Drupal in 4.6, and the people I've talked to have said, well, it's been around at least since 4.5, it may have been older than that. I'm not entirely sure. Basic idea, you have a single Drupal code base, but you run many sites off of it. Who's done this before? Wow. So you all know everything I'm talking about. Why are you even here? I'll just go home. This lets you run sites that are, for all intents and purposes, separate websites, but with a single code base. And it's fairly simple to set up to say, OK, off your Drupal root directory, you have a sites directory. We all know this. And there's the sites default directory. Wonder why that's there? Settings PHP is the configuration for that site. But if you set up a different directory that matches the domain name that gets requested, that uses that instead, you get a different settings file. That different settings file points to a different database, you have a completely different site. And you can have as many of these as you want. They don't have to all be on the same main domain if you don't want them to be. As of Drupal 7, you can now alias them too. So I think this is the only PHP code in this session. So don't be scared. So you can say, if a request comes in for this domain, use this directory name under sites. Forrest comes in for this domain, use this one, and so forth. And you can actually have multiple domains that point to the same directory. And then you just set up your DNS records and say, all of these 12 domains point to the same place on disk, the same virtual hosts in Apache. And this is really helpful for development. I've got my development server, and I've got five other people working on the site on their own directories. But we don't want to have to change the site directory structure all the time. So we just say, OK, Larry's sandbox maps to dev, Bob's sandbox maps the dev, Jill's sandbox maps the dev, and so forth. And then the domain part still works, but all of these aliases do as well. You technically can also use subdirectories in here and different port numbers. But honestly, in my experience, subdirectors are just way too hard to set up, and they're kind of buggy. So don't bother. Assume that you can only do domains. It's just going to be easier. Trade-offs here. Everything I said about separate sites is true here. You get all the same benefits in terms of independence, except you only have one code base to update, which means you only have one git repository because you are using version control for your site. I hear a couple of nervous laughs. So when you start using version control for your site, you only need one repository. Another important one that is often overlooked is the lower memory overhead. Who here is running APC or an opcode cache on their sites? Good. If you're running Drupal, you want to be doing that. An opcode cache, like APC, caches the compiled version of all of the code files, which is a huge memory, a huge performance improvement. It caches it per file name. So if you have 30 Drupal sites installed separately on the same server, then you have 30 copies of common.inc that are cached in memory. If you have 30 sites installed on the same install with multi-site, you have one copy of common.inc cached in memory, and you use 1 30th as much memory on your server. That means you need 1 30th as many servers to keep up with demand, and your budget people will love you for that. Something else you can do is table sharing. Drupal does have the ability to prefix tables in the database and change the prefix per table, which means you can have tables that are shared between different Drupal sites. Please do never, ever do this. I've done it exactly once. It was a mistake. The site works, mostly, and makes an upgrade and maintenance a nightmare. So it's a feature, but please don't use it. I don't think it's going to get taken out at any point, but please don't use it. It's more of a side effect than anything else. On the downside, pretty much all of the same downsides we talked about before, except that you can only have one core version at a time. Not just major version but minor version. If you're going to upgrade to 7.16 when that bug release comes out, you have to upgrade every single one of your sites at the same time, which means you only have to do it once, but it means you have to test them all at once. You can maintain different versions of modules for different sites, but it's kind of tricky because you have to have module overrides and stuff and be very careful where things get cached. It's just kind of gross. I recommend avoiding it if you can. As a general rule, if you or your client have one server administration team who's responsible for a site, go ahead and use multi-site. Make life easier for them. If you have several different teams, go ahead and make them separate sites, and then the teams don't have to coordinate and yell at each other. They can just do their own thing. Good example here. This is a very old site that we built back in early Drupal 6 days back before there was a features module, which means we built it using partial database dump to set up a new site rather than an install profile. I would recommend the install profile and features approach even for multi-site these days. Given four base themes to choose from for each site, for each academic department, and the process for setting up a new site was dead simple. Clone the database, flush the cache, set up settings PHP, and start pushing buttons. They could customize the theme a bit with color module, and if they really wanted to, they could start playing with the field configuration and so forth. Generally they didn't, but they could. But then they still only have one copy of the site on disk. Worked out. But honestly, when a client says that they want multiple websites, they probably don't mean it. Not because clients are stupid, but because clients don't understand the trade-offs in Drupal. That's your job. Couple of options here, if you want to have a single Drupal site, domain access being the first one. Most of the clients we deal with who say they want multiple sites, this is actually what they want. With domain access, you have a single code base, a single database, single set of configuration, but you can split your content up between different domains or not. And then your user base is shared across all of the different sites. Domain access is an access control module. It uses the node access system. But instead of doing access control based on does this user have this permission, does this user have the right role, it does access control to nodes based on the domain that was used to access the site. That's a really weird hack of the node access system, but it works very, very well. I will warn you, it does use the node grants system. So be careful. If you try to use multiple node access modules, weird things happen. If you want to know how to deal with those weird things, that's an entirely separate session into its own. But it can still work really well. Each domain, then, is that subsection of your site. Not necessarily a different subdomain. You can run any arbitrary domain as part of a domain access setup. The one caveat for that is, if you have 1.drupal.edu and 2.drupal.edu, then you can log into one and still be logged in on the other. If you have drupal.edu and jumala.edu, then the browser won't let you share a session across. That's just the way HTTP works. Domain access primarily affects node view. It restricts when a node will be available and viewable. And there's actually a fairly decent suite of modules built up around it. The main module is just called domain. But there's a couple of modules in that repository, as well as a number of other modules maintained by other people built up around it. So a very quick walkthrough with domain access. You can set up different domains. You give them names in the UI, set up which one is going to be the default, which ones are active. This is one drupal install, remember. Only one copy of the database, one copy of files on disk. Different domains can be set for HTTP or HTTPS, if you want to. You can have an administrative-only domain. This is one of the really cool things with domain access. You can actually override most variable settings per site, per domain. So you want a different site name for English department, German department, to history department, biology department. Go ahead. You want to change the site slogan? Fine. Different homepage? Fine. And most configuration you can override this way. Including the theme. It's very, very easy to have a different theme per domain. Now you probably want those themes to be sub-themes of each other, fine, whatever. That doesn't matter as far as domain access is concerned. You can colorize it per, because colors are a setting, you can, I believe, colorize that per site. So they use the same theme for different domains, but for the different color scheme. You can even set different time zones. This is really useful when you're working on, say, a syndicated magazine, and you have some magazines in one time zone and some magazines in another time zone. It's really important to show that kind of information in the correct time zone. People get very cranky if their newspaper has the wrong time zone. Now when you go and edit a node, you get this additional option. Say, OK, which domains should this node belong to? Which domains should return an access true for this node, and which should return access false? And then when you save it, it says, all right, assigned to this domain, this is a source domain, that's the official domain. So because with this you have content showing up on multiple sites, you want to make sure that Google doesn't hate you and think you're a spammer. So this just sets up a rel canonical in the header to say, no, Google really, the real version of this page is here. I know it's duplicate content. Don't hate me. You could also then take all of the same information and apply it in views. So you can have views that only appear on certain domains. You can have views that filter by domain. So any of your domains slash upcoming events. Just have that auto filter to whatever the domain is. So you only see content that is relevant to that one domain. Really cool. And then here you can see this node is part of these two domains. This node is part of these domains, and so forth. So that's the only domains where it will show up. Benefits here. You've only got one Drupal site. It looks like several, but you've only got one Drupal site. You can do content sharing really, really easily. Content sharing between separate Drupal installs is really hard. There are ways to do it. I've done it. It's really hard. It requires custom work for each site, generally. This way you push a couple of buttons and nodes get shared between different domains. You can have separate theme for each site. You get some configuration per site. And you get a consistent architecture. Your node types are the same across all of your domains. Your views are the same. It's one administrative experience. It's one set of users. So you can have one administrative user who handles 12 domains with one user account because he just logs in and pushes buttons and goes to whichever domain he wants and moves content around. And it's really easy. On the downside, you have that consistent architecture. You cannot vary your node structure between different domains because it's the same Drupal. It's just doing content filtering. You only have the option of using multiple domains. If you want to have different sites managed together that are not really separate domains but just subdirectories, not going to work. They try at one point. It doesn't work at all. It uses the node access system. Here be dragons. There are performance issues when you get into super large sites with that. And as I said, if you try to install multiple like domain access and taxonomy access control, weird things happen and you have to sort it out manually. It's also a single point of failure. If you upload a broken version of a module inadvertently, you don't break one site. You break your entire web presence. Not always the best thing. And everything gets a little bit more complicated. Because everything you do, you need to keep track of, OK, what domain do I need to be filtering for? You need to remember to set that on all of your views when you're making them. You have to think about, OK, these four domains that actually need different fields, I have to put those fields on all of them. You have to be more aware of what you're doing. A good example here. We saw Ken Rickards talk on environment in America earlier this week. Few people. OK, go back and look at the video if you want to see this in more depth. This is a domain access site we built earlier this year. They have one national site in the United States. And then they want an easy content syndication to all of their local affiliates. So there's Environment America, and then Environment Illinois, Environment Massachusetts, Environment Texas, and so forth. And they want to easily share content across all of those sites. So they just set it up as a domain access site. The sites are all fairly similar, but that's fine. That's exactly what they wanted. And they only have to pay to maintain one site. They can have one administrator take care of everything. Much, much easier. It's also one site to have to build, which saves you money, too. If that's not your bag, Organic Groups is another option. Most of the same options here with shared users or split users, if you want. It's a very important distinction. Organic Groups is a fairly old contrib module. Who has used groups.drupal.org? That's Organic Groups in Drupal 6. For Drupal 7, it was completely rewritten from the ground up. It's been revised again. It's now, I think, beta version of Organic Groups 2 for Drupal 7, which is quite nice at this point. I wouldn't have recommended AUG. It's probably pronounced AUG. It's an AUG the caveman, not OG. The maintainers say, OG, they're wrong, it's actually AUG. Took you a moment. But it's actually fairly nice in Drupal 7. The basic idea here, any entity, node, user, taxonomy term, whatever, can be promoted to being a group. And then any other entity can be assigned to be a member of that group. Users can then join a group. So you have this cluster called a group that can be anything that can have anything in it, and users can subscribe to it. This could be a department, create a department node, and then users can join that department. It can be a working group, like on group.drupal.org. You can make a user into a group, and then users can subscribe to that user as a form of fan club. Lots and lots of options here. If you do stuff with the commerce module, you can make a product into a group, and then users can subscribe to that group to get information about that particular product. Lots you can do here. Gives you a fairly good amount of access control that wouldn't have been possible in Drupal 6. So you can actually have roles per group. This is new in Drupal 7. It's really cool. Then you can have members that are part of just some groups and not others. You can add further access control to say, you can only see content that's in your group, you can only edit content that's in your group, only delete content that's in your group, per node type. So you can set up a system that says, this user is a member of this group and has this particular role. Therefore, they have permission to edit page nodes but not news nodes. In this other group, they have this other role, so they have access only to post new news nodes but not edit them. And in this other group, they're not a member, so they can't do anything. They don't even know it's there. Fairly straightforward to set up. It has very solid integration at this point with views, with sequels and panels. This is one of the big changes from Organic Groups 1 to Organic Groups 2. This used to be a lot clunkier. The new version is much, much nicer. It comes with some really nice sample views. I was able to pick it up in an hour or two, honestly, in version 2. Basically, anything in the Chaos Suite, views, panels, sequels, that family of the world works really well with Organic Groups. Is Amitai here? The maintainer of this module, Amitai Burstein, is here somewhere. If you see him, give him a hug. So when you're editing a node or any fieldable entity with Organic Groups, you can say, OK, this node type should be a group type. Or it should be able to be put into a group. And you can configure this per node type. And you can check both, which means you can have an entity that is both a group and can be put into a group. And you can do some really weird stuff with that. I haven't gone to that level of complexity, but experiment with it, see what you can do. Again, one Drupal site, but you're able to segment your content and your users this way. As I said, you can have separate roles and permissions. So in this case, we have what permission do people who are not a member have? What permission do people who are members have? So you can say, even if you're not a member, you can still edit content if you wanted to. The administrator member, I think that one's built in, you can add additional roles. You can even reconfigure this per group. So this group has three roles. This group has five roles. And the permissions are different. You can do that, it works. That's a double. Some of the benefits with organic groups. Again, only one Drupal site that you have to manage. It's only one copy of the code, one database to back up. You get really easy content sharing. You can configure it so that a node can be placed into any number of groups, or just one group, or no more than five groups up to you. You can have a separate theme per group with the AUG theme add-on module, it's a separate contrib. You only have one domain that you have to deal with. Could be a good, could be a bad, depends on your use case. But everything is on a single domain. There is an add-on module that sort of works to push it across multiple domains. But I haven't really played with it a great deal. I don't know how well it works. What's that? And again, a consistent architecture. All your node types are the same. Your administrative users are the same. Your views are the same. It's much easier to manage than having a bunch of different sites to have to go to. On the downside, everything we just said. Only one domain, you can't really push it across multiple domains well. You have a consistent architecture that you cannot really change. You do not have the ability to break out settings per group the way you do with domain access. Mostly it's permission level control. You can't say the site slogan is different in different groups, but you can kind of fake that using panels and hidden fields. As with domain access, you get a single point of failure. Break one module, break the entire web presence. And you have to keep track of that everywhere. Biggest thing here, if you're doing anything with panels or views, you probably need to make sure to include a group context or a group contextual filter everywhere. Forget it. And you're going to find stuff showing up that you don't expect to. Example here, I can't tell you who this is. We're working on this client right now. So I'm not allowed to talk about them by name until effort launches. But every college and every department is a group. So we have a group node type that we can assign content into. We have a bunch of hidden fields on that group node for things like the department name, the department slogan, an entity reference to a slideshow node to control the slideshow that appears at the top of the page. That way, every department gets their own slideshow that they can configure. We're building the site with panels everywhere, so we can use panels' capabilities to pull contextual information from the group out into the header, out into the footer, which on this site was a requirement. We're using panelizer on this one, so they can customize per page what the layout is. Still context sensitive to the group. We're probably going to have a consistent set of roles between different departments, but we are adding custom roles to help support their editorial workflow. It's going to be multiple themes that they define on each department that can then pick their own with the OG theme module just by editing the group node. Can't really tell you who this one is yet, but it'll be coming out soon. But probably you don't mean multiple sites. Just because your client says it's multiple sites, just because they think of it as multiple sites, doesn't mean it actually is. And you have to keep in mind also, what is a site? What does site mean? If the client says, I've got 50 sites, do they actually have 50 separate domains? Do they have 50 different administrative groups? They have 50 different groups that think they're a special snowflake, which does not necessarily correlate to anything else that's relevant. A site could just mean it's your presence on the web. Could mean the homepage for a particular organization or subgroup or departments or working group within some larger organization. They could just mean separate path routes, separate slash whatever. That's what they mean by site. Or they could mean separate access groups. If you're talking to a client and they say the word sites, they say we have multiple sites, stop and ask what it is they actually mean. Figure out what they're actually talking about. They probably don't know what they're talking about. I don't mean that in a defensive way, but it's true. If all they want is separate access control within a single site, there are a lot of different modules for that. My preference is workbench access, which is a model we developed at Palantir. It lets you divide a site into separate administrative sections. Users don't see anything, or the site visitors don't see anything. It's just administrative sections, which do not necessarily correspond to paths. They may, if you want them to, usually use taxonomy to define an access hierarchy, and then say you have access to the history departments. You have access to the biology departments. You have access to the sciences college, which includes the biology departments. Just a couple of buttons with workbench access. And then you can assign users individually, or users by role, to a section. And say, this user has access to biology. Any users in the sciences role have access to biology, whatever you want to do. This primarily affects node edit. It has no impact on node view. So casual visitors to the site, they don't know the difference. It doesn't have any impact on them. It's just an access control mechanism to control who can actually muck with content on the site. If you want to change the themes for different parts of the site, you've got options. I mentioned the sections module here, even though it's not up to Drupal 7 yet. Because it's the first contrib module that I ever committed code to myself in Drupal, so it has a special place in my heart. But I haven't actually used it in years. If you're using panels, or panels everywhere, then you can have different layouts based on a variety of different rules and context. That's an entire session unto itself. In Drupal 7, there is a hook for custom themes. And you can just set what your theme is going to be. Implement some custom rules in there yourself, some custom code, say, when it's Thursday, show this theme on these particular pages, or whatever. Or just don't. Plenty of sites don't actually need separate themes for different quote sites. They just need different access control. Benefits here. You really have no additional overhead. As with doing separate sites, everything you know is already valid. There's no extra complexity of which domain am I in, which organic group am I in. You don't need to worry about that. You only have one code base to manage. And it's therefore really easy for both the server administrator and the site administrator. They don't have multiple sites, multiple repositories, multiple domains to keep track of in their head. Downside, though, you get a lot fewer options to vary things between different sites. You may not need, but you have fewer ability to customize different sections of the site. As far as the public is concerned, there is only one site. Maybe you want that. Maybe you don't. And for the most part, you only get a single navigation hierarchy. Some of these others, you get the ability to have a separate navigation tree for different parts of your web presence with a single site that's assuming you've only got the one. Which, again, may be what you want. And in many cases is. For example, Mount Holyoke College in the United States, another client of ours, they've got a bunch of different departments. But they aren't giving each department their own special snowflake capabilities. It's just one big site. They install workbench access to say, OK, secretary of this department, you can edit your department, secretary of this department, you can edit your news, that's it. And that's all they needed. It's all they wanted. Makes life really, really easy for everyone involved. And then, yeah, the whole site has one design. Because they don't have departments that are super insistent on having a custom look and feel just to prove that they're special. It's really nice when you have clients that don't have that problem, isn't it? You can also mix and match these. For example, one Drupal install, one shared database, multiple domains, and then another instance of Drupal on the same code base that's set up differently. You can run domain access in one site and organic groups in another multi-site, and they won't affect each other. You still have the one code base benefit, but you have separate sites, each of which is split up differently. So you can mix multi-site with organic groups. You can mix multi-site with domain access. If you have a multi-site, you can put workbench access on some or all of them. We have them. You can, in fact, mix multi-site, domain access, and organic groups. And have domain access and organic groups on the same site, on one instance on a multi-site and something else on another. And you can get really complicated here if you want to. You probably don't want to unless you need to, but it can be a viable option. We had a client where I actually recommended to them, you're building a small micro-app, and you want everyone to use that same micro-app. You've got a couple of departments that want to be different for the sake of being different, but they still want you to host them. OK, tell them, we're going to put you all with domain access or organic groups into this one site, and we'll manage everything for you. You don't have to worry. Or we can put you in a separate instance on that same install with multi-site, and you're on your own. You don't get support from us. I don't think they had anyone take them up on the second offer. But the fact that they could say that was helpful. Example here, Barnard College. You have another Palantir client. They have some 50-some odd departments within the college. So we've got one install that's using domain access to deal with different departments that way. And then within each department, they've got workbench access set up so that you can have access to just this part of the physics department. That's what they needed. That's what they got. Here's that really important slide I talked about. So if your most important feature is that you want to support multiple core versions, then you want to go separate install. That's really your only viable option. If your most important thing is different content types, then separate installs or multi-site are viable options. If you want to maintain only a single user base, say, for your administrators or for your content editors, domain access, organic groups, single site. Multi-site is not going to do that. Separate installs is not going to do that. If you want to split your site up across multiple domains, you can do that with separate installs. You can do that with multi-site or with domain access. Ogg's not going to cut it. Single site, of course, won't cut it. If your most important thing is keeping everything on one domain, then organic groups or just one big site, those are your go-to options. If you want to really make life easy for your server administrators, and I encourage you to keep life easy for your server administrators because they can easily break your account. Domain access, organic groups, or single site. One code base, one database, makes life easy for them. If you want to share content between your different sites, different presence, domain access, organic groups, single site for three options that have only one database, I said there are options for doing content indication between separate installs. They are all messy. We're working on that for Drupal 8, but right now they're all messy. If you want to have separate access control rules per department, per group, single site, organic groups are your options. Single site there, you want to be using workbench access. If you want to allow each department to be their own special snowflake and have their own configuration, separate installs, multiple sites, to some extent, organic groups, if you really trick it out, there's a lot you can do there, especially when you start mixing panelizer and putting views into panels. But that also gets weird. I would try encouraging people away from that unless you really, really know what you're doing. If you want to have separate views per department, then again, separate installs or multi-site make it easier. With organic groups, you can a bit with domain access. You sort of can with some of the access rules on views, but it's kind of janky. Stack or migration. This is one we haven't really talked about. If you're not going to be cutting over your entire site at once, and you're going to move over from whatever you've got to Drupal in bits and pieces, that affects your architecture. That affects the way you're going to build a site. In this case, anything that involves multiple separate domains makes it easier because it makes your migration rules easier. It means you have to do fewer weird things with your proxy server. You can do weird things with your proxy server so that certain paths sometimes go to your old legacy site, whatever it is, and sometimes go to Drupal. I say shenanigans for a reason. It's possible. At least this is what my server friends tell me. I've never actually done that myself. I've just been told it's possible. So don't ask me what the actual varnish configuration is for that. I don't know. If you want to vary the theme per department, then most of these options will work. Single site, not so much, but you've got options. If you've got inexperienced site administrators, the people building the site are not really experienced in Drupal yet. They don't have a couple of sites under the belt. This is their first Drupal project. Keep it simple. Don't confuse things. Don't dive into the deep end. You're going to hit your head. Remember, these are guidelines. There is no hard and fast rule. If you want several of those, you're going to have to make trade-offs somewhere. You figure out what's going to be the best set of trade-offs in your case. And no battle plan survives first contact with the enemy, AKA actually building it. So be prepared to be agile about it. Questions? Is there a microphone here someplace? Of course, they don't have a microphone in this room. Why would they have a microphone in the large room? All right, I'll go ahead and repeat things. Yes? Speak up, multi-site. Every sub-site is a separate folder within a single domain. Probably organic groups or single sites. Multi-site supposedly lets you do that, but you have to play games with symbolic links in the file system. I try to avoid doing that. You could go that option. It's just a bit weirder. But I'd look at organic groups first, or just making it one big site, depending on other factors. Oh, yellow shirt. So the question is, best way to organize modules when you're doing multi-site? I would recommend just putting everything in sites all unless you know it's specific to a single site because of that APC issue I mentioned. If two or three sites are using it out of 50, then that's still two or three sites that would have duplicate copies of the code stored in memory at all times that way. Just because a module is in sites all doesn't mean you have to enable it with multi-site. So you can have a module that's in sites all and is able to on exactly one site. The only place any other site would know about it is in their admin modules page. They've looked in there, they'll see these other modules available, but if you don't give someone access to that page, they can't do anything about it. They don't even know it's there. So I would recommend just keeping a single copy whenever possible. So the question is how APC deals with symbolic links? I don't know. Yeah, I don't actually know. I'd just be guessing if I answered that. I would recommend against doing magic with sim links unless you really know what you're doing because it's one more layer of abstraction that you probably don't want to deal with. I know there are people who do a lot of sim links for their modules. I have not really dug into how APC handles that, so I don't know. Questions over here? Yeah. Space is module. Never worked with it, can't really speak to it. And I only had an hour. So yeah, I have not really worked with a module. I didn't, from what little I've seen of it, I didn't really care for its approach, but as I said, I have not actually tried building a site with it so I can't speak to its trade-offs. Other questions? Again, for the recording, first point. Organic groups does let you configure sites such that individual users or some subset of users can spin up new groups at any time. Which you can't do with domain access, you can't do with multi-site, that's absolutely true. And then the other question was multi-lingual, multi-site, in triple six, domain access. Domain access does do multi-lingual. Multi-lingual is always ugly, but we have done multi-lingual domain access sites before that would be my first, that would be my go-to. So solar search, you can either set up a separate solar instance for each instance, if it, you can set up one solar search per install, excuse me, per instance, you make sure I got my terminology right, per instance, so each database that you have can have a separate solar server, which means if you're using single-site or organic groups or domain access, you have one solar server, you can't have multiple. If you're doing separate sites or multi-sites, you can set up a separate solar server per site, or one solar server and use the solar multi-site module, which lets you index multiple sites to a single solar core, and then search from any of them, filtered or not, and then links point to the right place. That's actually what Drupal.org uses, so Drupal.org, groups.drupal.org, association.drupal.org, and so forth, are all separate installs, but they all use a single solar instance, so they're all indexing to the same solar core. You can't set that up. I don't think I've worked with solar multi-core myself, but it's not overly difficult from what I understand. So the point is organic groups does do multilingual, and you can do separate language defaults per group. I'm gonna take his word for it. This is Amitai Burstein, who wrote the new version of organic groups. Everyone give him a giant crowd hug at the end of the session. Anyone else? SingleSignOn on Drupal.org, oh dear. SingleSignOn is, again, a session unto its own. In general, anything with a single database, you get SingleSignOn for free. Anything that's multiple separate instances, it gets weird. For Drupal.org in particular, they developed a custom module called Bakery, that I've not looked at the code base in a great deal. I know it consists primarily of cooking jokes, and it does some weird thing with cookie redirection and login sharing. I don't know exactly how it works, but the module is out on Drupal.org, you can install it yourself if you want to. And by now, it's gotten decent. It's gotten pretty decent. I know there used to be a lot of issues with not realizing which site you were on and stuff like that, but those have mostly been worked out now. So if you are doing multiple installs, but want a shared user base, Bakery is an option there, what it actually does there, is you have a separate user account on each site, but when you log into site A, it does some magic with HTTP so that you're logged in to site B with the same account, or with your matched account over there. Like when you log in, when you visit Drupal.org, that's one user on one database. You visit Munich2012.drupal.org. That's a different user in a different database, different permissions on that site, but it does weird things with cookies so that you log in to one site, you get logged in to the other. I don't know the exact details of how it works, but the module's on Drupal.org, you can have a look. I'm sorry. Yes, I'm saying I'm sorry. So the question again for the recording is when you've got 15 sites and nine languages on a single install, the admin can get unwieldy and what do you do about that? Yes, it can. Usually what I'd recommend at that point is figure out what users will actually need on that site and custom builds of administrative views for them that do just that. And if you need to filter that by domain, do so. If you need to filter that by language, do so. If not, don't. In Drupal 7, you have the workbench suite. So workbench access is part of a suite of modules that's intended as a here's the administrative experience for content editors. Because Drupal out of the box doesn't do a good job of that. Workbench gives you a nice little dashboard for I just want to edit my content and that's it. And it's all built around views so you can go in and tweak that to make a domain sensitive, language sensitive and so forth if you need to. But I don't think there's a global answer other than figure out what people will actually be doing on the site in practice and custom build that administrative experience for them. And then most people don't need to worry about it because you've pre-built it for them. Yeah, that's one of the extra overhead things that can get weird when you have that level.