# leaguelaw — brief

**What:** A full rebuild of the League & Williams law firm website
(`https://www.leaguelaw.com`) on current WordPress, with a modernized take on the
existing design and a pattern-based build system behind it.

**Why:** The site is over a decade old. The theme framework has had no major
update in six years and throws PHP compatibility warnings, the homepage loads
roughly 50 script files, and a decade of plugins has accumulated. More urgently,
the firm's structured data still points at their **old office address** (they
moved in mid-2026), describes them only as a "personal injury attorney in
Victoria" despite four practice areas and six cities, and gives no author credit
for **427 articles published since 2014** — so their single biggest content asset
earns them nothing in AI search.

**Who:** League & Williams (Victoria BC, six locations). Client contact **Darren
Williams**, Principal. **Rob Cooper** owns the client relationship; **Rian** owns
delivery; **Adi** is building. Internal team on the thread: Janice Williams, Rob
Graham, Natasha Gordon.

**Status:** **Sold and accepted — Option 2, Design Modernization.** Client is
aiming for a **November 2026 launch** and we can start whenever ready. New office
and staff photography happens **in November**, so early design work uses labelled
placeholders. The AI add-on is **not yet confirmed with the client**, but its
delivery method is settled: it is `bw-ai-schema-pro` configured, not anything
custom built (see *Stack*).

## Where everything is
| Role | Lives in |
|---|---|
| Build plan, phases, gates | `.logs/planning/build-plan.md` |
| Session handoff (what next) | `.logs/handoff.md` |
| Project constitution / rules | `agents.md` |
| The signed proposal + client emails | `notes/` |
| Adi's manual designer/dev notes | `adi-note.md` |
| The repeatable prototyping process | `prototype.md` |
| Substrate friction worth reporting | `.logs/v8-feedback.md` |

## Stack

WordPress with the Gutenberg block editor on the **Kadence** premium theme
framework, built as an **unsynced pattern library**. Standards dispatch:
`/srv/projects/standards/README.md` → `coding.md` → `wordpress.md` →
`frontend.md`.

**The build philosophy, in one line:** assemble pages from a small set of
reusable pattern blocks whose variables can be changed in the editor, rather than
building bespoke layouts per page.

This is a deliberate carry-over from the Brentwood build, where unsynced patterns
plus properly declared editable blocks proved to be the thing that made a large
site fast to build and genuinely handable to a client. Two hard-won specifics
came out of that project and both apply here:

1. **Unsynced patterns inserted as unlocked starting points** — the client can
   change anything about an inserted section, rather than fighting content-only
   guard rails.
2. **Every block used inside a pattern must be explicitly declared editable**, or
   images, buttons, and tables go inert inside the pattern. A photo-led section
   whose photo could not be swapped was the sharpest edge of that discovery.

Detail and mechanics in `.logs/planning/build-plan.md` §Patterns.

### The build environment: keep this database, swap the theme

**Decided 2026-08-10.** `wp-content/` here is a **fresh pull of the live site**
(uploads re-synced 2026-08-09), and it is the thing we build *on*, not a
reference copy to leave alone. The live site at `www.leaguelaw.com` remains the
visual "before" reference, so no untouched local copy is needed.

**We keep the existing database and change the theme — we do not start a fresh
WordPress install.** That distinction is the whole point:

- **Passwords survive because the database survives.** WordPress password hashes
  are self-contained and do not depend on the site's salts, so keeping
  `wp_users`/`wp_usermeta` keeps every login working. A fresh install plus a
  content import would silently reset all of them.
- **The same is true of everything else worth keeping:** 3,929 Gravity Forms
  entries, all page and post IDs and slugs (which is what protects the URLs and
  rankings), ACF field data, the media library, and author attribution.

Then the content is **stripped back to plain blocks** — the design is rebuilt in
Kadence patterns, so the old presentation is deliberately discarded while every
page, post, entry, and user survives. See `.logs/planning/build-plan.md`
§Content conversion, which has the measured numbers: the content is in far
better shape than expected and the strip pass is small and targeted.

