Websites

The XWMS shop builder is a custom page and template system that lets a shop owner build a website from reusable templates, dynamic data, colors, and backgrounds inside the admin.

The builder works with pages, templates, live editing, color controls, dynamic data, and snapshots that can be sent to the website runtime.

Yes. Shops can use custom pages with their own slugs, labels, template stacks, page colors, and page backgrounds.

Yes. Each shop can create and manage its own pages instead of being limited to a small fixed set of prebuilt pages.

Yes. The root page stays fixed as the homepage, and the content on that page is built from templates that the shop owner can manage.

Yes. Shops can add new pages and remove existing ones, with the home page kept as the fixed root page.

Yes. Pages use custom slugs, so the shop owner can control the URL structure for shop pages.

Yes. Page links are unique per shop, which prevents duplicate slugs like two pages with the same URL.

Yes. A shop can have multiple pages, and each page can have its own stack of templates and settings.

Yes. The system is built around pages, and each page contains one or more template instances.

Templates are reusable website sections such as headers, footers, heroes, portfolios, contact sections, product layouts, and dynamic data sections.

Yes. The page editor includes a template library with preview cards, collections, search, favorites, and recent usage.

Yes. Templates are grouped into collections so shop owners can browse sections by visual style or shop concept.

Yes. The template library supports search so you can find sections faster when a shop grows larger.

Yes. The template library is built around cards with images, names, descriptions, and actions to preview or use a template.

Yes. Template library preferences can keep track of favorites so frequently used templates are easier to find.

Yes. The template library tracks recent template usage to make repeat editing faster.

Yes. Shared template types such as headers and footers can be synced across pages when needed.

Yes. Shared template syncing supports saving one template’s data across matching templates on multiple pages.

Yes. A shared template can be detached so one page gets its own separate version.

Yes. The shop system includes remote template support for advanced floating headers and footers rendered by the website runtime.

Yes. The page editor is live and autosaves changes while you edit template data.

Yes. The modern page editor saves most changes automatically instead of relying on a separate manual save button for standard edits.

Yes. Templates on a page can be reordered so the section order of the website can be changed visually in the page editor.

Yes. Templates can be removed from a page, with confirmation prompts for destructive actions.

Yes. Pages can have their own color overrides and their own background settings in addition to website-wide defaults.

Yes. Each page can override website-level colors without changing the rest of the shop.

Yes. Product templates are designed to use the same underlying shop product data that is managed in the admin.

Yes. Visitors can connect an XWMS account to a shop so protected and user specific features can work on the website.

Yes. The website can send the visitor into a dedicated XWMS connect flow to link the account with the shop.

Yes. The account icon can trigger a server backed connect flow instead of exposing a simple public link.

Yes. The connect flow is built around secure server side state and token based intent handling.

Yes. The admin includes a shop user resource where the shop owner can view linked shop accounts.

Yes. Certain actions such as protected downloads, forms, or bookings can require a connected shop account.

The website can direct the visitor into the XWMS account connection flow and then return the visitor back to the shop.

Yes. The connect flow supports return URLs so the visitor can continue from the same shop page after login or account connection.

Yes. The shop account flow uses a dedicated connect page with the same sign style layout as the main authentication experience.

Yes. The connect page supports the same eight language set used by the main sign interface.

Yes. A shop account is effectively the link between an XWMS user and a specific shop.

Yes. Shop user relationships are handled as account and business data, while website design data stays in the builder and snapshot layers.

Yes. Runtime templates can show account required states so visitors understand when login or connection is needed.

Yes. Templates can render buttons, chips, and action states that route visitors into the account connect flow.

Yes. File delivery can be restricted to connected shop users and handled through a controlled download flow.

Yes. The shop system supports appointment data that can be exposed to website templates.

Yes. The admin includes appointment management so a shop owner can define appointment options and availability rules.

Yes. Appointment definitions can support different spacing and slot interval patterns.

Yes. Appointment scheduling supports recurring timing concepts such as daily, weekly, and more advanced recurrence setups.

Yes. Appointment definitions can include capacity values so one slot can accept one or many participants.

Yes. Appointment templates can reserve a dynamic area for live appointment data while still keeping the design editable.

Yes. The website supports real appointment booking flows that create records inside the shop system.

Yes. Events can be managed in the admin and rendered on the website through dynamic templates.

Yes. Shops can use an event resource to create and maintain event style content and related data.

Yes. Event templates can be designed to show media, titles, descriptions, and tags in a structured layout.

Yes. Event row content is designed to support multiple presentational combinations as the template system grows.

Yes. Website colors and page colors support separate light and dark mode palettes.

Yes. Light mode and dark mode can each have their own CSS background values, including gradients.

Yes. Website and page backgrounds can use plain colors, gradients, and more advanced CSS background values.

Yes. The website settings support a global background that can be applied across the shop runtime.

Yes. A page background can override the global background while still falling back to the website default when needed.

