Often, there are attempts to reduce development costs by prototyping software. Developers are expensive, so development teams are often kept small, if not reduced to a one-person operation. Alternatively, the development team may have very limited time, and the project manager may be stuck in a loop of constantly asking for estimates. In such cases, tasks are often not carefully planned or structured due to time constraints.
This post is about leveraging software architecture and infrastructure to achieve high-quality software for online portals. The key here is scalability. Drupal already offers a variety of ways to scale. We can benefit from a single infrastructure to support a collection of sites. There are installation profiles, the Domain module, sharing content via the JSON API, recipes, and a new and exciting approach: the Sites module.
The domain module
Using the Domain module, we can point multiple domains via DNS to a single Drupal instance, providing multiple domains. Technically, we have one Drupal site with one database, but visitors experience multiple separate websites. Editors can specify on which sites each node should appear by checking boxes for each site. If there are many sites, editors will see a long list of checkboxes. Additionally, all editors have access to all nodes based on the permission system of the single site, so there is no editorial separation.
Multisite
Here, we have the same benefit that the Domain module provides. We can have a single infrastructure and point multiple domains to it via DNS. In a multisite setup, we have the same codebase but multiple databases. This means we need to configure each site from scratch and populate it with content from scratch.
Sharing Content via JSON API
This approach can act as a helper in a multisite setup, allowing us to share content across multiple site instances. However, we must make our own decisions and develop a system that supports the API workflow to share content across multiple sites. We must also decide how to manage editorial permissions and media, which can introduce complexity.
Sharing Configuration via Recipes or Installation Profiles
Recipes or installation profiles are not explicitly designed for a multisite setup; they are multipurpose systems for managing configuration. It is possible to set up a JSON API using them and share it across various sites.
Separate Editorials and Multiple Sites via the Sites Module
The Sites module leverages the popular Group module in Drupal. Content is organized into groups, each with its own roles and permission system, effectively making each group its own site.
Note: For this functionality, the Sites Group module must be installed. There is no need to manually select the site where content should be located; editors create content within the site they are currently in. Each site feels like a separate entity to editors. Site administrators can configure functionality for multiple sites simultaneously.
Currently, the Sites Drupal module is available outside of Drupal.org because it is in public alpha status. Other related modules, like Sites Group and Sites Migrator are already available on Drupal.org. Sites is already used in production for multiple clients. We are working to move this forward and make the modules publicly available on Drupal.org. You can explore some related modules here:
- Sites: https://git.erdfisch.de/contrib/sites
- Sites Group: https://www.drupal.org/project/sites_group
- Sites Migrator (tools for migrating existing Drupal sites into a Sites setup): https://www.drupal.org/project/sites_migrator
- And more to come
Feel free to open up issues or reach out to us on Drupal.org.
An insight into the administration area of the Sites module:
