The Domain Access suite of modules provide functionality that allows serving multiple sites (domains) from this setup, and specifying which pieces of content belong to a particular site, or are shared across some or all of the sites. ![]() This architecture consists of a single codebase and single database/installation. sites that need lots of special customization to code or config, can rapidly increase the risk of technical debt in an architecture that was meant to maintain similar sites. As a note, this setup is not supported by Pantheon, because they don’t allow multiple databases per hosting plan.Ī shared codebase setup would be most beneficial if all of the sites are using similar modules and settings.A code error has the potential to affect all of the sites.This is mitigated if most of the content is static (for anonymous users), because it can be cached by a CDN which can deliver the (cached) pages even if the server is down. Since there is a single server hosting all of the sites, a traffic spike can affect all of the other sites.Scripts are a frequent solution that comes up to automate maintenance tasks across the sites, which means more devops time.Deployments in this architecture need to happen “all at once” for all the sites, which can potentially be chaotic (there is no simple “revert” a commit for a single site, for example).Configuration and updates still need to be run once per site and saved back into code configuration (in each site’s config folder).This implies a high level of trust in the whole team, and does not allow for separation of concerns, meaning that while team members could be assigned to work only in a particular site, the codebase architecture implies it cannot be enforced on a code level. ![]() All developers working in the team have access to the codebase that affects all of the sites.This is one of the greatest risks of a multisite setup, because if sites start diverging in functionality, it makes no sense to keep maintaining a single codebase. If a site decides to customize functionality provided by a Features module, then it would lose any further updates to the module, as they have deviated from it.Less hosting costs: a single hosting plan that supports all of the traffic from all of the sites might be cheaper than hosting per individual site.Another option would be to use the Config Split module to segment what configuration is shared across sites and what should be overridden per site. Shared features can be accomplished by using Feature modules: features modules can be shared across the sites, and then individual sites can import the configuration from it.Some degree of customization is possible, because each site has its own configuration, and it can have it’s own custom theme and modules.Code and library updates only need to be done once.Onboarding developers and administrative tasks are easier with a single codebase.Each website can also have some extra modules / themes under its own subdirectory in the same codebase. In a classic Drupal multisite architecture, the individual websites share code (the Drupal core, modules, and themes), but each website has its own database so they do not share content, configuration, or settings. ![]() We’ll be looking at four distinct implementation choices: Classic Drupal Multisite, Domain Access or Mega Site, Distribution Profile, and an offshoot of the distribution profile called Custom Upstream. In Drupal we have several ways to accomplish this, and this post will describe some architecture options that make this possible, as well as the relevant factors that can help you decide which option provides the best ‘fit’ for the implementation. Oftentimes projects need a way to serve multiple domains from the same installation or from the same codebase.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |