Content on sites¶
Decide which content belongs to sites, how sites keep it apart, and which related modules to turn on.
Needs Sites content
Part of Sites content.
Membership and the canonical site are explained on Concepts.
Which content belongs to sites¶
The site type's Assignable content rows decide it per content type: content types, media types, block types, vocabularies and users, plus what other modules add.
| Value | Effect |
|---|---|
| Unlimited sites | An item can belong to any number of sites. The default. |
| Single site | An item belongs to one site. The default for taxonomy terms. |
| Not assignable | Sites of the type do not take this content. |
A type that leaves the rows Available lets each site change them on its own Assignable content section. Content of a type that no site takes belongs to no site and shows on every site. See Site types.
Auto-assigned content¶
A site's Auto-assigned content setting lists Default content types.
New content of these types, created on the hub, starts with every such site
preselected. With Canonical site by weight, the lowest-weight site that
has this box checked is also preselected as the canonical site; the weight is
the order on /admin/sites/table. Editors can change the preselection before
saving. Set both on the site type to give every new site the same defaults.
Isolation¶
On a site's hostname, the page of another site's content answers 404 "Not Found", to every user. Inside a page, a reference to another site's content or a content block of another site does not render: its access check hides it. Views and reference field options are scoped by site filtering.
Enforce per-entity cross-site view access on Sites configuration >
General (/admin/sites/configuration/general) switches that access check
off for the whole platform; the 404 for pages stays. Turn it off only
when site filtering keeps the sites apart.
JSON:API and core REST follow the same rules. On a site's hostname, another site's item answers 404, collections list the site's content only, and an item created there belongs to that site.
Files and media¶
Media types are assignable content like any other.
Needs Sites file
Part of Sites file.
With drush en sites_file, a file belongs to the sites of the content that
uses it. A private file (private://) of other sites is refused on a site's
hostname, and a form cannot attach it. Public files are served by the web
server without this check, so keep site files private where that matters. See
Media and files.
sites_file.settings has no form; set it with Drush or in settings.php:
| Key | Default | Effect |
|---|---|---|
enforce_download_access |
true |
Both refusals above. false leaves file access to Drupal core. |
upload_directory_prefix |
empty | A directory, tokens allowed, that uploads on a site's hostname go into, like sites/[current-site:id]. |
drush config:set sites_file.settings upload_directory_prefix 'sites/[current-site:id]'
Menus and terms¶
Needs Sites menu
Part of Sites menu.
Installing Sites content also installs Sites menu. The Per-site menus rows of the site type list the menus; a checked menu gets its own links on each site, and the menu itself stays shared. A menu left unchecked shows the same links on every site. The Administration, Tools, User account menu and Sites menus are always shared. See Menus.
Needs Sites taxonomy
Part of Sites taxonomy.
Installing Sites content while Taxonomy is on also installs Sites taxonomy. Terms of a vocabulary the type makes assignable belong to sites, and each site's Taxonomy section lists its vocabularies and its own terms. Vocabularies stay shared and are managed on the hub. See Taxonomy terms.
Links in text¶
Needs Sites Linkit
Part of Sites Linkit.
On a Linkit profile's Manage
matchers tab (/admin/config/content/linkit):
- A content matcher's Filter by site context, on by default, suggests content by site (References and links); off, every site's content.
- The Site front page matcher, once added, links a site's front page by its current hostname.
The Linkit (with attributes) widget of Link attributes works too.
Webforms¶
Needs Sites Webform
Part of Sites Webform.
After drush en sites_webform, every existing webform is usable on no site until
it is assigned on its Sites tab (Webforms).
Sites status counts them and links their list
(/admin/structure/webform?scope=none). The assignment is part of the
webform's configuration and is exported with it.
On a site's hostname, a webform of other sites or of none answers 404 on its visitor pages (the form, its confirmation, its submissions), and a webform field or webform block renders nothing in its place, whatever Enforce per-entity cross-site view access says. The hub serves every webform, and the webform's administration pages keep the webform's own access on every hostname.