Yes. The color system is token based so templates can share a compact set of reusable colors instead of hardcoding hundreds of values.

Yes. The color architecture is designed so many templates can share a small set of reusable website, page, and template colors.

Yes. Template colors can inherit from the website, inherit from the page, or override colors only for one template instance.

The website runtime receives snapshot data that contains pages, templates, dynamic data, colors, backgrounds, and shop metadata.

Yes. The runtime payload is designed to contain the website structures and the dynamic store data needed by the remote templates.

A shop snapshot is a stored export of the current shop state that can be validated, restored, or sent to the website runtime.

Yes. The snapshot system can restore the saved shop state, including pages, templates, products, and other supported data.

Yes. The snapshot resource lets you choose a specific saved snapshot and deliver that snapshot to the website server.

Yes. The platform supports automatic snapshot creation so shops have recurring restore points over time.

Yes. Snapshots can be validated so the system can warn about missing assets, missing template types, or other issues before restore.

Yes. Snapshot validation checks for missing templates, missing images, missing logos, and other recoverability issues.

Snapshot metadata is tracked in the database and the full snapshot archives are stored on disk for reliable restore and delivery flows.

Yes. The snapshot restore flow supports products and their related variant structures.

Yes. Snapshot restore includes page structures and template instances so a website layout can be recovered.

Yes. Shop user account links are part of the broader shop state that can be restored from a snapshot.

Yes. Remote templates can receive dynamic data payloads from the store so sections can render products, records, files, and other live content.

Yes. Product pages can be backed by shop product data instead of only static text from the template editor.

Yes. The template system supports product detail layouts that render store data at runtime.

Yes. Product pages can be designed to show variant specific data such as options, pricing, and media.

Yes. Product runtime data can include store media and review style content for richer product layouts.

Yes. The shop system already includes an advanced product setup with variants and related product data.

Yes. A shop can use both standard content pages and dynamic product driven pages within the same website runtime.

Yes. The platform supports shop forms that can be managed in the admin and rendered on the website.

Yes. Shops can define custom forms with different fields and then place those forms into website templates.

Yes. Form submissions are stored in the shop side data model so the owner can review incoming entries.

Yes. Form submissions fit into the shared record architecture used by the shop system.

Yes. The form system is designed to support multiple input and textarea style fields, with room to expand further.

Yes. A form can be placed behind a shop account requirement when that is needed for the workflow.

Yes. Shops can publish files on the website and control how access is granted.

Yes. File access rules can include password protection for specific downloads.

Yes. File access can be restricted to one or more users linked to that shop.

Yes. Protected files use a controlled flow that checks permissions before serving the download.

Yes. Shops can manage quote style business records through dedicated admin resources and related templates.

Yes. Shops can manage communication style records such as threads or business interactions in the admin.

Yes. The runtime can expose those record types to templates so websites can show structured business data visually.

Yes. The platform uses a shared record architecture so multiple feature types can reuse participants, messages, fields, attachments, and links.

Yes. The record schema is designed around indexed shop scoped data instead of pushing everything into one large JSON blob.

Yes. The architecture is built to let those workflows coexist in one shop system with shared patterns and type specific detail tables.

Yes. The shared record model supports participants, messages, attachments, links, and typed field data.

Yes. The builder supports service style flows such as appointments, forms, contact journeys, events, and protected customer actions.

Yes. The system supports products, variants, dynamic product pages, and ecommerce style presentation.

Yes. A single shop can combine custom content pages, product data, appointments, files, and other business workflows.

Yes. Shops can use custom slugs, FAQ pages, and sitemap generation to create a cleaner search engine friendly structure.

Yes. Sitemap generation supports the main public routes and FAQ driven routes so search engines can crawl more of the site.

Yes. Structured FAQ content can answer search intent directly and gives the website more relevant landing pages for long tail queries.

Yes. The system is designed around pages, template libraries, shared data layers, snapshots, and scoped settings so larger shops stay manageable.

Yes. The platform combines website design tools with operational data such as products, users, files, forms, records, and snapshots.

XWMS combines a custom page builder, reusable templates, live editing, snapshots, dynamic data, and operational shop tools in one connected system.

Yes. Templates can stay local to one page so each page can have its own unique content and layout.

Yes. Shared template syncing makes it easier to keep repeated elements like headers and footers aligned across the website.

Yes. The snapshot system gives the shop owner restore points before risky changes and deployments.

Yes. Light and dark mode settings can exist at the website level and the page level so both branding and page mood can be controlled.

Yes. The template architecture is built so each template keeps its own styling scope and avoids conflicts with other sections.

Yes. The builder is designed so a branded site can still be assembled from flexible templates and dynamic data instead of fixed pages.

Yes. Template collections can group sections that belong to one visual concept or shop style so the builder stays organized.

Yes. The template library is shared, but each shop still controls its own pages, colors, data, and layout decisions.