Practice: Extend a CMS site

Course: Level 2 · Web Construction
Module: CMS development
Required-path effort: 480–720 minutes
Submission: Show the restored final CMS site, evidence files, local exports, and private GitHub repository to your teacher
Assignment type: Individual CMS capstone

Estimate assumptions: This provisional estimate covers the required path, including project and repository setup, baseline restoration, a CMS brief, block-theme customization, one shared template-part change, extension research and approval, installation and configuration, visitor, keyboard, request, deactivation, narrow-width, and zoom tests, focused repairs, Git checkpoints, two exports, final restoration proof, documentation, a walkthrough, support use, debugging, and re-entry. It assumes that you completed the Level 1 CMS project and both Level 2 CMS lessons, or that your teacher supplied an equivalent restorable site. Optional extensions are not included. Optional extensions are not included.

Outcome

Complete a separate CMS capstone from a restorable WordPress site. Define the product need, apply a consistent block-theme system, integrate one focused capability, test the combined visitor result and removal boundary, and prove that the final ZIP restores in a new WordPress Playground.

This capstone is separate from the source-code task board. A CMS stores important state in its files and database, so its evidence, export, and recovery route need their own project boundary.

What you will practice

Distinguish page content, global theme presentation, shared template structure, and plugin functionality.
Select a CMS extension from a defined need and record evidence before installation.
Test visitor behavior, accessibility, requests, deactivation, and restoration as parts of one integration contract.
Document a CMS result with reviewable text evidence and recoverable exports.

Why this project matters

A CMS can make a change easy to apply across many pages, but that scope increases the cost of an unclear decision. A theme change can affect every route. A plugin can add markup, assets, requests, stored settings, and an ongoing update dependency. This capstone makes those boundaries visible before the site is treated as complete.

What is new and what is reused

New: You will combine theme and extension work in one independent product, maintain a decision and test record, rehearse deactivation, and restore the complete final result.
Reused: The Level 1 content structure and search information, WordPress Playground, block themes, global Styles, template parts, plugin evaluation, visitor testing, Network inspection, ZIP export and import, and the solo Git workflow for text evidence.
Kept separate: The task-board repository, its source files, and its later analytics training data do not enter this CMS project.

Starting point

Before you start

Use the verified final ZIP from the Level 1 CMS assignment, or use an equivalent teacher-supplied five-page block-theme site.
Complete the Level 2 theme-customization and extended-functionality lessons.
Use WordPress Playground in a current browser, VS Code for evidence files, Git, and a private GitHub repository.
Use fictional public content. Do not add real visitor, student, staff, account, or contact data.

Current state: You have lesson copies that demonstrate theme and plugin workflows, but you do not yet have one independent CMS capstone with a stable brief, separate evidence repository, verified deactivation route, and restored final export.
First action: Create a folder named level-2-cms-capstone and add README.md, cms-brief.md, theme-decisions.md, extension-evaluation.md, cms-test-report.md, and .gitignore.
First checkpoint: The evidence repository is private, the supplied CMS ZIP restores into a new Playground, and a separately named baseline export can restore the unchanged starting state.
Help trigger: Stop and use assistance or ask for help when the supplied ZIP does not restore, the active theme is not a block theme, or the plugin need cannot be stated without naming a product.

Requirements

The required assignment is complete when every applicable criterion below is met.

CMS product

The restored site keeps at least five purposeful public pages with working primary navigation and fictional content.
One page is a substantial guide or resource page with at least three meaningful second-level headings. It provides the required test surface for the added capability.
The home page identifies the site purpose and gives a clear route to the guide or resource page.
Every page has one descriptive main heading, a logical heading hierarchy, useful link text, and intentional search title and description information from Level 1.
The final visitor site contains no placeholder text, default sample content, broken public link, or unexplained draft route.

Theme customization

The site uses one identified block theme that exposes the Site Editor and global Styles.
Global Styles define a deliberate color system, body and heading typography, and content-layout width or spacing behavior.
One block type used on several routes has a documented global style that supports its role.
One shared Header or Footer template part changes in a way that supports the product brief and appears on every route that uses that part.
The design provides readable contrast, visible keyboard focus, content wrapping, and a usable visitor result at narrow and wide widths and 200% browser zoom.
theme-decisions.md identifies each decision, its scope, the affected routes, and the visitor evidence that confirms it.

Extended functionality

