Develop themes, assets and view fallback

Theme package

Themes use the theme manifest category rather than a payment/server/addon bootstrap. Package reviewed views for views/admin, views/customer and views/storefront, plus local assets such as assets/style.css. Optional area layout.blade.php replaces that area's layout; missing overrides fall back to built-in core views. Authentication and installation retain their built-in protected flow.

Select per area

Install and enable the reviewed signed theme, then open System → Appearance in the newer source or System → Themes & appearance in earlier licensed releases, with themes.manage, and select it for admin, customer or storefront. Built-in choices include Cloudlight, Cloudline and Emaila Experience under their stored identifiers. A brand/storefront may choose its permitted local appearance. Selection changes views; it must not alter invoice calculations, customer ownership or permissions.

Preserve safety and usability

Retain CSRF tokens, proper escaping, permission gates, protected confirmation, focus behavior, labels and error feedback. Avoid copying staff-private data into public storefront layouts. Use responsive tables, readable code/long content, keyboard navigation, adequate contrast and reduced motion. Signed Blade is privileged executable template code, not untrusted HTML.

Assets load through the signed local theme route. Respect the application's CSP; a theme cannot assume arbitrary remote scripts are allowed. Do not hide mandatory product attribution/disclosures or create insecure card collection in a decorative checkout override.

Verify and recover

Test all three areas, a restricted staff account, delegated customer, long invoice PDF-related views, missing-view fallback, mobile and no-JavaScript submission. Back up before enabling and keep the built-in fallback available. If package integrity fails, restore the verified exact package rather than editing its manifest or turning off verification.