If you have the ForgeWP monorepo, its theme projects offer useful examples alongside the smaller recipes. Start with a specific feature and trace it from source to configuration and generated output. The projects contain work in progress and project-specific choices, so use them as examples to investigate rather than as release-certified templates.

Choose a project to study

These names describe folders in this checkout; they are not commands or required dependencies of a generated theme. Auth and WooCommerce implementations have their own package scope and verification needs.

Trace one editable section

In hospitality, the front-page schema uses buildPageEditable to combine section schemas and prefixes. The hero selects fields with pickEditable, including mappings such as previewLabel to a Page key like hero_preview_label.

Read the four layers together:

1. The section schema declares types and defaults.
2. The Page schema combines them into Page metadata keys.
3. The shared React section reads the selected fields and renders editable values.
4. The block definition exposes an instance's attributes to Gutenberg.

The Page metadata and a block's attributes are separate storage locations. Reusing the visual component does not make every Page and block share one saved value. Use resolveDualHost when selecting an explicitly supplied attribute/prop before a metadata fallback, and preserve empty strings, zero, and false.

For a smaller starting point, complete the editable hero and room-details fields recipes before adapting a whole section.

Trace a form

In hotelchecker24/cms/forms/contact.ts, one defineWpForm contract declares fixed name/email fields and locale-specific client fields. Its filename establishes the contact key.

Follow that key into the form component and check the matching submitWpForm or useWpForm call. Then inspect the exported form definitions. A local simulated success verifies the UI path; send a real test on WordPress to verify validation, stored submissions, and configured mail delivery.

See Native Forms and Client Fields & Search.

Trace a custom post template

hotelchecker24/src/app/single-listicle.tsx exports its Page component as the template entry. WordPress selects the generated single-listicle.php for that post type; local routes.tsx supplies preview routes.

Check the post-type registration, permalink configuration, post data bindings, and related queries together. If a query uses metadata or taxonomy filters, keep its stable queryId contract and verify the real WordPress results. See Route Sync & CPT Templates.

Separate presentation from live data

A component's name is not evidence of backend behavior. For example, forge-commerce/src/components/ProductGridSection.tsx includes a local PRODUCTS array. Those cards illustrate design; that array alone does not establish WooCommerce inventory, checkout, or editable product records.

When adapting any theme, identify whether a value comes from:

• A source constant or imported asset.
• Mock data used by the local preview.
• A Page metadata field or block attribute.
• A WordPress option, menu, query, or installed plugin.

Then identify who edits it and what a theme update should do. Use the content ownership guide to make those choices explicit.

Verify your adaptation

Work in a copied theme or branch, keep your own site identity and real links, and review seed settings before installation. Export with validation, inspect the generated bindings, and test the changed workflow in WordPress with existing content. The release checklist gives you a repeatable path.