Module Wrapper
Every module in Scorecenter can be wrapped with a title bar and card chrome -- visual treatments that frame the module's content without changing what the module does. The wrapper is configured per module instance, so the same module type can look different on different pages.
Wrapper options
| Option | Values | Default | Description |
|---|---|---|---|
| title | Any text or blank | (empty) | Heading displayed above the module content. Supports template variables. |
| subtitle | Any text or blank | (empty) | Smaller text displayed below the title. Supports template variables. |
| card_style | Global, None, Soft, Bordered, Flat, Elevated | Global | Visual treatment applied to the module's container. |
| padding | Global, None, Default, Tight | Global | Interior spacing between the card edge and the module content. |
| radius | Global, None, SM, MD, LG, XL, 2XL | Global | Border radius (corner rounding) of the card. |
| background_color | CSS color, gradient, token, or blank | (empty) | Optional custom wrapper background. Values are sanitized before rendering. |
| border_color | CSS color, token, none, or blank | (empty) | Optional custom border color. Use none to remove the visible border for supported cards. |
| text_color | CSS color, token, or blank | (empty) | Optional custom wrapper text color for modules that inherit wrapper text. |
| split | On / Off | Off | When enabled, each logical section inside the module gets its own card instead of one card wrapping everything. |
The Global option for card_style, padding, and radius inherits from your site-wide Styles settings. This keeps your pages visually consistent without configuring every module individually. Override with a specific value only when you need a module to stand out.
Card styles explained
None
No card container at all. The module content renders directly on the page background with no visible boundary. Use this for modules that provide their own visual framing (like a hero image) or when you want modules to flow seamlessly into each other.
Soft
A subtle background fill with no border. The card is distinguished from the page background by a slight color shift (typically a lighter or darker shade depending on theme). This is the most understated card style.
Best for: clean, modern designs where you want separation without hard edges.
Bordered
A thin border around the module with no background fill. The interior matches the page background, and the border provides the visual boundary. Works well in both light and dark themes.
Best for: traditional layouts, sites that want clear module boundaries without color shifts.
Flat
A solid background fill with no border and no shadow. Similar to Soft but with a more pronounced background contrast. The module feels like a distinct panel.
Best for: dashboard-style layouts, high-density pages where each module needs to be clearly delineated.
Elevated
A background fill combined with a drop shadow that gives the card a raised, floating appearance. The most visually prominent card style.
Best for: hero modules, featured content, or any module you want to draw attention to. Use sparingly -- too many elevated cards compete for attention.
Padding options
| Value | Spacing | When to use |
|---|---|---|
| None | 0px | Full-bleed content like images, maps, or video that should touch the card edges |
| Tight | 8px -- 12px | Compact modules in sidebars or dense layouts where space is limited |
| Default | 16px -- 24px | Standard spacing for most modules, comfortable breathing room |
Radius options
| Value | Corners | Visual effect |
|---|---|---|
| None | 0px | Sharp, squared-off corners. Industrial, no-nonsense look. |
| SM | 4px | Barely rounded. Subtle softening. |
| MD | 8px | Moderately rounded. The most common default. |
| LG | 12px | Noticeably rounded. Softer, friendlier feel. |
| XL | 16px | Very rounded. Modern, app-like aesthetic. |
| 2XL | 24px | Heavily rounded. Pill-like cards for bold designs. |
Split mode
When split is enabled, the module's internal sections render as separate cards instead of being grouped under one wrapper. This is useful for modules that contain multiple logical blocks.
Example without split: A standings module shows the league header, the table, and the form guide all inside one card.
Example with split: The same standings module shows the league header as one card, the table as a second card, and the form guide as a third card -- each with its own card_style, padding, and spacing.
Split mode respects the card_style and padding settings -- each sub-card inherits the wrapper configuration.
Card section container
Use Card section when you want a configurable card that contains several child modules. It is similar to a one-column section builder:
- The container owns the card style, radius, padding, gap, background, border, and text color.
- Child modules own their own content and data settings.
- It is best for reusable landing-page blocks, sidebars, promotional cards, or mixed editorial sections.
Avoid wrapping every child in its own heavy card inside a Card section unless you intentionally want nested chrome.
Nesting limits
Scorecenter supports controlled nesting, not infinite nesting:
- Public rendering supports module trees up to depth 4.
- The CMS warns on deep nesting and blocks adding modules above the render limit.
- Avoid Card section inside Card section and Grid inside Grid. Use one Card section with child modules, or mix Grid and Card section when you need columns inside a card or cards inside columns.
- Very large page trees can become slow to edit and heavy to render. Keep each page/template under roughly 120 modules.
Template variables in titles
Wrapper titles and subtitles support template variables that resolve to real entity data on dynamic template pages. This lets you create contextual, data-driven headings.
Available variables
On dynamic template pages, all entity-specific variables from the template variables reference are available in wrapper titles. The most commonly used ones:
| Variable | Resolves to |
|---|---|
[country_name] | Country name (e.g. "England") |
[league_name] | League name (e.g. "Premier League") |
[team_name] | Team name (e.g. "Arsenal") |
[player_name] | Player name (e.g. "Kylian Mbappe") |
[home_name] | Home team (match pages) |
[away_name] | Away team (match pages) |
[season_name] | Season label (e.g. "2025-2026") |
[site_name] | Your site name |
[entity_name] | Display name of the current entity |
Examples
Variables on static pages
On static pages (not dynamic templates), entity-specific variables like [league_name] or [team_name] are not available because there is no entity context. Only global variables work:
| Variable | Available on static pages |
|---|---|
[site_name] | Yes |
[lang] | Yes |
[theme] | Yes |
[league_name], [team_name], etc. | No -- renders as blank |
If you use an entity variable on a static page, it will render as an empty string. The title will still display, just without that segment.
Best practices
- Be consistent -- use the Global card_style across most modules so your site has a unified look. Override only for emphasis.
- Match padding to context -- use Default padding for main region modules and Tight for sidebar modules.
- Use titles strategically -- not every module needs a title. Modules with built-in headers (like match header or league header) already identify themselves.
- Avoid over-elevating -- if every module uses Elevated, nothing stands out. Reserve it for 1-2 featured modules per page.
- Test split mode -- some modules look better split, others look better unified. Preview both before deciding.