cms-brief.md defines one visitor or editor need before extension research begins.
One teacher-approved plugin from the official WordPress Plugin Directory adds the focused capability. The required route does not use a paid plan, external account, embedded third-party service, or visitor-data collection.
extension-evaluation.md records the plugin name, author, directory URL, stated purpose, current compatibility evidence, update and support evidence, permissions or data behavior, external-resource evidence, alternatives, and selection reason.
The configured capability solves the defined need on the guide or resource page without replacing its semantic heading structure or normal link behavior.
The visitor result works with keyboard input, direct links where applicable, narrow and wide widths, and 200% browser zoom.
A separate deactivation test records what remains, what disappears, what editor state changes, and how the site returns to the active final state.

Evidence and recovery

Keep a restorable baseline ZIP and final ZIP in a local exports folder that Git ignores.
The private repository contains the brief, theme decisions, extension evaluation, test report, README, and ignore rules. It does not contain ZIP exports, credentials, personal data, or unrelated course work.
cms-test-report.md identifies the WordPress version, PHP version, active theme, active plugin, browser, test conditions, results, repairs, limits, and verified final export filename.
A fresh Playground imports the final ZIP and reproduces the active theme, shared template part, content, navigation, plugin, configuration, and tested visitor result.
Focused Git commits record planning, theme, extension, testing, and final delivery evidence. The final commit exists on the private remote and the working tree is clean.

Design freedom

Choose one brief below, the site name, fictional content, visual direction, active block theme, global style values, shared template-part change, and focused capability.
Choose the exact page structure and block composition while preserving the required five-page information architecture and guide-page test surface.
Choose an official-directory plugin after the evidence matrix supports it and your teacher approves it.

Out of scope

A custom PHP theme, custom plugin, child theme, code injection, production server, domain, public launch, migration, and live maintenance schedule are not required.
E-commerce, payments, user accounts, comments, public forms, membership, advertising, tracking, analytics, and external-service embeds are outside the required project.
Do not install several plugins to compare them inside the same project copy. Evaluate alternatives in text and keep one approved active extension.
The local Git repository does not replace ZIP export and restore proof. The ZIP export does not replace reviewable text evidence.

Definition of done

The CMS capstone is complete when one named final ZIP restores into a fresh Playground and the restored site passes the required visitor, keyboard, responsive, request, deactivation-recovery, and content checks. The evidence files must identify the restored result, one final Git commit, known limits, and the exact export filename. Optional extensions do not change this finish line.

Choose one CMS brief

Each route requires five public pages and one substantial guide page. Keep the user need narrow enough to test in one local CMS.

Brief A: Public service guide

Create a fictional guide to one public process, such as preparing for a community repair event. Suggested pages: Home, Start here, Step-by-step guide, Resources, and Contact information. The contact page must use fictional organizational details and must not contain a form.

Brief B: Creative studio resource hub

Create a fictional studio site that explains services and publishes one client-preparation guide. Suggested pages: Home, Services, Work, Prepare your project, and Studio. Do not use real client names, testimonials, or contact details.

Brief C: Community program information site

Create a fictional site for a short public program. Suggested pages: Home, Program, Participation guide, Accessibility, and About. Do not collect registrations or publish real participant information.

Write the selected brief in cms-brief.md with this bounded contract:

# CMS capstone brief

## Product

- Site name:
- Brief:
- Intended visitor:
- Visitor outcome:

## Page inventory

| Page | Purpose | Primary visitor action | Main heading |
| --- | --- | --- | --- |

## Theme need

- Global visual problem to solve:
- Shared template-part problem to solve:

## Extension need

- User who has the need:
- Current barrier:
- Required capability:
- Evidence that will show the need is met:

## Boundaries

- Fictional content rule:
- Data and external-service exclusions:
- Work reserved for Later:

Name the capability without naming a plugin. For example: A visitor needs an in-page list of the guide’s second-level headings so they can move to a named section and copy a direct section link.

The plugin is a candidate solution. It is not the need.

Checkpoint 1: Restore and preserve the baseline

Create this local evidence structure:

level-2-cms-capstone/
├── .gitignore
├── README.md
├── cms-brief.md
├── theme-decisions.md
├── extension-evaluation.md
├── cms-test-report.md
└── exports/
    ├── cms-capstone-baseline.zip
    └── cms-capstone-final.zip

Add these ignore rules before a ZIP enters the folder:

exports/
*.zip