**All 424 posts are kept, drafts included** (272 published + 152 drafts) —
decided 2026-08-10.

**The target stack is Kadence + ACF + Yoast + Gravity Forms**, plus
`bw-ai-schema-pro` if the add-on lands. Everything else is removed. The full
keep/remove list, the ACF field-group decisions, and the one ordering hazard that
can orphan the lawyer post type are in `.logs/planning/build-plan.md`
§Stack cleanup — **read that before removing anything.**

### The AI add-on is a plugin to configure, not a thing to build

If the client takes it, it is delivered with **`bw-ai-schema-pro`** from the BW
plugin library. No custom schema code. The only prerequisite is a **team post
type** mapped in the plugin's settings — and a `staff` CPT with 13 entries
already exists here, so this is a mapping exercise rather than a build.

The plugin also ships a **team survey workflow** that collects credentials and
areas of expertise from team members and publishes them into the Person schema
fields it renders — which is exactly the "we research and apply baseline
information for your team, you review and finalize" deliverable in the proposal.
Read `docs/SPEC-team-survey.md` in the plugin before scoping that work.

## Scope (what was sold)

**Option 2 — Design Modernization.** Explicitly *not* a redesign. The site keeps
its layout logic, brand conventions, and orange highlights; presentation comes up
to current standards in typography, spacing, imagery, and modern-screen feel.
Mockups of the home page plus key pages go to the client for sign-off **before**
the rebuild starts. One comprehensive round of design feedback.

Also included, per the proposal in `notes/`:

- Full content migration: 427 posts (back to 2014), 47 pages, staff and
  testimonial post types, 1,400+ media files
- All six location pages (Victoria, Vancouver, Kelowna, Nanaimo, Duncan,
  Campbell River)
- Contact and intake forms rebuilt on current tooling
- Baseline SEO / AI crawlability, **including the corrected firm schema with the
  new address** — this one is a genuine live-site defect and is in the base scope
- Performance pass with before/after Core Web Vitals
- Security cleanup: small, current, supported plugin set
- Redirect map so existing rankings carry over
- Launch on the client's existing Flywheel hosting, training session, 30 days
  post-launch support

## Not doing

- **The AI Search Optimization add-on is not yet confirmed with the client**, so
  do not start configuring it until Rian says the client has accepted. When it
  lands it is `bw-ai-schema-pro` configuration, not custom development. The
  base-scope schema fix (correct address, correct practice areas) is separate and
  *is* in scope regardless.
- **No custom schema code.** If a task starts to look like hand-writing JSON-LD,
  stop — that is what the plugin is for.
- **Not a redesign.** If a proposal or mockup starts reading as "new brand,"
  it has drifted from what was sold.
- **No copywriting.** Content migrates; the client writes anything new.
- **No hosting migration.** Flywheel stays.
- **No final photography.** Placeholders until November.

## Known gaps

- **The client has not yet accepted the AI add-on.** Rian is following up.
- **The `Lawyer Settings` options page** holds one field, `lawyer_header_image`.
  Recommend dropping it with the other settings groups; Rian has not confirmed.
- **Four plugins need a decision, not a straight delete** — `redirection` (holds
  the existing redirect map), `wp-mail-smtp` (form notification delivery),
  `metronet-profile-picture` (author avatars), and the security/SSL trio. See
  `.logs/planning/build-plan.md` §Stack cleanup.
- **Team roster is unconfirmed.** 13 staff entries exist including a placeholder
  called "IS IT YOU?"; Natasha Gordon is on the client email thread but has no
  staff entry. Additions and departures need confirming before bios are built,
  and before any team-survey work if the add-on lands.
- **Author attribution is thin.** Published posts map to only 5 WordPress user IDs
  across 9 accounts, with a Molongui authorship layer and 2 `guest_author` entries
  on top. Untangling this is a prerequisite for per-lawyer authority schema.
- **No Core Web Vitals baseline captured yet.** Needed before changes, since the
  proposal promises a before/after.
- **43 items use ACF blocks and 32 contain shortcodes** — these are the custom
  layouts that the strip pass has to handle deliberately rather than blindly.