Customize a CMS theme

Course

Level 2 · Web Construction

Module

CMS development

Expected effort

180–300 minutes

Estimate assumptions: You completed the Level 1 CMS assignment and have its restorable final ZIP, or your teacher supplied an equivalent site. The estimate includes restoration, baseline evidence, global style decisions, one template-part change, visitor testing, documentation, export, restore verification, and re-entry after an interruption. Optional extension work is not included.

Outcome

You will customize the global visual system and shared header of a WordPress block theme, test the result as a visitor, and restore the completed site from a new ZIP export.

Why this matters

A CMS theme controls presentation and shared page structure across many content entries. A deliberate theme change can improve a complete site without editing every page. The same scope also creates risk: one poor global choice can reduce readability or break navigation across every route that uses it.

What you will practice

• Distinguish page content, global Styles, templates, template parts, and the original theme package.
• Create a restorable baseline before changing shared presentation.
• Use the Site Editor to change global colors, typography, layout, and one block type.
• Customize a shared header template part without changing page content.
• Review the Site Editor save list and identify the scope of each saved change.
• Test theme changes across routes, viewports, zoom, and keyboard navigation.
• Export and restore a complete CMS checkpoint that contains the saved customizations.

What is new and what is reused

• New: Block-theme customization, global Styles, style variations, element and block styles, template parts, shared-scope save review, style revisions, before-and-after evidence, and theme-specific restore verification.
• Reused: WordPress Playground, visitor and administration views, complete-site ZIP exports, page hierarchy, navigation, prepared media, semantic headings, contrast checks, responsive testing, documentation, and the solo Git workflow for text evidence.

Starting point

Before you start

• The unchanged cms-site-final.zip from the Level 1 CMS assignment, or a teacher-provided equivalent ZIP with several published pages and working navigation.
• A current version of Edge, Chrome, or Firefox with internet access.
• VS Code and permission to create a local cms-theme-practice folder.
• The active site uses a block theme, or you have permission to activate an installed block theme in the restored practice copy.

Current state

You have a restorable Level 1 CMS site, but you have not created a separate Level 2 practice copy, theme baseline, or customization record.

First action

Create cms-theme-practice, copy cms-site-final.zip into it without changing the original file, and rename the copy theme-source.zip.

First checkpoint

cms-theme-practice contains theme-source.zip, and the unchanged Level 1 final ZIP still exists in its original folder.

Help trigger

Use the recovery note or ask for help if the ZIP does not restore, Appearance does not include Editor, the Site Editor save list names an unexpected template, navigation changes on routes you did not inspect, or you cannot produce and restore a final ZIP.

Reference environment

This lesson uses WordPress Playground and a block theme. A block theme exposes the Site Editor for global Styles, templates, and template parts.

If your class uses another CMS, complete the equivalent work in a safe practice copy: preserve a baseline, customize site-wide design tokens, change one shared header component, review the save scope, test every affected route, document evidence, and create a restorable backup.

If Appearance → Editor is absent, stop before following the Site Editor steps. The active theme can be a classic theme, or your account can lack the required capability. Confirm the environment with your teacher. Do not switch the only copy of a working site to an arbitrary theme.

Keep three separate recovery states

Preserve theme-source.zip as the untouched source. Export theme-baseline.zip after the restored site passes its first checks. Export theme-customized-final.zip only after the changed visitor site passes. A later export must not replace either earlier file.

Required result

You have completed the lesson when:

• cms-theme-practice contains the untouched theme-source.zip, the verified theme-baseline.zip, the verified theme-customized-final.zip, and theme-customization-notes.md;
• the baseline site restores with its required pages, primary navigation, prepared media, and front-page setting;
• the active theme is a block theme and the Site Editor opens;
• global Styles define a deliberate background, text, link, heading, and button treatment with readable contrast;
• typography and content-width choices support readable text at wide and narrow viewports;
• the shared Header template part contains the site title, primary navigation, and a visible tagline or equivalent site-purpose text;
• page titles, page content, page hierarchy, and navigation destinations remain correct;
• the Site Editor save list contains only the intended Styles and Header-related changes;
• theme-customization-notes.md records exact decisions, scopes, route evidence, and known limits;
• visitor checks pass at a wide viewport, about 320px, and 200% zoom with keyboard navigation; and
• a new Playground restored from theme-customized-final.zip matches the tested result.