Initialize the evidence repository, create a private GitHub repository named level-2-cms-capstone, connect the remote, and push the initial brief and empty evidence headings. Confirm Git does not list either ZIP.

In WordPress Playground:

Open New Playground and choose Import zip.
Import the verified Level 1 final ZIP or teacher-supplied equivalent.
Record the WordPress version, PHP version, active theme, page count, and active plugins.
Visit all five public routes and test the primary navigation.
Remove leftover lesson-only content or restore the source ZIP again if the starting state is not the intended site.
Export the unchanged restored state as cms-capstone-baseline.zip.
Import that baseline ZIP into another new Playground and confirm the same routes, theme, and content return.

Do not rely on a copied Playground setup link as the backup. A setup link can recreate the initial setup but does not prove that later database and file changes are present. The required ZIP contains the current site state.

Check

Confirm all of these facts before theme work:

the chosen five-page brief is written;
the current visitor routes work;
the active theme is a block theme and Appearance → Editor is available;
the baseline ZIP restores;
the exports folder is ignored;
the private remote contains the evidence baseline commit;
no real or sensitive data exists in the site or evidence.

Assistance for Checkpoint 1

Assistance 1 — Identify the three project boundaries

The Playground contains the working CMS. The ignored exports folder contains portable recovery points. The Git repository contains readable plans and evidence. Confirm which boundary owns the file you are about to change.

Assistance 2 — Diagnose a ZIP that restores the wrong state

Compare the export filename, modification time, source Playground, active theme, page count, and plugin list. Import into a new Playground instead of reopening a recent autosave. Record the first mismatch before exporting again.

Assistance 3 — Build the baseline in a stable order

Create ignore rules and evidence files; initialize and push the private repository; import the source ZIP; inventory the site; verify five routes; export the baseline; restore the baseline; record the result. Do not customize the theme until the restored inventory matches the brief.

Checkpoint: The CMS baseline is recoverable

What now works: A separate Playground restores the five-page starting site, the private repository contains the approved brief and inventory, and Git ignores the baseline export.
Files changed: .gitignore, README.md, cms-brief.md, cms-test-report.md
What remains: Apply a global visual system and one shared template-part change with explicit scope.
Next action: Open theme-decisions.md and record the current theme, global style baseline, and first site-wide visual problem.
If it does not work: If the baseline is uncertain, stop and restore the last verified source ZIP in a new Playground before making CMS changes.

Record each CMS evidence checkpoint with Git

Commit the text evidence after the related CMS state passes. Push each checkpoint. The CMS itself remains recoverable through named ZIP exports, not binary Git history.

Define CMS capstone brief and baseline
Document block theme customization
Evaluate and integrate CMS capability
Record CMS visitor and recovery tests
Complete CMS capstone evidence

At every checkpoint, run git status, inspect the text diff, confirm that exports/ stays absent, commit, push, and leave the working tree clean.

Checkpoint 2: Apply the block-theme system

Open Appearance → Editor → Styles. Record the active theme and current site-wide values before changing them. Use the Site Editor save review to inspect which global records, template parts, or templates will change.

Create a coherent system with these four decisions:

Color: Define the main surface, text, link or action, border, and limited emphasis roles. Test normal text and controls for sufficient contrast.
Typography: Define body and heading choices with readable sizes and line height. Keep one stable role for each type treatment.
Layout: Set content width or spacing behavior that supports long guide text and does not create fixed-width overflow.
Repeated block: Customize one block type used on several routes, such as Buttons, Quotes, or Headings. Record why that repeated role needs a global rule.

Then edit one shared Header or Footer template part. The change must support the brief, such as clarifying site identity, navigation, or a persistent public-information note. Do not place page-specific copy in a shared template part.

In theme-decisions.md, use one row per decision:

| ID | Scope | Before | Decision | Affected routes | Visitor test | Result |
| --- | --- | --- | --- | --- | --- | --- |
| THEME-01 | Global color | ... | ... | All public routes | ... | ... |

Use IDs THEME-01 through THEME-05 for color, typography, layout, repeated block, and shared template part.

Check

Visit every public route outside the editor. At narrow and wide widths and 200% zoom, confirm:

the shared visual roles remain consistent;
the Header or Footer change appears only where its template part applies;
page-specific content remains on its page;
navigation wraps and remains keyboard operable;
text, controls, focus, and content remain visible;
no route gains horizontal page scrolling;
the save review contains no unrelated record.

