HOWEVER due to whatever fake university policy, they don’t get a subdomain. But, for whatever reason our university decides that the office of admissions needs another site (not just a page within the default site). In this case, let’s pretend that the school of nursing and music opt to go with the domain-based route and register sub domains. You can, technically, do a combination of both. I won’t spend a lot of time on this, aside from defining it and strongly recommending that you don’t do it. Once you define a multisite at a path, the default site will lose access to place content on that path (as it will belong to another multisite). In fact, this challenge will expand throughout all paths. So, in this case, even if had a page of content called “nursing” it would be able to serve that page at /nursing because that path is being reserved for the school of nursing’s website. nursing) that path becomes unavailable to the default site to use for content. That means that if you want to have a site like at a path (e.g. Remember that in a Drupal multisite scenario, you have a single docroot / codebase. But what about the admissions page? Is that a page controlled by the default site? Or is that an entirely separate multisite in the array? Honestly, it can be either, but it can’t be both. The admissions page under the nursing site is certainly a page on the nursing multisite. Let’s go back to my example of an admissions page. Here is where things start to get confusing… /admissions The primary differences are that the schools of nursing are now nested under this domain. Here we see that the default site would still be. Let’s go back to our university example: Path-Based multisite can be significantly harder to manage than a domain-based approach, although there are some potential SEO benefits (so it shouldn’t be dismissed entirely out of hand). Having said that, this approach “let’s Drupal be Drupal” and own all of the paths and routing necessary to create and manage content within each multisite. Likewise, nursing.example and music.example are separate sites in the multisite, and /admissions is piece of content owned by the school of nursing.Ī domain-based world can have significant implications on domain / SSL configuration, as you will need to register many (perhaps hundreds / thousands) of domains for your platform and provide SSL certificates for each (or, be willing to register and share a wildcard certificate with your hosting provider). admissions) would be pages owned by the default Drupal site. In this case, would be our default site and will serve as the primary website. These could be entirely separate domains, sub-domains, or a mix.įor the domain-based example, let’s examine our university example. In this scenario, each site in your multisite setup has its own, unique URL. Introduction to Domain-Based Multisiteĭomain-Based is my personal recommended approach. In the following sections, I’ll use the example of a university website with a number of departments to illustrate the differences. And while this may not sound like a big deal (it’s just DNS, right?) it can actually have a really significant impact on your application and the content you’re trying to manage. Where does that leave us? It’s how you actually navigate to the sites that is going to change in these approaches. This means that all sites will run the same version of Drupal, modules, etc.ĭeployments / updates will impact all sites simultaneously This means that each site will have separate content, users, etc.Įach site will run off of the same underlying codebase / application / docroot. Regardless of which option you choose (purely domain, purely path, or a hybrid):Īll your your sites will have their own, unique databases. Right up front, let’s get a few of the similarities out of the way.
0 Comments
Leave a Reply. |