Create the local evidence folder

Use this local structure:

CMS theme practice files

cms-theme-practice/
├── .gitignore
├── theme-source.zip
└── theme-customization-notes.md

Add this rule to .gitignore before you initialize or reuse a private Git repository:

cms-theme-practice/.gitignore

*.zip

The ZIP files are complete CMS environments and can contain database state, users, configuration, plugins, and uploaded files. Keep them local and ignored. The notes file is the reviewable project evidence.

Add this starting structure to theme-customization-notes.md:

cms-theme-practice/theme-customization-notes.md

# CMS theme customization

## Baseline

- Active theme:
- Required routes checked:
- Navigation result:
- Baseline ZIP restore result:

## Design decisions

| Decision | Exact setting | Scope | Reason |
| --- | --- | --- | --- |
| Background and text | | Global | |
| Links | | Global element | |
| Headings | | Global element | |
| Buttons | | Global block type | |
| Content width | | Global layout | |
| Header | | Shared template part | |

## Visitor checks

| Route and condition | Expected result | Observed evidence | Pass or fix |
| --- | --- | --- | --- |

## Restore verification

- Final ZIP filename:
- Routes compared:
- First mismatch, or none:

## Known limits

- Playground is a local practice environment, not a public production deployment.

Do not place credentials, private contact details, or the ZIP contents in the notes.

Restore and verify the source site

Open a new WordPress Playground. In the Dock, use New → Import zip and select theme-source.zip. Wait for the restored site and administration tools to finish loading.

Check the source before you customize it:

1. Open the site root and every required Level 1 route in the visitor view.
2. Confirm that the primary navigation reaches each required page and that current-page states remain understandable.
3. Confirm that page titles, heading order, images, captions, and alternative text still exist.
4. Open Settings → Reading and confirm the expected static front page.
5. Open Appearance → Themes and record the exact active theme name.
6. Open Appearance → Editor and confirm that the Site Editor loads.

Record the route list and result under Baseline. If the restored site already fails a Level 1 requirement, fix or replace the source before you customize the theme. Do not record a broken baseline as a theme success.

Export the verified baseline

Use the Playground Dock Export → Download as .zip action. Store the new file as theme-baseline.zip in cms-theme-practice.

Open another new Playground and restore theme-baseline.zip. Compare at least the site root, one child route, primary navigation, active theme, and one image. Record the restore result.

Checkpoint: The theme work has a restorable baseline

What now works

theme-source.zip remains unchanged, theme-baseline.zip restores the verified content and active block theme, and the notes name the tested routes and result.

Files changed

cms-theme-practice/theme-source.zip, cms-theme-practice/theme-baseline.zip, cms-theme-practice/theme-customization-notes.md

What remains

Define the global visual system and customize the shared header in the working Playground.

Next action

Return to the working restored site, open Appearance → Editor → Styles, and inspect the current style variation without saving a change.

If it does not work

Keep both Playgrounds open, compare the first route that differs, and repair the source state before producing a newly named baseline export.

Map each CMS layer before editing

Use the Site Editor for shared presentation, not for page-specific text corrections.

Layer	Owns	Required example
Page content	Text, headings, images, and blocks unique to one page	The Work page description
Global Styles	Site-wide colors, typography, layout, and default block appearance	Default link color
Template	Structure used for a page type	Page title and content placement
Template part	Repeated structural region used by templates	Header with site title and navigation
Theme package	Original defaults, templates, assets, and configuration supplied by the theme	The active block theme files

Changes saved through the Site Editor override theme defaults for this site. This workflow does not edit the original theme package as a maintained source-code project.

Before each change, state its intended scope. If the intended statement begins with “on every page,” use a global Style, template, or template part. If it begins with one page name, open that page’s content editor.

Define the global visual system

Open Appearance → Editor → Styles. The exact panel order can vary with the active theme and WordPress version. Find the controls by role: Typography, Colors, Layout, and Blocks.

Preview before you commit

Preview the available style variations. A variation can change several settings together. Do not save a variation because its preview looks different. Choose it only if you can explain how its color, type, and spacing support the site’s content and then test the complete scope.

If no variation fits, keep the current variation and change the required settings directly.

Set readable colors

Define and record these global roles:

• page background;
• normal text;
• links, including a non-color cue such as an underline;
• headings; and
• button background and text.

