H1 Sites¶

Version 1.0.1-SNAPSHOT · Magnolia 6.4 · Java 21

H1 Sites turns "which brand is this request for?" into a question the content team answers in a form. One entry per site holds the domains that resolve to it, the page in the tree it starts at, its logo, its favicon, its default social image, its Schema.org organization type, its phone number and its social profiles. A headless front end asks once per request — who am I serving? — and gets the whole identity back in a single call, so adding a brand or moving a domain stops being a deploy.

It ships as one JAR with a single light module, and it is designed to be optional to everyone who reads it: the SEO pack enriches its output when H1 Sites is installed and simply omits those values when it is not.

Feature	What it solves	Light module
Site registry	Every site you run described in one app, with its identity and its social profiles, instead of spread across front-end constants.	`h1-sites-light-module`
Domain resolution	One call answers "which site serves this domain?", so a multi-brand front end resolves branding per request rather than per build.	`h1-sites-light-module`
Site globals for SEO	The organization type, the default social image and the social profiles that structured data and social cards need, filled in once per site.	`h1-sites-light-module`
Theme association	A site can point at a Material Design theme, and the resolution call returns the whole theme with it — one round trip, not two.	`h1-sites-light-module`
REST + AI access	A read/write JSON API and an MCP tool, so both a front end and an assistant can work with the registry.	`h1-sites-light-module`

Why use H1 Sites?¶

A new brand is a form, not a release. Domains, logo, social image and organization type are content. Pointing newbrand.com at an existing tree is an edit an author makes and sees live on the next request, with no build and no environment variable.
One call returns everything the page needs. getSite answers with the identity, the social profiles and the full Material Design theme when one is linked — the front end does not follow a reference to a second workspace to paint the first byte.
Domain patterns, not domain lists. A pattern covers www, staging and every subdomain at once, and the same syntax accepts a plain glob (*.brand.com) or a real regular expression.
Optional to its consumers, by design. The SEO pack reads the site globals without depending on this module: with H1 Sites installed the structured data carries the organization and the social profiles, without it the pages still render. Nothing breaks by not installing it.
Safe to read from a public instance. The linked theme is resolved with system credentials, so a public visitor gets the theme without you granting read access to the theme storage.

Documentation¶

Authors — the Sites app field by field, how the domain patterns are matched, what an empty field falls back to, and what the order of the list decides.
Developers · Installation — what the JAR contains, Maven coordinates, deploy, the wiring the module cannot do for you, the permissions the public channels need, and the version deltas.
Developers · Configuration — every field, the resolution rules, the REST reference with its request and response shape, and the MCP tool.
Troubleshooting — symptom to cause, with the silent failures first.

Requirements¶


Magnolia	6.4 (built against bundle `6.4.4`; DX Core or Community)
Java	21
Magnolia modules	`core`, `ui-admincentral`, `ui-contentapp`, `rest-integration`, `rest-services` (all declared in the module descriptor)
H1 modules	`h1-helpers` (mandatory, ships with the module) · `h1-mcp-api` (optional, only for the MCP tool)
Optional integrations	`frontend-md3` — adds the Material Design Theme field and makes the theme travel in the resolution response · `h1-seo` — reads the site globals for structured data and social cards
Magnolia platform APIs used	`magnolia-core`, `magnolia-templating`, `magnolia-dam-templating`, `magnolia-rest-integration` (all `provided` — supplied by the bundle)