Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallUse Drupal multisite: one shared Drupal codebase and document root, with a separate site directory, settings.php, database and files for every site. Map each hostname or path to its directory through sites/sites.php, point every web-server virtual host at the shared Drupal root, set trusted-host patterns, and run the installer for each hostname. This gives you independent sites without copying Drupal core, while accepting that a shared code or deployment failure can affect the whole group.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What Drupal multisite actually separates
Drupal multisite is one Drupal installation serving several Drupal-powered sites. The codebase is shared, but each site has its own database, configuration, files and base domain or URL. A site can therefore have its own content, enabled modules, themes, administrative settings and users without placing its data in another site’s database.
As an Amazon Associate I earn from qualifying purchases.
The shared layer
- Drupal core and shared dependencies: one document root contains the code used by every site.
- Common modules and themes: extensions needed by several sites can live in the shared locations and be deployed once.
- Web-server entry point: each domain or subdomain resolves to the same Drupal document root rather than to a site subdirectory.
The per-site layer
- Configuration directory: a directory such as
sites/site1.example.comcontains that site’ssettings.phpand related files. - Database: each site’s
settings.phpdefines its owndefaultdatabase connection. - Files: public and private uploads remain in that site’s directory so media cannot be mixed accidentally.
- Hostname or path: Drupal uses the incoming host and path, together with aliases, to select the right configuration directory.
When multisite is the right architecture
Choose core multisite when the sites are operationally independent: for example, separate game-news publications that need different content, administrators, themes or release schedules but can share one maintained Drupal codebase. Separate databases make ownership, export, restoration and deletion boundaries clear.
Do not use core multisite merely because several domains should display different sections of one shared content model. If the sites need shared content, shared users or domain-aware permissions, evaluate a single Drupal site with the Domain Access project instead. Core multisite documentation describes independent sites; it does not promise shared content or single sign-on.
#1 Best Overall
Plan the installation before creating directories
List domains and routing forms
Write down every production hostname, such as example.com, sub.example.com or a path-based site such as example.com/site3. Decide whether development names will differ from production names. The decision affects the aliases in sites/sites.php and the trusted-host patterns in each site’s settings.
Choose database isolation
The clearest model is one database per site. Drupal also supports table prefixes when multiple sites share one database, but prefixes increase operational coupling: a mistake in credentials, backups or maintenance can cross site boundaries. If prefixes are unavoidable, document the prefix assigned to every site and test restoration of one site without the others.
Define file and permission boundaries
Give each site its own public and private files directories. The web-server user must be able to read the shared code and write only the directories that Drupal needs for that site. Treat permissions, upload locations and private files as part of the site’s backup and security design, not as an afterthought.
Prepare operational safeguards
- Arrange DNS records for every hostname before installation.
- Create databases and credentials with only the permissions Drupal requires.
- Plan backups for every database and every site’s public and private files.
- Schedule maintenance windows that cover all sites because a shared code deployment can affect them together.
- Decide how cron, cache clearing, configuration imports and rollback will run across the portfolio.
Step-by-step: add a site to the shared Drupal codebase
1. Install a supported Drupal release in the shared document root
Install Drupal in the directory that all virtual hosts will use, for example /var/www/drupal. Complete the initial site’s database setup and verify that its hostname works before adding another site. Keep the web server’s document root at this shared directory; it is the codebase, not a site-specific folder.
2. Create the second site’s database
Create a database for the new site, such as drupal_site1, and a dedicated database account. Record the database name, host, port, username, password and driver because they will be entered in that site’s settings.php.
3. Create the site’s configuration directory
Under the shared installation, create a directory whose name matches the hostname you intend Drupal to discover:
Free tools Windows power users keep installed
One-click scans. No signup required.
sites/site1.example.comUse a consistent naming scheme. The directory is for configuration and site files; it is not a second web root and should not be used as the virtual host’s document root.
4. Copy and edit settings.php
Copy Drupal’s template file into the new directory:
sites/default/default.settings.phpSave the copy as:
sites/site1.example.com/settings.phpSet the database connection and the site’s file paths. A minimal connection block has this shape, with values replaced by the credentials you created:
$databases['default']['default'] = [
'database' => 'drupal_site1',
'username' => 'site1_db_user',
'password' => 'use-the-site-specific-secret',
'host' => '127.0.0.1',
'port' => '3306',
'driver' => 'mysql',
];The exact driver and connection options depend on the database service you installed. Every site must define a default connection. Keep secrets readable by the web process but protected from other accounts, and make sure the file is included in the site’s configuration backup.
Recommended Free Tools
5. Add a hostname alias in sites.php
If it does not already exist, copy sites/example.sites.php to sites/sites.php. Add an alias that maps the incoming host to the directory you just created:
$sites['site1.example.com'] = 'site1.example.com';This alias is especially useful when development and production hostnames differ. You can map a host, port and path pattern to the same configuration directory instead of duplicating settings.
6. Point the virtual host at the shared root
Create an Apache, Nginx or other supported web-server virtual host for site1.example.com. Its document root must be the shared Drupal directory, such as /var/www/drupal, not /var/www/drupal/sites/site1.example.com. A second hostname can use a server alias while still targeting that same root. Reload the web server after validating its configuration.
7. Configure DNS and trusted hosts
Make the hostname resolve to the server before opening the installer. In the new site’s settings.php, configure $settings['trusted_host_patterns'] to include every legitimate hostname for that site. For one exact host, an example is:
$settings['trusted_host_patterns'] = [
'^site1\.example\.com$',
];Add separate patterns for legitimate aliases, staging names or an explicitly used port and path where appropriate. Requests carrying an unexpected Host header should be rejected. Also configure the web server’s default response so a request sent to an unintended host does not accidentally serve one of the real sites.
8. Run the installer for the new hostname
Visit https://site1.example.com. Drupal should find the new directory and present the installation form for that site’s database and configuration. If the wrong site appears, open /core/install.php on the new hostname and verify the alias, directory name, virtual-host root and database settings. Complete the installer, create the site’s administrator account and confirm that uploads and administration work.
9. Repeat the pattern for every additional site
For each new domain or path, create a separate directory and database, add its alias, point its virtual host at the shared root, configure trusted hosts, and run the installer. Do not copy an existing site’s database or files unless you deliberately intend to clone that site and understand which identifiers and credentials must change.
How Drupal selects the site at request time
sites/sites.php is an alias map. Drupal’s API defines keys as <port>.<domain>.<path> patterns mapped to configuration directories. This allows several incoming names to use one directory and lets development hosts resolve to the same settings as production.
When no alias matches, Drupal derives candidate directory names from the incoming hostname and path. It uses the first candidate containing settings.php; if no candidate is valid, it falls back to sites/default. A directory can therefore be selected by a direct hostname such as example.com, a subdomain such as sub.example.com, or a path arrangement equivalent to sub.example.com/site3.
Selection errors usually mean the request did not match the alias you expected, the directory name is different from the candidate Drupal generated, or the directory lacks settings.php. Check the actual Host header, port and path before changing databases.
Keep databases, files and configuration isolated
Databases
Separate databases let you grant, back up, restore and remove one site without operating on another site’s tables. Each site’s $databases array should point to its own default connection. If you use table prefixes in one shared database, test that every update, backup and restore process honors the prefixes and cannot select another site’s tables.
Rank #4
Public and private files
Store uploads in each site’s own public files directory and private files outside any directly served path. Keeping these locations separate prevents one site’s media from appearing in another site’s listings and makes per-site backup retention possible. Check ownership and permissions after deployment, especially when cron or command-line maintenance runs under a different account than the web server.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Site-specific extensions
Common modules and themes can remain in shared locations. If one site needs a local extension, place its site-specific module or theme in that site’s directory and document the dependency. A local extension still runs on the shared Drupal core, so it must be tested against the same code and dependency versions used by the other sites.
Web-server and security requirements
One root, many virtual hosts
Every hostname must resolve in DNS and be routed by the web server to the same Drupal document root. Pointing a virtual host directly at sites/site1.example.com bypasses the normal Drupal front controller and commonly produces missing assets, installer failures or accidental exposure of configuration files.
Trusted-host patterns
Trusted-host settings must cover every legitimate multisite hostname in the relevant settings.php. Keep patterns as narrow as possible instead of allowing any host. A narrow list protects against Host-header attacks while still permitting the domains that users and administrators actually use.
Default-host behavior
Configure the web server’s default virtual host to return a deliberate response for unknown or unintended hostnames. Without that boundary, an unrecognized request may be routed to whichever site happens to be the server’s default, making troubleshooting and host-header protection harder.
Operating a shared-codebase portfolio
Updates and deployments
A shared codebase means one core or dependency update can be applied once for all sites, reducing duplicated maintenance. It also means a faulty code change, incompatible module or incomplete deployment can affect every site simultaneously. Use a staging copy that exercises each site’s modules and themes, schedule a portfolio-wide maintenance window, and keep a tested rollback for code, databases and files.
Backups and restoration
Back up the shared code and each site’s database, public files, private files and site-specific settings. A code backup without the matching database and files cannot restore a working site. Perform restoration drills for one site and for the entire installation so you know whether shared dependencies, permissions and database credentials are recreated correctly.
Cron, caches and configuration imports
Design scheduled jobs to run for every site, not just the first site’s URL. Cache clearing and configuration imports must target the intended site directory and database. A job that runs with the wrong working directory or credentials can update one site while silently leaving the others stale.
Monitoring and failure boundaries
Monitor each hostname separately for availability, database errors, file-write failures and certificate problems. Although content and databases are isolated, the shared PHP code, dependency tree, web server and host can be a common failure domain. Keep an incident procedure that identifies whether the fault is site-specific or requires stopping a shared deployment.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Core multisite versus one site with domain routing
| Decision area | Drupal multisite | Single site with domain-routing modules |
|---|---|---|
| Content and database isolation | Normally a separate database and independent content per site. | One database and one content model, with domains controlling presentation or access. |
| Users and authentication | Each site has its own user accounts and authentication configuration unless you build an external sharing layer. | Users can be shared naturally because they belong to one Drupal site; domain-aware permissions still require configuration. |
| Upgrade independence | Sites share core and dependencies, so a code update is coupled across the group. Site-specific extensions can differ, but they run on the same base. | One site is upgraded as one application, with domain-routing modules and their configuration included in that deployment. |
| Files and backups | Separate site directories and databases provide clear per-site backup and restoration boundaries, while shared code remains common. | Files and database are centralized; per-domain restoration requires careful content and configuration selection. |
| Domains and URLs | Each hostname or path resolves through multisite discovery and aliases to a configuration directory. | Domains route inside one site’s configuration and content model. |
| Failure and deployment impact | A shared code or server problem can take down every site, even though site data is separate. | The single application is also a shared failure domain, but there is only one site’s configuration and deployment to coordinate. |
Use the multisite column when independence of databases, administrators and content is the priority. Use a single site with domain routing when sharing users, content types or cross-domain permissions is more important than separate site databases.
Troubleshooting common setup failures
The new hostname shows the wrong site
- Confirm the request reaches the intended virtual host and that its document root is the shared Drupal root.
- Check the exact Host header, port and path against the key in
sites/sites.php. - Verify the mapped directory name and confirm it contains
settings.php. - Use
/core/install.phpon the new hostname when the installer must be invoked explicitly.
Drupal falls back to sites/default
The alias did not match, or Drupal could not find a valid candidate directory. Compare the incoming hostname and path with Drupal’s <port>.<domain>.<path> pattern and inspect spelling, punctuation and case in the directory name. Ensure the file is named exactly settings.php and is readable by the web process.
The installer cannot connect to the database
Recheck the database name, driver, host, port, username and password in that site’s settings.php. Confirm the account has access to the intended database and that the database service accepts connections from the web server. Do not fix one site’s credentials by copying another site’s settings.
Trusted-host errors appear
Add the exact legitimate hostname to $settings['trusted_host_patterns'], escaping literal dots in a regular expression. Include every alias users actually visit, then reload the request. Avoid replacing a narrow list with a wildcard, which removes the protection rather than solving the routing mistake.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Uploads fail or files appear in the wrong site
Check that the site’s public and private file paths point inside its own directory, that the web-server user can write where Drupal requires, and that cron or command-line jobs use the same site context. Inspect permissions and ownership after each deployment.
Assets or clean URLs return 404 errors
Verify that the virtual host points to the shared Drupal root and that the server’s rewrite or front-controller configuration is active. A document root aimed at a site subdirectory commonly causes missing core assets and routes requests outside Drupal.
Quick Recap
Multisite launch checklist
- Supported Drupal code is installed once in the shared document root.
- Every hostname resolves to the server and has a virtual host targeting that root.
- Each site has a uniquely named directory containing its own
settings.php. - Each site has a separate database, or a documented table-prefix plan.
sites/sites.phpaliases match the actual host, port and path patterns.- Public and private files are separated per site with tested permissions.
- Trusted-host patterns include every legitimate hostname and no unintended wildcard.
- The default web-server host has a deliberate response for unknown names.
- The installer has been completed and administrator access, uploads and caches have been tested for every site.
- Backups, cron, cache clearing, configuration deployment, monitoring and rollback have been tested across the portfolio.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
