Sites

Sites are managed multipage websites built inside Einblick. They combine pages, reusable layouts, site classes, custom CSS, CMS bindings, hosted forms, custom domains, and managed publishing.

Open the feature

• Open Sites from the sidebar.
• If the entry is missing, an admin can enable the Sites module and sidebar item. Sites depend on CMS because published pages can bind to CMS collections.

Create and publish a site

• Click New site to create a draft site with a managed domain based on the site slug. Choose Blank for an empty Home page or Portfolio starter for a shared header/navigation/footer layout plus Home and Projects pages.
• Site slugs are normalized, kept unique inside the workspace, and can be edited from the site actions. Changing the slug also updates the managed host and puts its DNS status back into review.
• Each site has a name, slug, draft theme, default SEO, optional custom CSS, pages, layouts, classes, domains, a site image folder, and form submissions.
• Use Publish to copy the draft site settings, pages, layouts, classes, and custom CSS into the published version. Public rendering only uses published content.
• Publishing queues managed-domain DNS provisioning and asks the site renderer to revalidate when that integration is configured. The domain becomes public only after it is active.
• A site that is still draft, archived, unpublished, or only reachable through a pending or failed domain returns not found publicly.

Manage sites

• The Sites list supports table and grid views with status, slug, updated time, published time, and row actions.
• Use the site actions to open, edit, duplicate, archive, or delete a site.
• Duplicating a site creates a draft copy named after the source, gives it a unique managed -copy slug and domain, and copies draft pages, layouts, classes, and custom CSS. Custom domains, published state, and form submissions are not copied.
• Deleting a site removes its domains, pages, layouts, classes, stored form submissions, and site image folder, then revalidates the renderer when configured.
• The homepage cannot be deleted, but additional pages can be added from the site detail page or editor.

Pages and editor

• Add pages from the site detail page or editor. Paths are normalized and must be unique inside the site; a site can only have one / homepage.
• Page settings control the title, path, layout, page type, CMS detail collection, preview record, and page SEO. Static pages use fixed paths; CMS detail pages use dynamic paths such as /posts/:slug.
• Layouts store shared structure such as headers and footers. A page can use no layout or one layout, and layouts can inherit from a parent layout. Layout content is inserted through an Outlet element.
• The editor lets you add HTML-like elements, arrange layers, edit text and attributes, copy and paste elements, upload or link images, switch preview widths, and save page SEO.
• Styles can be stored inline on an element or in reusable site classes. Style states are saved per breakpoint for base, current page, hover, focus, active, and open states.
• Interactions can run on click, mouse enter, mouse leave, focus, or blur. Actions can toggle states, classes, or allowed attributes on the element itself or another element; the open state can drive open-state styling and aria-expanded.
• Custom CSS is saved at site level and injected into rendered pages after generated styles.
• Each site can contain up to 200 pages, 100 layouts, and 500 reusable classes.
• Preview mode disables selection so you can test links, forms, and interactions in the canvas.

CMS bindings

• Collection-list bindings repeat an element for published records from a CMS-backed API resource. They can set a record limit and filters.
• Collection-detail pages can use dynamic paths such as /posts/:slug and render the published CMS record that matches the slug.
• Field bindings can render a field from the current list item, detail record, or singleton record as text or as a chosen attribute, such as an image src or link href.
• Public pages only read published CMS records.

Forms and submissions

• Form elements submit to Einblick through the public site endpoint.
• Form submissions must come from the same host as the site, stay under 1 MB, and pass per-IP and per-site/form rate limits.
• Submitted payloads are stored on the site with the page, form ID, origin, user agent, and timestamp.
• The site detail page shows recent submissions so admins can review incoming form data.

Domains and public rendering

• New sites get a managed host based on the site slug. Managed DNS uses the configured renderer target and can reconcile a wildcard CNAME or an exact per-site CNAME when needed.
• Add custom domains from Edit site details > Domains. Einblick registers the host with the site renderer and shows the CNAME record to create at the DNS provider. Wildcard domains and hosts under the managed Sites domain are rejected.
• Pending custom domains can be checked manually. Einblick also rechecks pending custom domains in the background while DNS propagates, and emails the creator when a domain first becomes active.
• Domain status shows whether DNS is pending, active, disabled, or failed, including the stored DNS error when provisioning fails.
• Domain additions and verification changes are recorded as site-domain activity items that link back to the site.
• Public resolution checks the request host and path against active site domains and published pages.
• Published sites expose page metadata, robots rules, and a sitemap from the rendered site.