This SOP governs the path from an empty DevKinsta install to a fully configured, cloneable Kadence master template — the base that template-medical, template-alt-health, and template-nonprofit-church all branch from.
Two different things share the phrase “starter template” — don’t conflate them. HWD-SOP-KADENCE Section 08 covers using Kadence’s own built-in starter template library as scaffolding on an individual client build. This SOP covers building our own master template from scratch on DevKinsta, which then gets cloned per niche. Same words, unrelated processes.
1
Install DevKinsta + Docker
DevKinsta runs on Docker. Install Docker Desktop first, then DevKinsta. This matches Kinsta’s production stack exactly (Nginx + MariaDB), so what works locally works on staging with no surprises.
New WordPress site in DevKinsta — name it something unambiguous, e.g. hwd-starter-base. This one site becomes the master; the three niche templates are clones of it, not separate builds from scratch.
PHP 8.2 minimum, matching the Kinsta production requirement. Set this in DevKinsta’s site settings before installing any plugins.
Settings → Permalinks → Post name. Do this before creating any page. Changing permalink structure after pages exist breaks internal links — expensive to fix later, free to get right now.
Single source of truth: plugin-inventory.html The full plugin list, install order, licensing, and “do not install” table already live there and are kept current — this SOP does not duplicate them. What follows is specific to the starter template base only.
✓
Install on the base — every clone inherits these
- Kadence Theme Pro + Kadence Blocks Pro — activate first, per plugin-inventory.html’s install order
- RankMath SEO (free tier), Fluent Forms, Perfmatters, Wordfence
- Kadence Cloud — syncs saved global styles/patterns from this base into each niche clone without rebuilding settings by hand
−
Leave dormant on the base
Shop Kit — none of the three niches run WooCommerce as standard scope. Leave deactivated on the base; only activate it on the rare individual client site that actually needs e-commerce, not on any master template.
+
Add after cloning, not on the base
Niche-specific plugins get layered on after a template is cloned from the base — never baked into the shared starting point. Examples: GiveWP + Stripe and an events/sermon plugin for template-nonprofit-church. See Section 06 for what’s still undecided there.
These are the settings the three niche templates share by default. A clone changes its header CTA and adds niche-specific sections (Section 05) — it should not need to touch colors, type, buttons, or spacing.
| Setting | Value |
|---|
| Primary color | Navy #0f2354 |
| Background | Off-white #f4f6fb |
| Headings | Lora, bold, letter-spacing −0.02em |
| Body | Raleway, 15px, weight 400, line-height 1.65 — never below 16px for medical/nonprofit clients |
| Primary button | Navy bg, white text, 10px radius, 13px/28px padding, hover opacity 88% |
| Container width | 1200–1280px |
| Section padding | 96px/80px desktop → 48px/24px mobile |
| Header | 68px, sticky, transparent-to-white on scroll, text logo (Lora 17px bold) until brand photography exists |
| Footer | Navy bg, three-zone layout: brand · “Norfolk, Virginia · Serving Hampton Roads” · Privacy/Terms/email |
This table describes the public charleshardt.com site’s Kadence Customizer settings — not this ops-hub document’s own styling. The public site (and its Kadence build) still specifies Raleway per the Kadence Build Reference; the ops hub you’re reading this in runs on assets/design-system.css (Inter, 16px root). Don’t conflate the two typography systems when building.
Header CTA is the one thing that changes per clone. Medical → click-to-call + booking CTA. Nonprofit/church → donate button + service times. Set the universal header structure on the base, but expect to swap this one element immediately after cloning.
→
Build locally, push to staging
All development happens in DevKinsta first. Once the base (or a niche clone) is in a working state, push local → Kinsta staging. This is the primary and default direction for every build.
←
Pull — rare edge cases only
Pulling from Kinsta staging back to local is reserved for edge cases — e.g. reconciling a change made directly on staging that wasn’t made locally first. It is not part of the normal workflow and should not become a habit.
- Confirm PHP 8.2+ on the Kinsta site
- Confirm SSL is enforced
- Staging environment enabled — all development-facing work happens on staging, never directly on live
- “Discourage search engines from indexing this site” is checked while on staging — flip off only at actual launch
1
Duplicate the base site in DevKinsta
Use DevKinsta’s site duplication feature to clone hwd-starter-base three times, renaming each to its niche: template-medical, template-alt-health, template-nonprofit-church.
Medical/alt-health → click-to-call + booking. Nonprofit/church → donate button + service times. This is the one global-settings element that changes per clone (Section 03).
3
Layer in niche-specific plugins
Add what Section 02 deferred — e.g. GiveWP + Stripe and an events/sermon plugin for the nonprofit/church clone. Do not add these to the base; keep the base plugin-lean so future clones stay universal.
MedicalOrganization schema for the medical clone; general LocalBusiness or the appropriate nonprofit schema elsewhere. Configured through RankMath per HWD-SOP-KADENCE.
5
Hand off to HWD-SOP-KADENCE for page assembly
Once a clone has its CTA, plugins, and schema set, page-level design and build work follows the general Kadence Design Implementation methodology — extract design tokens, build components, assemble pages, QA.
Leading candidate: CP Live (YouTube/Resi only) paired with CP Sermons (YouTube/Facebook/Vimeo/SermonAudio) — but there’s a Facebook live-detection gap. WP Livestream or EmbedVidio may be needed as a supplement depending on the church’s streaming platform. Instagram live isn’t supported by any current tool option — a platform limitation, not a plugin gap.
Leading candidates: PDF Embedder (free, no iframe, leanest) or PDF Poster (free, adds fullscreen/download/print buttons). EmbedPress was rejected as too heavy for this use case. Leaning toward a single static URL such as /bulletin with a weekly file swap for volunteer ease — not yet tested.
Don’t clone nonprofit/church until both are settled. Cloning before these are resolved means retrofitting a plugin decision into a live template later, instead of baking it in cleanly at clone time.
- All plugins match the current plugin-inventory.html list — no stale or extra plugins on the base
- Shop Kit is installed but deactivated — not removed, not active
- Kadence Cloud sync is confirmed working
- Global colors, typography, buttons, and spacing match Section 03 exactly
- Header and footer builders configured and tested at all three breakpoints
- Permalinks set to Post name — confirmed before any page existed
- PHP 8.2+, SSL enforced, staging enabled on the corresponding Kinsta site
- “Discourage search engines from indexing” is checked
- No client-specific content, form fields, or schema present — the base stays generic
- Base pushes cleanly to a Kinsta staging site with no errors
Only after this checklist passes: move to Section 05 and duplicate the base into the three niche templates.