Custom Theme Notes

Notes gathered from working with the Kadence theme, to inform building a lightweight
replacement. Goal: semantic HTML, minimal CSS, no JS framework, fast on slow connections.

Build Plan

Trigger: Wait until Serge has populated most of his real content — migrate once,
not twice. Aim to start roughly 1–2 months after the site goes live.

Estimated work: ~5 days

  1. Theme scaffold + nav + typography (~2 days)
  • Classic (non-block) theme: style.css, functions.php, header.php, footer.php,
    page.php, single.php, 404.php
  • Responsive nav in pure CSS (no JS for the breakpoint decision)
  • Port the established fonts (Raleway body, Playfair Display headings) and colour palette
  1. Home page template (~1 day)
  • Drop the Kadence tabs — replace with plain scrolling sections (simpler, more
    accessible, works without JS)
  • Hero with min-height: 55svh and background-size: cover
  1. Content migration (~1–2 days)
  • Replace Kadence blocks with core blocks or static template parts on ~10 pages
  • Booking page stays as [serazi_booking] shortcode — no change needed
  • Contact form stays as plugin shortcode — no change needed
  1. Testing + fixes (~1 day)
  • Cross-browser, mobile, zoom levels
  • Check booking and contact form flows end to end

Performance Targets

WordPress will never match a fully static site, but the gap can be kept small:

  • Eliminate Kadence and all its block assets — the theme currently loads Google Fonts,
    Kadence block CSS/JS, and Splide (a carousel library) on every page. A custom theme
    loads only what it needs.
  • Self-host the two Google Fonts — one extra HTTP request and potential GDPR issue
    avoided; fonts load from the same server, no DNS lookup.
  • No jQuery if avoidable — WordPress loads it by default; dequeue it if no plugin
    needs it (check after plugin audit).
  • Audit and remove unused plugins — Easy Appointments, Kadence Starter Templates,
    Web Stories are already flagged for removal. Fewer plugins = fewer assets.
  • Images: WebP already in use (good). Add loading="lazy" to below-fold images.
    Consider width/height attributes to prevent layout shift (CLS).
  • Add WP Super Cache once content is stable — simple file-based page cache;
    cached pages are served as static HTML, almost as fast as a static site for visitors.
  • Target: sub-second TTFB on a good Irish connection; Lighthouse performance ≥ 85.

Hero / Banner Sections

  • Always set background-size: cover and background-position: center center from the
    start — there is no sensible reason to use auto for a full-width image.
  • Use viewport units for height, not fixed pixels:
    min-height: 55svh adapts to any screen without needing breakpoint overrides.
    (svh = small viewport height, avoids mobile browser chrome overlap issues.)

Navigation Breakpoints

  • Kadence controls the mobile nav collapse point via JavaScript (a PHP value passed to JS),
    not purely CSS. This means it cannot be overridden with a simple media query.
  • In the custom theme, the hamburger toggle should be driven entirely by a CSS media query
    so there is one value in one place. No JS involvement in deciding the breakpoint.
  • A breakpoint of around 1100px works well for this site’s menu (6 items); tune per content.

Responsive Layout

  • Kadence stores pixel heights in block JSON attributes, leading to values that need manual
    fixing per breakpoint. Use CSS custom properties or viewport units instead.
  • svh/dvh units are now well-supported and are the right tool for “fill the screen”
    sections. dvh adjusts dynamically as mobile browser chrome appears/disappears.

Tablet/Device-Specific Background Overrides

  • Kadence rowlayout supports a separate tabletBackground image that fires via a media
    query targeting iPads (1024–1366px, 2× DPR, hover: none). If that image goes missing
    (404) the background simply disappears with no visible error — hard to diagnose.
  • In a custom theme, avoid device-specific background images entirely. One cover image
    that crops well is simpler and less fragile.

General

  • Separate desktop and tablet background images (as Kadence does) adds complexity.
    A single cover image that crops gracefully is simpler and usually sufficient.
  • Block themes introduce a lot of JSON-driven configuration that is hard to inspect or
    override via SSH. A classic (non-block) theme with hand-written templates will be
    far easier to maintain and audit.