RFC: First-class white-labeling for the EmDash admin & login (completing #639) #1493

marcusbellamyshaw-cell · 2026-06-15T19:30:52Z

marcusbellamyshaw-cell
Jun 15, 2026

TL;DR — EmDash already shipped the seed of admin white-labeling
(admin: { logo, siteName, favicon }, from approved Discussion
#639 / PR
#705). But that work shipped
incomplete: its own approved scope named the "Login/onboarding page (large
logo)" as a target, yet the login page — plus signup and invite-accept — still
ignore the configured branding. And there's still no way to customize colors,
copy, layout, or replace a surface with your own component without forking core.

This RFC consolidates the scattered, separately-approved/prototyped threads
(#639 merged,
#1241 prototyped,
#826 fallback idea,
#1132 login-UX pain,
#137 upgrade-safety)
into one coherent, additive, fully backward-compatible white-labeling design,
so agencies and enterprises can rebrand — or completely replace — the login and
admin UI without editing core (the thing WordPress never solved).

It's structured to merge in small, low-risk steps. Step 0 is a bug fix
(it completes the approved-and-merged #639 promise, so it fits CONTRIBUTING.md's
bug-fix-with-failing-test lane); every later tier is an optional, additive
feature gated behind this Ideas Discussion.

AI disclosure (per CONTRIBUTING.md): drafted with assistance from Claude
(Anthropic, claude-opus-4-8); all code and claims verified against the
repository at the cited file:line.

Screenshots — the same login screen, branding off vs on

Both screens are the stock login with authProviders: [github(), google()] configured; the only difference is the admin branding block (Step 0 fix applied, captured from a running instance via the dev-bypass). Before/after images attached below.

1. Motivation

A core EmDash goal is to be a better WordPress. Today EmDash shares WordPress's
biggest white-labeling weakness: you can't fully customize the login and admin
UI without editing core, and such edits are lost on upgrade — the exact
"don't-fork-core / survive-upgrades" problem raised in
#137.

But EmDash is far closer to solving it than WordPress, and the maintainers have
already endorsed the goal:

#639 ("Admin
white-labeling") was approved by @ascorbic ("This sounds like a good
idea. Setting in config makes sense… Happy for you to open a PR") and merged
as #705. Its changelog:
"Adds admin white-labeling support via admin config… Agencies can set a
custom logo, site name, and favicon for the admin panel." The original
request explicitly listed "Login/onboarding page (large logo)" as a target
surface.
#1241 ("Admin UI &
Login Page Customization") is an active thread where a maintainer-side
contributor (@bergaaberg, who runs a white-label multi-tenant platform)
responded "It's small. It follows how admin.favicon already works,"
prototyped admin.customCss / login-copy overrides / accent color, and
offered to open a PR with a changeset.
#826 asks for a
config → Site Identity → default branding fallback chain.
#1132 reports the
default login UX is "confusing for non-technical users… doesn't explain what
passkeys are or provide clear fallback guidance."

This RFC unifies those into one design. The incumbents set a low bar to beat:
Strapi gates full wordmark removal behind a paid Enterprise license;
WordPress can't touch login/admin without core edits lost on upgrade. EmDash
can offer free, additive, open, zero-fork white-labeling — and should.

2. Current state (verified against `main`)

2.1 What already exists (from #639 / #705)

packages/core/src/astro/integration/runtime.ts:503-529 — the public
EmDashConfig.admin option. Its docstring markets it as white-labeling for
"agency or enterprise deployments" and promises the logo applies to the
"login page, sidebar":

admin?: {
    /** URL or path to a custom logo image for the admin UI (login page, sidebar). */
    logo?: string;
    /** Custom name displayed in the admin sidebar and browser tab. */
    siteName?: string;
    /** URL or path to a custom favicon for the admin panel. */
    favicon?: string;
};

The same shape is declared in three hand-synced places: the integration
config above, the manifest response interface
packages/core/src/astro/types.ts:194-198, and the admin client
packages/admin/src/lib/api/client.ts:183-187 (AdminManifest.admin).
It's plumbed end-to-end: integration → middleware → locals.emdash.config.admin
→ exposed via the manifest route
(packages/core/src/astro/routes/api/manifest.ts:42,64,75; the value comes
from locals.emdash.config.admin, not a build-time global) →
fetchManifest() (client.ts:208) → React.
The HTML shell honors siteName/favicon:
packages/core/src/astro/routes/admin.astro:22-23,32-33,40,92 (page
<title>, favicon <link>, boot-loader text). (Astro auto-escapes
attribute expressions, so the favicon href isn't an injection vector today;
see §7.)
BrandLogo/BrandIcon already accept a custom logo and fall back to the
hardcoded EmDash gradient mark
(packages/admin/src/components/Logo.tsx:156-188).
Two authenticated surfaces wire branding correctly via the manifest fetch:
Sidebar (Sidebar.tsx:394-396) and Setup wizard
(SetupWizard.tsx:553-555).
The theming substrate is ready: styles.css:32-75 overrides Kumo's
semantic tokens under [data-theme="classic"], and ThemeProvider.tsx:71-77
documents data-theme as "reserved for visual identity overrides" — but
hardcodes it to "classic" (line 76).

2.2 What's broken or missing

(A) The pre-auth surfaces ignore the branding they're documented to honor.
Three customer-facing, pre-auth screens render the hardcoded EmDash mark:

LoginPage.tsx:214 and :226 — <BrandLogo … /> with no
logoUrl/siteName.
SignupPage.tsx:397 — renders LogoLockup directly (imported at line 20).
InviteAcceptPage.tsx:204 — same.

So a configured admin.logo appears in the sidebar/setup wizard but not on
login, signup, or invite — directly contradicting #639's approved scope and
the docstring in §2.1.

(B) These surfaces have no branding source pre-auth. Branding reaches React
via the manifest, but the manifest endpoint is not in the public allowlist
(PUBLIC_API_PREFIXES/PUBLIC_API_EXACT, auth.ts:94-122) — authenticated
pages (Sidebar, SetupWizard) fetch it fine, but the unauthenticated login/
signup/invite pages cannot. (/_emdash/api/auth/mode is public — line 115 —
and login already calls it.) This is the root cause of (A): there's no
synchronous, pre-auth branding channel.

(C) Branding arrives via an authenticated async fetch, so authenticated
pages briefly flash the EmDash logo before the custom one loads. There's no
single synchronous source of truth, even though admin.astro has the config
server-side and simply doesn't pass it to React (admin.astro:95 renders
<AdminWrapper> with only locale/messages; PluginRegistry.tsx:16-30
forwards only those).

(D) Branding is limited to logo + name + favicon. No brand colors/theme, no
custom font, no login background, no custom copy, no dark-mode logo, no
"powered by" control, no custom head/CSS — the gaps #1241 and #826 ask for.

(E) There's no escape hatch for full control. The login UI is a fixed,
single-column centered card (LoginPage.tsx:222-353) with no seams to change
layout, add a marketing panel, reorder/hide auth methods, or add footer links —
and no way to replace it wholesale with a custom React component, even though
EmDash already has the exact injection pattern (auth-provider/plugin-admin
modules; see §4.2) and a documented react-admin plugin rail.

(F) The default login UX is weak (corroborated by #1132): page background
(bg-kumo-base) and card background (bg-kumo-base) are identical so the card
barely separates; magic-link is buried as a ghost button (:284-291); help
text duplicates the card contents (:321-327); passkeys aren't explained.

(G) Other hardcoded "EmDash" surfaces a full white-label must address:

WelcomeModal.tsx:96 — hardcodes "Welcome to EmDash, {name}!" (shown to
every new user).
Sidebar.tsx:463 — footer falls back to "EmDash CMS" when siteName unset.
Logo.tsx:74 — aria-label="EmDash" on the mark (screen-reader brand name,
not customizable).
Page <title> after SPA navigation may revert from the branded Astro-time
title (admin.astro:40).
Help/marketing copy (e.g. PluginManager.tsx) references "EmDash" (lower
priority; Lingui strings).

3. Goals & non-goals

Goals

Zero-code rebrand of login + admin via config.
Complete component replacement of the login screen (and other surfaces) when
config isn't enough — wrap-don't-reimplement.
Branding available synchronously and pre-auth (no flash; fixes login/
signup/invite).
100% backward compatible — every new field optional; with none set, output
is byte-for-byte today's EmDash.
Improve the default login UX (responding to Bug Report + UX: Subscriber role has excessive admin access + login page needs overhaul #1132).

Non-goals (first PRs) — runtime/DB-stored branding editable from the admin UI
for multi-tenant self-service (#826).
Deliberately deferred; the BrandingProvider (§4.1) is designed so the same
context can later be fed from DB settings. This is exactly Directus's model
(§4.5), so the phasing is "config-now, DB-later," not a missing capability.

4. Proposed design (tiered, additive)

One coherent system in three tiers; each independently mergeable. Each tier maps
to an accepted competitor precedent (§4.5) so reviewers see convention, not
novelty.

Step 0 — Fix the pre-auth logo (bug fix; ships first, own lane)

Per CONTRIBUTING.md, this is a bug fix (it completes the approved-and-merged
#639 promise), so it can open directly with a failing test. It needs a pre-auth
branding source, which is the small Tier-1 wiring below; once that's in,
LoginPage, SignupPage, and InviteAcceptPage consume useBranding() and pass
logoUrl/siteName to BrandLogo. A failing LoginPage test (renders the
configured logo) locks it in (TDD-for-bugs).

Tier 1 — Server-inject branding (synchronous, pre-auth) + finish the wiring

1a. Add a BrandingProvider React context, mirroring the existing
PluginAdminProvider (plugin-context.tsx) and AuthProviderProvider
(auth-provider-context.tsx) exactly.

New file packages/admin/src/lib/branding-context.tsx:

import * as React from "react";
import { createContext, useContext } from "react";

/** White-label branding for the admin UI. All fields optional. */
export interface AdminBranding {
	logo?: string;
	/** Logo variant used when the resolved theme is dark. */
	logoDark?: string;
	siteName?: string;
	favicon?: string;
	/** Hide the "Powered by EmDash" mark. Default: shown. */
	hidePoweredBy?: boolean;
	/** Brand color overrides → Kumo tokens (Tier 3). */
	colors?: { brand?: string; brandHover?: string };
	/** Login-page declarative customization (Tier 1b). */
	login?: {
		layout?: "centered" | "split";
		background?: string;
		heading?: string;
		subheading?: string;
	};
}

const BrandingContext = createContext<AdminBranding>({});

export function BrandingProvider({
	children,
	branding,
}: {
	children: React.ReactNode;
	branding: AdminBranding;
}) {
	return <BrandingContext.Provider value={branding}>{children}</BrandingContext.Provider>;
}

export function useBranding(): AdminBranding {
	return useContext(BrandingContext);
}

1b. Thread branding through the existing props pipeline, identical to
pluginAdmins/authProviders.

packages/admin/src/App.tsx:

 import { AuthProviderProvider, type AuthProviders } from "./lib/auth-provider-context";
+import { BrandingProvider, type AdminBranding } from "./lib/branding-context";
 import { PluginAdminProvider, type PluginAdmins } from "./lib/plugin-context";

 export interface AdminAppProps {
 	pluginAdmins?: PluginAdmins;
 	authProviders?: AuthProviders;
+	/** White-label branding, injected server-side from admin.astro */
+	branding?: AdminBranding;
 	locale?: string;
 	messages?: Messages;
 }

 const EMPTY_AUTH_PROVIDERS: AuthProviders = {};
+const EMPTY_BRANDING: AdminBranding = {};

 export function AdminApp({
 	pluginAdmins = EMPTY_PLUGINS,
 	authProviders = EMPTY_AUTH_PROVIDERS,
+	branding = EMPTY_BRANDING,
 	locale = "en",
 	messages = {},
 }: AdminAppProps) {
 	...
 	return (
 		<ThemeProvider>
+			<BrandingProvider branding={branding}>
 			<I18nProvider i18n={i18n}>
 				... <RouterProvider router={router} /> ...
 			</I18nProvider>
+			</BrandingProvider>
 		</ThemeProvider>
 	);
 }

Export from packages/admin/src/index.ts:

+export { BrandingProvider, useBranding, type AdminBranding } from "./lib/branding-context";

packages/core/src/astro/routes/PluginRegistry.tsx — this file is in core and
already imports from @emdash-cms/admin (line 9), so importing the type here is
valid (the dependency edge already exists):

 import { AdminApp } from "@emdash-cms/admin";
+import type { AdminBranding } from "@emdash-cms/admin";
 import type { Messages } from "@lingui/core";

 interface AdminWrapperProps {
 	locale: string;
 	messages: Messages;
+	branding?: AdminBranding;
 }

-export default function AdminWrapper({ locale, messages }: AdminWrapperProps) {
+export default function AdminWrapper({ locale, messages, branding }: AdminWrapperProps) {
 	return (
 		<AdminApp
 			pluginAdmins={pluginAdmins}
 			authProviders={authProviders}
 			locale={locale}
 			messages={messages}
+			branding={branding}
 		/>
 	);
 }

packages/core/src/astro/routes/admin.astro already has adminConfig (line 22):

-<AdminWrapper client:only="react" locale={resolvedLocale} messages={messages} />
+<AdminWrapper client:only="react" locale={resolvedLocale} messages={messages} branding={adminConfig} />

Type-sourcing note (resolves the one critical review finding). core
depends on admin, not the reverse, so core/src/astro/types.ts and
runtime.ts cannot import AdminBranding from @emdash-cms/admin (and the
reverse would be circular). Tier 1 doesn't need them to: the AdminWrapper
prop is typed in PluginRegistry.tsx (which already imports from admin), and
admin.astro passes the existing {logo,siteName,favicon} value, which is
structurally assignable to the (all-optional) AdminBranding. When later tiers
add fields to EmDashConfig.admin, the clean fix is to host the shared
AdminBranding in a neutral leaf package (e.g. @emdash-cms/plugin-types) that
both core and admin already build on — eliminating today's three-way
hand-synced duplication (§2.1). Flagged here as a design decision for
maintainers; not required for Step 0 / Tier 1.

1c. Fix the three pre-auth surfaces to read useBranding() and pass
logoUrl={branding.logo} / siteName={branding.siteName} to BrandLogo
(LoginPage.tsx:214,226; SignupPage.tsx:397; InviteAcceptPage.tsx:204).

1d. Make the brand mark accessible. BrandLogo/LogoLockup should accept an
aria-label so the screen-reader name matches siteName instead of the
hardcoded aria-label="EmDash" (Logo.tsx:74).

1e. Migrate Sidebar/SetupWizard to useBranding() (single synchronous
source; removes the flash), keeping the manifest field as a fallback. Change the
Sidebar footer fallback (Sidebar.tsx:463) from "EmDash CMS" to siteName or
a neutral default, and make WelcomeModal (WelcomeModal.tsx:96) greet with
siteName.

Tier 1b — Declarative login customization (feature)

Render branding.login.{layout,background,heading,subheading} in the default
LoginPage (centered vs split, brand panel/background, custom copy) + apply
hidePoweredBy and logoDark. Maps to #1241's request and Strapi's
config.auth (§4.5).

Tier 2 — Component override / slot system (the escape hatch; login-first)

Let integrators replace specific surfaces with their own React components —
modeled on the existing auth-provider/plugin-admin injection (props → virtual
module → context → resolver) and the documented react-admin plugin rail.

New packages/admin/src/lib/branding-components.tsx (mirrors plugin-context.tsx):

export interface LoginScreenProps {
	redirectUrl: string;
	onSuccess: () => void;
	/** The built-in screen, so authors can wrap rather than reimplement. */
	renderDefault: () => React.ReactNode;
}

export interface BrandingComponents {
	LoginScreen?: React.ComponentType<LoginScreenProps>;
	BrandMark?: React.ComponentType<{ className?: string }>;
	LoginHeader?: React.ComponentType;
	LoginFooter?: React.ComponentType;
	SidebarHeader?: React.ComponentType;
	WelcomeModal?: React.ComponentType;
}

renderDefault (borrowed from Sanity Studio) is the key ergonomic: every
override receives the built-in surface, and EmDash already exports the auth
primitives (PasskeyLogin, useAuthProviderList, fetchAuthMode), so a custom
LoginScreen can wrap/extend instead of reimplementing WebAuthn/magic-link. This
directly answers the maintainers' likely worry that a custom login will rot when
internal auth changes.

Default surfaces consult the override first, e.g.:

const Custom = useBrandingComponent("LoginScreen");
if (Custom) return <Custom redirectUrl={safeRedirectUrl} onSuccess={handleSuccess} renderDefault={renderDefaultLogin} />;
// …built-in LoginPage JSX

Integration wiring follows the exact authProviders precedent
(vite-config.ts:35-36,191-193,253-255; virtual-modules.ts —
VIRTUAL_AUTH_PROVIDERS_ID / generateAuthProvidersModule):
EmDashConfig.admin.components?: string (a module path) → new
VIRTUAL_BRANDING_COMPONENTS_ID + generateBrandingComponentsModule() →
PluginRegistry.tsx imports it → AdminApp wraps in
BrandingComponentsProvider. No new architecture.

Tier 3 — Design tokens + theme + head injection (visual rebrand, no JS)

Promote data-theme from hardcoded "classic" to branding-driven
(ThemeProvider.tsx:76).
Generate a scoped token block from admin.colors in admin.astro mapping
to the documented Kumo vars (--color-kumo-brand, --color-kumo-brand-hover,
--text-color-kumo-brand) — server-rendered, no flash.
Optional admin.customCss (a file path, like Payload's admin.css),
injected into the admin shell. Scope it via cascade layers (@layer) and the
admin-root selector to avoid the public-page bleed already tracked in issue
#1281 — aligning with the
fix direction the maintainers are already discussing.
Custom fonts already work via the existing fonts integration option
(styles.css:78-90); document it as part of branding.

A white-label "theme" is just a [data-theme="<id>"] token bundle — the same
model the theme marketplace manipulates
(ThemeMarketplace*.tsx, lib/api/theme-marketplace.ts); Tier 3 should reuse it
rather than fork it.

4.5 Precedent (each tier is conventional)

Tier	EmDash	Closest precedent
1: declarative logo/name/favicon/colors	`admin: { logo, siteName, favicon, colors }`	Payload `admin.meta` (`icons[]`, `titleSuffix`); Strapi `config.auth.logo` (login) vs `config.menu.logo` (nav), `head.favicon`, `theme.light/dark`
1b: login copy/layout	`admin.login.{heading,…}`	Strapi `config.auth` + `translations`; Directus `public_background`
2: component overrides	`admin.components` → `BrandingComponents`	Payload `admin.components.graphics.Logo` (the login mark) / Sanity `studio.components.{logo,navbar,layout}` + `renderDefault`
3: tokens / customCss	`admin.colors` → Kumo vars, `admin.customCss`	Strapi `theme.` token overrides; Directus* `custom_css` + `theme_*_overrides`
§3 non-goal (DB-stored)	future: `BrandingProvider` fed from settings	Directus runtime `settings` (`project_logo`/`project_color`/`custom_css`)

Two precedents are especially decisive: Strapi gives the login logo its own
config.auth.logo field distinct from the nav logo — independent evidence that
login deserves first-class treatment (the §2.2A bug). And Payload's
admin.components.graphics.Logo is literally the login-view mark — confirming
"login-first" framing. (APIs cited are the current shapes: Payload v3
admin.meta.icons[] / admin.css as a path / components.graphics.*; Sanity
passes real imported components, not string paths.)

5. Example usage

No-code rebrand:

emdash({
  admin: {
    logo: "/brand/acme-logo.svg",
    logoDark: "/brand/acme-logo-dark.svg",
    siteName: "Acme Studio",
    favicon: "/brand/favicon.ico",
    hidePoweredBy: true,
    colors: { brand: "#7C3AED", brandHover: "#6D28D9" },
    login: { layout: "split", background: "/brand/login-bg.jpg", heading: "Welcome to Acme Studio" },
  },
})

Full takeover:

emdash({ admin: { siteName: "Acme Studio", components: "./src/emdash/branding.tsx" } })

// src/emdash/branding.tsx
import { PasskeyLogin } from "@emdash-cms/admin";
import type { BrandingComponents } from "@emdash-cms/admin";

export const LoginScreen: BrandingComponents["LoginScreen"] = ({ onSuccess, renderDefault }) => (
  <div className="acme-login">
    {/* your layout/marketing/copy — or `renderDefault()` to wrap the built-in */}
    <PasskeyLogin
      optionsEndpoint="/_emdash/api/auth/passkey/options"
      verifyEndpoint="/_emdash/api/auth/passkey/verify"
      onSuccess={onSuccess}
    />
  </div>
);

6. Default login UX improvements (responds to #1132)

Grounded in LoginPage.tsx:212-353:

Separate card from page — both are bg-kumo-base (:222, :244); use
bg-kumo-elevated/the brand background so the card reads as a surface.
Optional split layout (login.layout: "split") — brand panel + form.
Fix method hierarchy + explain passkeys — magic-link is a low-affordance
ghost after a confusing "Or continue with" divider (:255-291); Bug Report + UX: Subscriber role has excessive admin access + login page needs overhaul #1132 says
users don't understand passkeys. Present passkey/email as clear peers with a
one-line passkey explainer and fallback guidance.
Trim redundant help text (:321-327).
Dark-mode-aware logo (logoDark).

Before/after screenshots (captured via the documented dev-bypass,
GET /_emdash/api/setup/dev-bypass?redirect=/_emdash/admin) will be attached.

7. Cross-cutting concerns (merge-readiness)

Backward compatibility. Every new field optional; defaults reproduce
today's EmDash exactly. Additive — no migrations, no breaks.
Security. Logo/favicon/background URLs are interpolated in server-rendered
Astro, which auto-escapes attribute expressions; the existing escapeHtmlAttr
helper (packages/core/src/page/metadata.ts:37, as used in
site-identity.ts:49) is available for any non-template interpolation.
customCss is build-time/trusted but should still be scoped via cascade
layers + the admin-root selector (re: issue Admin stylesheet bleeds into public pages in astro dev, overriding host design tokens (layer-ordering) #1281) and run through
sanitize-html (already a core dep, packages/core/package.json) where
user-supplied HTML is involved; document CSP implications.
i18n. New built-in strings via Lingui (useLingui/<Trans>), RTL-safe
logical Tailwind. Per CONTRIBUTING.md, do not commit messages.po in
feature PRs.
Tests. Add a failing LoginPage test that asserts a configured logo
renders (locks the §2.2A fix) + useBranding unit test;
packages/core/tests/unit/astro/manifest-route.test.ts:47-82 already covers
the existing fields and gets new cases as fields are added.
Docs. Create an admin white-labeling docs page — the merged Admin white-labeling: custom logo and site name in the admin UI #639 config
is currently undocumented (no mention in reference/configuration.mdx,
concepts/admin-panel.mdx, or themes/overview.mdx); a welcome docs win.
Changeset. Minor bump for @emdash-cms/admin + emdash/core.
Process. Per CONTRIBUTING.md: this RFC is the Ideas Discussion seeking the
"Approved for PR" label for the feature tiers; Step 0 ships as a direct
bug-fix PR with a failing test; AI disclosure included; small PRs per §8.

8. Rollout (small, reviewable PRs)

PR 1 — Step 0 (bug fix): BrandingProvider + thread branding through
admin.astro → AdminWrapper → AdminApp, fix login/signup/invite logos +
aria-label, failing-test-first. (Completes Admin white-labeling: custom logo and site name in the admin UI #639; bug-fix lane.)
PR 2 — Tier 1b + default UX: login config, hidePoweredBy, logoDark,
Sidebar/WelcomeModal fallbacks, §6 polish.
PR 3 — Tier 2: component overrides + virtual-module wiring + renderDefault.
PR 4 — Tier 3: colors → Kumo tokens, branding-driven data-theme,
layer-scoped customCss.
Follow-up (feat(admin): use Site Identity logo/favicon as admin panel branding default #826): runtime/DB-stored branding from the settings UI — drops
into the same BrandingProvider.

9. Why this approach

It finishes approved-and-merged work (Admin white-labeling: custom logo and site name in the admin UI #639/feat: admin white-labeling (custom logo, site name, favicon) #705) and consolidates
Feature Request: Admin UI & Login Page Customization #1241/feat(admin): use Site Identity logo/favicon as admin panel branding default #826/Bug Report + UX: Subscriber role has excessive admin access + login page needs overhaul #1132/Does EmDash need a child theme concept? #137 — convention, not novelty.
It reuses EmDash's own idioms (context providers + virtual modules + props
pipeline; the documented react-admin rail) — no new architecture.
Strictly backward compatible, in small low-risk steps, with the
bug-fix shipping first.
It solves the login page specifically — config for the common case, full
component replacement for the hard case, and a better default for everyone —
and beats the incumbents (free vs Strapi's paid wordmark removal; zero-fork vs
WordPress core edits).

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC: First-class white-labeling for the EmDash admin & login (completing #639) #1493

Uh oh!

{{title}}

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

RFC: First-class white-labeling for the EmDash admin & login (completing #639) #1493

Uh oh!

marcusbellamyshaw-cell Jun 15, 2026

Screenshots — the same login screen, branding off vs on

1. Motivation

2. Current state (verified against main)

2.1 What already exists (from #639 / #705)

2.2 What's broken or missing

3. Goals & non-goals

4. Proposed design (tiered, additive)

Step 0 — Fix the pre-auth logo (bug fix; ships first, own lane)

Tier 1 — Server-inject branding (synchronous, pre-auth) + finish the wiring

Tier 1b — Declarative login customization (feature)

Tier 2 — Component override / slot system (the escape hatch; login-first)

Tier 3 — Design tokens + theme + head injection (visual rebrand, no JS)

4.5 Precedent (each tier is conventional)

5. Example usage

6. Default login UX improvements (responds to #1132)

7. Cross-cutting concerns (merge-readiness)

8. Rollout (small, reviewable PRs)

9. Why this approach

Replies: 0 comments

marcusbellamyshaw-cell
Jun 15, 2026

2. Current state (verified against `main`)