Visual design

Superfunky can be customised without editing source for most store launches. Start with the Control Center and WordPress global styles, use the Layout section's preview and a native WordPress Preview to compare alternatives, then reserve custom CSS or source changes for the final exceptions.

Typography

Open Appearance > FunkyCommerce > Branding to configure:

• display, body, and monospace font-family stacks;
• base font size;
• type-scale ratio;
• the default colour mode: device, light, or dark.

Use valid CSS font-family values. A named web font must also be loaded by WordPress, a font provider, or the storefront; entering its name alone does not download the font.

WordPress font faces and global typography are also transferred to the storefront. Body, heading, link, caption, and button font choices made through global styles are applied to their equivalent headless elements.

Width, spacing, colour, and motion

The Control Center Visual & CSS section provides:

• post maximum width;
• page maximum width;
• reduced-motion protection;
• custom storefront CSS.

WordPress theme.json supplies the editor's brand, background, and foreground colours, fluid typography, spacing tools, and content/wide widths. Changes made through the Site Editor remain the right choice for Gutenberg content.

The storefront maps the WordPress brand colour into a complete tonal scale used by its brand utilities. It also maps WordPress background and foreground colours to the storefront theme variables.

Layout

Open Appearance > FunkyCommerce > Layout to configure the site-wide storefront composition, including:

• announcement-bar visibility and scroll behaviour;
• sticky header, search style, logo style, icon visibility, and cart drawer/dropdown;
• content maximum width, border radius, breadcrumbs, and brand palettes;
• newsletter-popup style and cooldown;
• footer visibility, columns, newsletter, logo, bottom bar, and module arrangements;
• physical or digital checkout, field visibility, coupon placement, payment position,

and order-summary behaviour;

• home hero, product/post/community archive heroes, and product/wishlist card variants;
• the cart layout and summary position;
• the shared community-profile and journal-author header layout (six variants each,

chosen independently) and the discussion (comments/reviews) layout.

Community member profiles and journal author pages render the same shared header component with six selectable variants — card, cover-banner, compact-list, immersive, split, and strip — but each surface has its own Layout field (Community profile header and Journal author profile header), so the two can use different variants. Both surfaces also share a single canonical cover image per person: authors edit it from their WordPress user-profile screen (Users > Profile > Community cover), and it appears identically as the community profile banner and as the journal author archive's coverUrl. There is only one cover per person, not a separate one for each context.

The Layout section renders a lightweight preview canvas in wp-admin that updates as fields change, so you can judge width, radius, palette, and a few structural choices before saving. It is an approximation, not a pixel-accurate render of the storefront. For a faithful check, open WordPress' native page/post Preview: when the signed-in user has permission to edit the object, it mirrors the current Layout settings and shows the real header/footer navigation menus. Preview access always requires sign-in and edit permission regardless of that mirroring toggle; disabling the toggle (Deployment > Mirrored native previews) turns off native Preview entirely.

Every Layout field is a single, canonical value applied to every visitor — there is no separate public storefront route for comparing alternatives and no personal per-user layout preference. Saving a field updates the live storefront immediately, without a rebuild. Product, post, archive, community, and individual shortcode instances can still expose their own layout/card_variant/view attributes (see Shortcodes), which override the Layout section's default only for that specific shortcode instance.

Menus

Create menus under Appearance > Menus and assign these theme locations:

Location	Purpose
Header Menu	Primary desktop navigation
Mobile Menu	Mobile navigation; may differ from desktop
Footer Menu	Footer links and hierarchy

Superfunky reads menu labels, descriptions, URLs, targets, CSS classes, link relationships, parent/child hierarchy, and order. Use absolute URLs only for external destinations. Keep internal links on the public storefront hostname.

Open Screen Options at the top of the WordPress menu editor and enable Description, CSS Classes, Link Target, and Link Relationship (XFN) when those fields are hidden. Descriptions appear as secondary text in header and footer menus. They may contain the same safe inline HTML accepted by other CMS content; the storefront sanitizes the markup before rendering it. Items without descriptions retain the standard compact spacing.

Menu hierarchy is recursive rather than limited to a fixed number of levels. Parent items with descendants receive an expand/collapse control where the selected layout needs one. Desktop header mega menus use first-level children as columns and retain deeper descendants inside each column. Mobile navigation always uses the recursive accordion layout.

Mega menus

Add one of these CSS classes to a top-level Header Menu item:

Class	Result
mega	Enables a desktop mega menu and derives the column count from the number of first-level children, between 2 and 14
mega-2 to mega-14	Enables a desktop mega menu with that explicit number of columns

The numbered class works by itself; it does not also require mega. Invalid values such as mega-1, mega-15, or mega-04 are ignored and leave the item as a regular dropdown. Very wide configurations remain bounded by the viewport and can scroll horizontally rather than clipping columns. Mega classes affect desktop presentation only, so the same hierarchy stays usable as an accordion in the mobile menu.

Expanded descendants

Add the exact CSS class expanded to any parent menu item whose descendant section should start open. All mobile parent items start closed without this class. It also works in regular desktop dropdowns, nested mega-menu groups, and footer accordions. Visitors can still collapse the section. On a top-level desktop header item, expanded does not keep the entire popover permanently visible; the popover continues to use hover, click, keyboard, and outside-click behavior.

After changing a menu:

1. confirm the correct display location is assigned;
2. clear any WordPress, GraphQL, or edge cache;
3. test parent and child links on desktop and mobile;
4. verify descriptions and every nested level remain readable in light and dark modes;
5. verify wide mega menus can reach every column at the target desktop widths;
6. verify external links that open a new tab have an appropriate link relationship.

Custom CSS

Use Appearance > FunkyCommerce > Visual & CSS > Custom storefront CSS for a small, site-wide override. WordPress Additional CSS is included too.

Scope rules to the smallest stable selector:

.wp-site-blocks.entry-content .wp-block-button__link {
  letter-spacing: 0.02em;
}

The storefront loads WordPress block styles, font faces, global styles, Additional CSS, and Control Center CSS. Its block-compatibility layer loads last so alignment, columns, media, and responsive block behaviour survive collisions with application CSS.

Avoid:

• selectors based on temporary DOM depth;
• broad rules for button, img, or a that affect application controls;
• hiding required checkout or account fields with CSS;
• copying generated Tailwind CSS into the Control Center;
• !important unless it is required to override a known compatibility rule.

When to edit source

Edit the MIT storefront source when you need a new component, route, design token, Tailwind utility, interaction, or layout that the existing controls cannot express. Source changes require a new production build and deployment.

Keep reusable components in the shared UI package and storefront-specific composition in the storefront application. Test a production build, not only the development server: Tailwind generates utilities from classes it can find in the configured source paths.

Visual acceptance checklist

• Logos remain legible on light and dark surfaces.
• Heading, body, form, and monospace fonts load without layout shifts.
• Header and footer menus work at mobile and desktop widths.
• Content does not overflow the configured page and post widths.
• Gutenberg wide/full alignments behave as intended.
• Checkout controls remain visible and keyboard accessible.
• Reduced-motion mode removes non-essential animation.
• Custom CSS does not change WordPress admin or backend API responses.

Next: configure brand and identity.