Content on sites¶

Decide which content belongs to sites, how sites keep it apart, and which related modules to turn on.

Needs Sites content

Membership and the origin 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.
Global (no site)	Sites of the type do not take this content.

On Valtora's site types, articles and basic pages take Unlimited sites, so the group's press release can belong to Valtora, Hydrion and Torqline; tags take Single site, so each tag belongs to one site.

A type that leaves the rows Value per site lets each site change them on its own Assignable content section. See Site types.

Every item of a type a site takes belongs to a site from the moment it is created: the forms ask for one, the create check refuses accounts that may add to no site, and an API client names the site. A type that no site takes is global content: created on the hub, it belongs to no site and shows on every site. A global tag vocabulary or a shared media library is such a type. Keep global and site-bound content in separate types; a type cannot hold both.

Content that lost its site, say through an import that brought no memberships, is not global content: it shows on no site, only View unassigned content or Administer sites in a platform role sees it at all, and it waits on the Unassigned content report.

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 Origin site by weight, the lowest-weight site that has this box checked is also preselected as the origin 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. Hydrion's article "Service intervals for X-series pumps", for instance, answers 404 on www.torqline.example. 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. On the hub a client names the site with the site_id query parameter, as the links of the administration do: POST /jsonapi/node/article?site_id=hydrion creates an article on Hydrion. Without a site the account may add to, the request fails with 422 "Unprocessable Content". Global content needs no 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; a vocabulary a site takes with Unlimited sites has its one list of terms there too. 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.

Last updated 2026-11-02