Customization packages (brand presets)
Customization packages are ready-made brand presets you declare in composer.json. The admin picks one from the sales channel's branding tab and every colour, radius and font on the form fills in with the package's values in one click. They are the fastest way to give customers a "restore defaults" option, or to ship a few curated looks (a light preset, a dark preset, a seasonal palette).
Add a package to composer.json
Packages live under extra.theme.customizationPackages. Each entry needs an id, a label and a branding map. A description is optional but shown to the admin.
{
"extra": {
"theme": {
"customizationPackages": [
{
"id": "evolution-default",
"label": "Evolution Default",
"description": "The original Evolution branding.",
"branding": {
"branding_primary": "#175cd3",
"branding_secondary": "#1d1c1f",
"branding_success": "#2eb67d",
"branding_danger": "#da1e04",
"branding_warning": "#f2ac0d",
"branding_body_bg": "#f5f5f5",
"branding_card_bg": "#ffffff",
"branding_border_color": "#e5e5e6",
"branding_border_radius": 4,
"branding_font_family": "Space Grotesk"
}
}
]
}
}
}The branding map accepts every key the admin's branding form uses. Anything you omit is left at whatever the sales channel already had. See Compile theme SCSS with brand settings for what each key does at compile time.
What the admin sees
Packages render as clickable cards above the individual colour fields on the branding tab. Clicking a card fills every input on the form with the package's values; the admin can then edit any field before saving.
The click is a pure client-side prefill. Nothing about the selection is persisted, so the sales channel stores only the resolved individual values, not the package id. When the admin reopens the tab, they see the current values, not the package they last picked.
Ship at least one package that matches the theme's out-of-box look and label it clearly, so customers who wandered off from the defaults have a one-click way back.