Use exact color values in the notes when the interface exposes them. Check each text-and-background pair with the contrast method from Level 1. Keep link meaning visible without depending only on color. Test visited, hover, and keyboard-focus states in the visitor view when the theme supplies them.

Do not use a page-level color override to repair a global color conflict. Correct the global role or document the deliberate local exception.

Set typography and layout

In global Typography and Layout controls:

• choose a readable body typeface from the installed options;
• keep body text at a usable default size and line height;
• distinguish headings through a consistent type, weight, or size system;
• set a content width that prevents long text lines on wide screens; and
• keep a wider layout value only for blocks that need it, such as a large image or group.

Do not add a remote font or custom font file in the required path. Font licensing, loading performance, fallbacks, and privacy require separate evidence.

Customize one block type globally

Open Styles → Blocks → Button. Set the default button background, text, border, radius, and focus-visible treatment available in the active theme. Keep the result consistent with the recorded color roles.

If the site has no Button block, add one temporary draft Button block to a private draft page for the preview. Do not publish a meaningless action to satisfy the style check.

Record each setting, scope, and reason in the decision table.

Check the Style Book or several real pages

Use the Style Book when the active environment provides it. It previews many block types, but it does not replace real-page testing. Open at least the Home page and one content-heavy route in the visitor view before you save.

Use revisions as a recovery route

The Styles menu can provide revision history and reset actions. Before you use reset, identify whether it will remove one setting, the current saved revision, or all user customizations. Preserve the baseline ZIP even when revisions are available.

Customize the shared header

Open the Header template part from the Site Editor’s Design, Patterns, Template parts, or template List View route. The exact entry path depends on the active WordPress version and theme. Confirm the editor identifies the selected region as a Header template part before you change it.

The final shared header must contain:

• the Site Title block linked to the site root;
• the primary Navigation block with the required destinations; and
• a Site Tagline block or equivalent short site-purpose text.

If all three already exist, improve their grouping, spacing, or narrow-screen arrangement without changing the navigation destinations. Use List View to confirm the block hierarchy.

Do not type the site title separately into every page. Do not replace the Navigation block with a paragraph of links. The template part owns this repeated structure.

Save only the intended scopes

Select Save in the Site Editor. WordPress shows a list of the site records that will change. Review that list before you confirm it.

The intended list can include:

• Styles; and
• the Header template part.

Stop if the list contains an unrelated page, template, footer, navigation menu, or synced pattern that you did not intend to change. Cancel the save, inspect List View and recent edits, and isolate the cause.

After saving, open several visitor routes. Confirm that the same header appears where expected and that page content remains unchanged.

Checkpoint: Shared theme presentation is deliberate

What now works

Global colors, typography, layout, and Button defaults follow the documented visual system; the Header template part contains the required identity and navigation; and the save list contains only intended scopes.

What remains

Test the complete visitor result, document evidence and limits, then export and restore the customized site.

Next action

Open the site root in the visitor view and run the route-and-viewport test matrix.

If it does not work

Use the save review, Styles revisions, or theme-baseline.zip to return to the last confirmed state before making a smaller change.

Test the visitor result across the theme scope

Global and shared changes require more than one page check. Add these rows to the notes and record observed evidence:

Route and condition	Expected result
Site root at a wide viewport	Header, content width, headings, links, and media follow the visual system
Content-heavy route at a wide viewport	Text lines remain readable and headings keep a clear hierarchy
Every required route at about 320px	No horizontal overflow; header and navigation remain usable
Site root at 200% zoom	Content reflows without overlap or hidden actions
Primary navigation by keyboard	Every link receives visible focus and opens the correct route
Page with an image	Image, caption, and alternative text remain present and usable
Draft Button block or real button	Text contrast, border, and focus treatment remain clear

Also confirm that:

• the site title still identifies the complete site;
• each page title remains the page’s main heading;
• navigation order and destinations did not change unintentionally;
• text does not rely on color alone;
• page content was not duplicated into the template part; and
• no administration controls appear in the visitor result.

Fix one failed scope at a time. Record the failed observation, the owning layer, the change, and the repeated test.

Export and restore the customized site

When every required visitor check passes:

1. Use the Playground Dock Export → Download as .zip action.
2. Store the file as theme-customized-final.zip in cms-theme-practice.
3. Confirm that the file exists and is greater than 0 bytes.
4. Open a new Playground and use New → Import zip.
5. Restore theme-customized-final.zip.
6. Compare the active theme, global Styles, shared Header, site root, one child route, primary navigation, and one image with the tested working site.
7. Record the first mismatch, or none, in the notes.

A screenshot proves appearance at one moment. It does not prove that theme data, templates, navigation, media, and settings can be restored. The restored ZIP is the required recovery evidence.

Record the final local Git state

Commit only .gitignore and theme-customization-notes.md in the private practice repository. Confirm with git status --ignored that all three ZIP files exist locally and are ignored. Do not push the ZIP files or CMS credentials.

Self-check

Complete these checks against the required result.

1. Confirm that theme-source.zip, theme-baseline.zip, and theme-customized-final.zip are three separate local files greater than 0 bytes.
2. Restore the baseline and explain which content, navigation, theme, and settings it preserves.
3. Name one page-content change, one global Style change, one template change, and one template-part change without mixing their scopes.
4. Open Styles and confirm the recorded background, text, link, heading, Button, typography, and layout decisions.
5. Use List View to confirm that the shared Header contains site identity, primary navigation, and site-purpose text.
6. Review the saved site at a wide viewport, about 320px, and 200% zoom and confirm that no content clips, overlaps, or creates horizontal scrolling.
7. Use the keyboard to operate primary navigation and the tested Button and confirm visible focus.
8. Compare page titles, content, hierarchy, destinations, and media with the baseline and identify any deliberate difference.
9. Restore theme-customized-final.zip in a new Playground and confirm that the tested theme result returns.
10. Run git status and git status --ignored and confirm that the notes are committed while all ZIP files remain ignored and local.

Common theme-customization failures

Symptom	Likely cause	Focused check
Appearance has no Editor item	The active theme is classic or the account lacks capability	Confirm the active theme type and account permissions before changing themes
A color changes on only one page	The change was made on a page block instead of in global Styles	Inspect the selected block and the Styles scope
Page text changes across the site	Content was added to a shared template or template part	Use List View to locate the repeated block and move page-specific content back to the page
Navigation disappears on some routes	Those templates use another Header or Navigation block	Inspect the template and template part used by the failed route
Save lists unrelated records	The editing session changed more than the intended scope	Cancel, inspect each listed record, and undo or isolate unrelated edits
Narrow layout overflows	Header groups, navigation, wide blocks, or fixed dimensions cannot wrap	Inspect the first overflowing element at the failing width
Restore loses the customization	The wrong export was used or the latest save did not complete	Compare filenames, modification times, and the working save list before exporting again

Optional block-theme investigations

The required lesson is complete before these investigations. Preserve the verified final ZIP before each route.

Compare a second style variation

Restore theme-baseline.zip in a new Playground. Apply a different style variation, repeat the same visitor matrix, and compare the evidence with the required final design. Do not overwrite the required final ZIP.

Create a custom page template

Create one custom template for a legitimate alternate page type. Document which page uses it, which structure differs, and why the standard Page template is not sufficient. Test fallback behavior before deletion.

Inspect generated style sources

Use browser developer tools to inspect one global color or typography rule in the visitor view. Identify the computed value and source. Relate it to the saved Site Editor setting without editing generated CSS in developer tools.

Export a theme from Site Editor changes

Research the official Create Block Theme workflow in a separate practice copy. Compare a site-specific customization stored in the CMS with a distributable theme source change. Record which files, licenses, and maintenance responsibilities a reusable theme would require.

Optional references

• WordPress Site Editor documentation explains global Styles, templates, template parts, save review, and revisions.
• WordPress Styles overview explains global typography, colors, layout, block styles, and reset controls.
• WordPress block themes documentation distinguishes block themes from classic themes and lists Site Editor capabilities.
• WordPress Playground web instance guide explains Dock navigation, ZIP export, and ZIP restoration.

Next step or safe stopping point

The required lesson is complete when the restored final ZIP contains the tested global visual system and shared header, all affected routes pass the visitor matrix, and the notes identify each decision and its scope.

Continue to Add functionality to a CMS to evaluate and add one CMS capability without confusing content, theme presentation, and plugin behavior.

If you stop here, leave yourself this resume note beside the final ZIP: Global Styles and the shared Header are tested and restorable. Next, open the extended-functionality lesson and define the visitor need before selecting a CMS extension.