Assistance for Checkpoint 2

Assistance 1 — Distinguish global, template, and page scope

Global Styles affect repeated site-wide presentation. A template part affects every template that includes it. Page content belongs to one page. State the intended scope before you select a block or save a record.

Assistance 2 — Trace a change that appears on only one route

Inspect whether the change was saved on one page block, in a block’s global Styles, or in a shared template part. Then inspect which template the failed route uses. Do not repeat a page-level change across routes to imitate a global rule.

Assistance 3 — Apply and test one theme decision at a time

Record the baseline; change one global role; save only its listed record; test all affected routes; write the result; commit the evidence. Continue to the next role only after the current scope matches the decision record.

Checkpoint: The theme system has deliberate scope

What now works: Global color, type, layout, and repeated-block roles remain consistent, and one shared template-part change supports the brief across every intended route.
Files changed: theme-decisions.md, cms-test-report.md, README.md
What remains: Select and integrate one focused CMS capability from documented evidence.
Next action: Open extension-evaluation.md and write the visitor or editor need from cms-brief.md before searching the Plugin Directory.
If it does not work: If an unintended route changes, inspect the saved record and active template before adding another override. Restore the baseline if the scope cannot be explained.

Checkpoint 3: Evaluate the extension before installation

Search the official WordPress Plugin Directory from the written capability. Record evidence for at least two candidate routes. One route can be a core-block or manual alternative rather than a second plugin.

For each plugin candidate, record:

official name, author, slug, and directory URL;
stated capability and what remains outside that claim;
compatibility information shown by the directory and your current WordPress version;
last update, active development, changelog, support, and review evidence;
required account, payment, external service, or networking behavior;
personal-data, telemetry, cookie, iframe, tracking-pixel, and external-script statements;
frontend assets or requests you expect to test;
saved-content or block dependency you expect after deactivation;
why the candidate is accepted, rejected, or needs more evidence.

Do not treat install count, rating, publisher claims, or directory presence as proof that the plugin works with this site. The project tests provide that evidence.

The required candidate must:

solve the written need;
work without a paid plan or external account;
avoid visitor-data collection and analytics;
avoid an embedded third-party service;
have a clear deactivation test;
receive teacher approval before installation.

If no candidate meets the boundary, keep the project at the last passing checkpoint and ask your teacher to approve another capability. Do not weaken the privacy or recovery requirements to keep the first plugin choice.

Check

Review extension-evaluation.md with your teacher. The selected solution must connect evidence to the original need and state at least one limit or uncertainty. Record the approval and date. Do not record credentials or private teacher information.

Assistance for Checkpoint 3

Assistance 1 — Return from a plugin name to the user need

Hide the candidate name and read the need statement. If the statement no longer identifies a user, barrier, capability, and passing evidence, rewrite it before comparing plugins.

Assistance 2 — Separate publisher evidence from project proof

Directory metadata can support identity, maintenance, compatibility claims, and documented behavior. It cannot prove this site’s keyboard behavior, markup, requests, theme fit, or deactivation result. Put those claims in the later test matrix.

Assistance 3 — Use a bounded extension matrix

Compare need fit, maintenance evidence, account and payment boundary, data and external-resource behavior, output, configuration scope, deactivation expectation, and test cost. Reject a route when one required boundary fails instead of averaging it against popularity.

Checkpoint: The extension has an evidence-based selection

What now works: The approved candidate solves the defined need, fits the data and service boundary, has an explicit test and removal contract, and has not yet changed the CMS.
Files changed: extension-evaluation.md, cms-brief.md
What remains: Install, configure, test, deactivate, restore, and retest the capability in the capstone site.
Next action: Export or confirm the current baseline recovery point, then install only the approved plugin in the active capstone Playground.
If it does not work: If the selection still depends on a vague benefit, return to the need and passing evidence rather than installing several candidates.

Checkpoint 4: Integrate and test the capability

Before installation, confirm that cms-capstone-baseline.zip still restores and that the current theme evidence commit is pushed. The baseline predates the extension and remains the rollback route.

Install only the approved plugin. Record the exact version installed and every setting changed. Apply the capability to the substantial guide or resource page. Keep the page’s semantic headings and ordinary links meaningful without the plugin enhancement.

Build the test matrix in cms-test-report.md:

ID	Condition	Required evidence
EXT-01	Plugin active, guide page loads	Capability appears once in the intended location
EXT-02	Keyboard route	Every generated control or link is reachable, visible, and operable in logical order
EXT-03	Direct target or equivalent path	The capability reaches the correct section or result and preserves a meaningful URL when applicable
EXT-04	Narrow visitor view	Content, controls, and generated output wrap without horizontal page scrolling
EXT-05	Wide visitor view	Capability aligns with the theme and does not obscure content
EXT-06	200% browser zoom	Text and controls reflow; focus remains visible
EXT-07	Network requests	No unexplained external domain, tracker, pixel, iframe, or remote asset appears
EXT-08	Other public routes	No duplicate output, broken route, or unintended global insertion appears
EXT-09	Plugin deactivated in a separate test copy	Remaining content and lost capability match the recorded dependency expectation
EXT-10	Plugin reactivated and configured	The active final behavior returns without stale or duplicated output

Use fictional content in every path. In the Network panel, inspect request domains and initiators after a fresh load. A request to an unexpected domain is a stop condition until you can explain and approve it.

Perform deactivation in a separate Playground restored from the latest working export or in a duplicate test copy. Do not make the only active project copy your first removal experiment. Record:

visitor output that remains;
visitor output that disappears;
editor warnings or unavailable blocks;
saved settings or content that remain;
requests that stop;
exact reactivation and configuration recovery steps.

Return the working capstone to the approved active configuration and repeat EXT-01, EXT-02, EXT-07, and EXT-10.

Assistance for Checkpoint 4

Assistance 2 — Trace a capability that is active but absent

Confirm the plugin is active, the required block or setting is present on the intended page, the page is saved, the visitor route is current, and the page content meets the plugin’s documented input conditions. Inspect one condition at a time.

Assistance 3 — Test integration layers in a stable order

Verify active output; keyboard and direct-target behavior; narrow, wide, and zoom presentation; request boundary; unaffected routes; separate-copy deactivation; reactivation; focused retest. Repair one reproducible failure before continuing to a later row.

Checkpoint: The capability has an active and removal contract

What now works: The approved extension solves the need in the active site, the visitor and request tests pass, and a separate deactivation test records the exact dependency and recovery route.
Files changed: extension-evaluation.md, cms-test-report.md, README.md
What remains: Run the integrated site regression, export the final state, restore it in a fresh Playground, and prepare the walkthrough.
Next action: Visit the home page and execute the complete five-route visitor test before creating the final ZIP.
If it does not work: If deactivation changes content unexpectedly, stop editing that copy, preserve the evidence, and reactivate or restore the last working export before retesting.

Checkpoint 5: Restore the complete capstone

Run one final integrated matrix against the active site:

ID	Area	Required result
SITE-01	Five public routes	Each route loads, has one clear purpose and main heading, and contains no draft or placeholder content
SITE-02	Primary navigation	Every route is reachable, current location is understandable, and keyboard operation works
SITE-03	Theme system	Global roles and shared template part appear on every intended route with no page-specific leakage
SITE-04	Responsive visitor result	Narrow, wide, long-content, and 200% zoom paths pass without lost content or page overflow
SITE-05	Search information	Each route keeps a descriptive title and description aligned with its visible content
SITE-06	Extension integration	EXT-01 through EXT-10 have final passing or explicitly bounded results
SITE-07	Browser evidence	Console and Network panels contain no unexplained error or external request on the tested routes
SITE-08	Data boundary	Site, uploads, evidence, and planned export contain only fictional public content and approved assets

Repair a confirmed failure, retest its focused row, then rerun every affected integrated row.

Export the active result as cms-capstone-final.zip. Keep the baseline unchanged. In a fresh Playground:

choose New Playground → Import zip;
import cms-capstone-final.zip;
record the restored WordPress and PHP versions;
confirm the active theme and plugin;
test all five public routes;
rerun SITE-02, SITE-03, SITE-06, SITE-07, and SITE-08;
record Restore Pass only when the imported copy produces the intended active result.

If the restored result differs, keep the row failed, return to the working source Playground, identify whether save or export order caused the mismatch, create a newly named final ZIP, and repeat the fresh import. Do not overwrite evidence of an unverified export and call it final.

Prepare the capstone walkthrough

Prepare a five-to-seven-minute route:

State the visitor, site purpose, and five-page structure.
Show one global style decision and its scope.
Show the shared template-part decision on two routes.
State the extension need, selection evidence, and one rejected alternative.
Demonstrate the capability with the keyboard at one narrow width.
Explain the deactivation result and external-request boundary.
Open the fresh restored copy and identify the final export and Git commit.
State one known limit without presenting optional work as missing required work.

Keep the baseline ZIP available as a fallback. The walkthrough demonstrates a verified product; it does not require slides.

Assistance for Checkpoint 5

Assistance 2 — Diagnose a restored result that differs from the working site

Compare the source and restored copy by final ZIP filename, export time, active theme, active plugin, plugin settings, page modification time, and visitor output. Find the first mismatch before changing the restored copy.

Assistance 3 — Close the capstone through one evidence chain

Finish the source-site matrix; export with a unique final filename; import into a new Playground; rerun the required restored rows; update report and README; commit and push text evidence; rehearse the walkthrough from the restored copy.

Checkpoint: The CMS capstone restores and presents

What now works: A fresh Playground reproduces the five-page theme and extension result, the full evidence chain identifies the export and commit, and the walkthrough fits the required route.
Files changed: README.md, cms-brief.md, theme-decisions.md, extension-evaluation.md, cms-test-report.md
What remains: Complete the self-check, push the final evidence commit, and keep both local exports available for review.
Next action: Run git status, inspect the final text diff, record the commit ID after committing, and confirm the remote and local states agree.
If it does not work: If any restored row fails, do not finalize the evidence commit; produce and verify a newly named export first.

Final evidence and Git state

Complete README.md with:

product brief and five-route inventory;
WordPress, PHP, theme, and plugin identities;
the purpose of each evidence file;
baseline and final export filenames and where they are stored;
theme decision summary;
extension need, selected solution, data and external-request boundary, and deactivation result;
complete test and fresh-restore route;
final verified evidence commit;
known limits and rollback steps.

Commit only the reviewable evidence:

git status
git diff
git add .gitignore README.md cms-brief.md theme-decisions.md extension-evaluation.md cms-test-report.md
git diff --staged
git commit -m "Complete CMS extension capstone"
git push
git status

Confirm that neither ZIP appears in the staged diff or remote. Record the new commit ID in README through one final focused documentation commit if necessary.

Self-check

Complete these checks against the required result.

The final site contains at least five purposeful public pages, one substantial guide page, working primary navigation, and fictional content only.
The active block theme exposes the Site Editor, and the evidence identifies the exact active theme.
Global color, typography, layout, and repeated-block decisions have clear roles, affected routes, and visitor test evidence.
One shared Header or Footer template-part change appears on every intended route without page-specific content leakage.
The extension need was written before the plugin selection, and the selected plugin has teacher approval and official-directory evidence.
The selected capability works without a paid plan, external account, embedded service, visitor-data collection, or analytics.
The active capability passes keyboard, direct-target where applicable, narrow, wide, zoom, unaffected-route, and external-request checks.
A separate deactivation test records what remains, what disappears, and how the approved active configuration returns.
All five routes pass heading, link, focus, wrapping, 200% zoom, and horizontal-overflow checks.
The Console and Network evidence contains no unexplained error, tracker, pixel, iframe, or external request on the tested routes.
cms-capstone-baseline.zip still restores the pre-capstone recovery state and remains unchanged.
cms-capstone-final.zip imports into a fresh Playground and reproduces the final theme, content, navigation, plugin, configuration, and visitor result.
The evidence files identify test environments, actual results, focused repairs, limits, final ZIP filename, and restored result.
The five-to-seven-minute walkthrough demonstrates the brief, theme scope, extension reasoning, keyboard path, deactivation boundary, and restored final state.
The private repository contains reviewable text evidence but no ZIP, credentials, personal data, or unrelated work.
The final evidence commit exists on the private remote and git status reports a clean working tree.

Assessment

Area	Evidence
Product and content	Five purposeful routes, coherent information architecture, complete fictional content, and intentional search information
Theme system	Global roles, shared template scope, contrast, wrapping, keyboard focus, narrow and wide behavior, and recorded decisions
Extension judgment	Need-first selection, official evidence, bounded capability, service and data constraints, and rejected alternative
Integration quality	Active, keyboard, direct-target, responsive, request, unaffected-route, deactivation, and reactivation tests
Recovery	Separate baseline and final exports, fresh imports, exact filenames, restored inventory, and rollback instructions
Professional evidence	Focused Git history, readable reports, known limits, clear walkthrough, private remote, and clean final state

More plugins do not improve the result. The required capstone assesses one coherent theme system and one justified, tested, recoverable capability.

Assignment-wide assistance

Assistance 4 — Review a partial CMS evidence structure

Use this when the CMS changes exist but the evidence files do not yet show their relationships:

# README

## Product and routes
Link to `cms-brief.md` and name the five public routes.

## Environment and recovery
Name WordPress, PHP, the ignored baseline ZIP, and the ignored final ZIP.

## Theme
Link to `theme-decisions.md` and summarize global versus template-part scope.

## Extension
Link to `extension-evaluation.md`. State the need, selected plugin, data boundary, and deactivation result.

## Tests
Link to `cms-test-report.md`. Name the final restored result and known limits.

## Resume or rollback
Name the last passing state, next action, and baseline recovery route.

Complete the linked evidence in the same order as the project checkpoints. Do not reconstruct results from memory after the final export.

Assistance 5 — Review one complete reference evidence chainExample solution

This is a reference architecture, not a finished CMS solution. Replace every placeholder with evidence from your product.

Evidence	Reference result
Need	Visitors need to move to and directly link to one named section in a long guide
Content baseline	Five linked pages; guide has one H1 and four H2 sections
Theme scope	Global palette, type, content width, Button block style; shared Header identity and navigation
Selected route	One approved official-directory table-of-contents block plugin
Data boundary	No account, visitor input, analytics, iframe, tracker, or unexplained external request
Active result	Generated in-page links reach unique heading targets with keyboard and direct URL use
Deactivated result	Generated navigation disappears; semantic headings and normal page content remain; saved plugin-block dependency is recorded
Recovery	Reactivation and saved configuration restore the active visitor result
Baseline export	`cms-capstone-baseline.zip` restores the pre-theme, pre-plugin state
Final export	`cms-capstone-final.zip` restores the active theme, content, plugin, settings, and visitor behavior
Git evidence	Text-only brief, decisions, evaluation, report, and README identify one final commit

A valid project can use another approved capability. Keep the same chain: need → evidence → selection → active test → deactivation test → recovery → final restore.

Optional CMS capstone extensions

Complete and preserve the required final ZIP and evidence commit before starting an extension. Use a separate Playground copy for work that can change the verified result.

Replace the plugin with a core-block route

Rebuild the same capability with core blocks or manual links in a separate copy. Compare authoring time, update behavior, visitor markup, requests, content dependency, deactivation behavior, and maintenance cost.

Create one justified custom template

Add one template only when a specific page type needs a different repeated structure. Document the difference, assigned page, fallback after removal, and affected routes. Keep the verified standard templates available.

Compare two current block themes

Restore the baseline twice and apply the same theme decisions to two block themes. Compare available global controls, generated markup, responsive behavior, migration cost, and maintenance evidence. Do not overwrite the required final export.

Add a second-browser visitor pass

Repeat the complete SITE and active EXT visitor rows in one second current browser. Keep results separate and investigate only the paths that differ.

Prepare a later findability and measurement handoff

After you complete the Quality, SEO, and analytics lessons, create a separate plan that identifies public-origin requirements, crawl evidence, one useful measurement question, consent and data boundaries, and an approved integration route. Do not add analytics to the required CMS capstone or use real visitor data.

Optional official references

WordPress Site Editor documentation explains global Styles, templates, template parts, save review, and export tools.
WordPress Styles overview explains site-wide color, typography, layout, and block-style scope.
WordPress block themes documentation distinguishes block-theme Site Editor capabilities from classic-theme workflows.
WordPress Playground web instance guide explains current Dock tools, complete ZIP export, and ZIP import into a new Playground.
WordPress Plugin Handbook privacy guidance lists questions about personal data, telemetry, third-party scripts, pixels, iframes, cookies, and external services.
WordPress Plugin Directory guidelines describe current directory rules for services, tracking, disclosure, and user consent.

Safe stopping point and re-entry

Stop after a passing checkpoint, export when the CMS state has materially changed, and commit the matching text evidence. Add this note to README.md before a longer interruption:

## Resume here

- Working Playground identity:
- What works:
- Active theme and plugin:
- Last verified export:
- Last evidence commit:
- First failing or unfinished test ID:
- Exact next action:
- Dashboard or visitor route to open:

Keep both required exports until the teacher confirms the capstone review is complete. They contain the recovery history that Git does not store.