Use case

Check where WordPress patterns, template parts, and shared references are used before updating them

When a pattern, template part, or shared navigation changes, the real risk is not the definition alone. The real risk is every page, template, or shared source that already depends on it.

When this matters #

This workflow matters when a shared pattern, template part, or navigation change could ripple beyond a single page edit.

• A pattern, template part, or navigation item is about to change and the team needs to understand downstream references first.
• A WordPress team needs to decide whether to update the shared definition or only selected sources that reference it.
• A redesign or cleanup could affect reusable content and site chrome as well as posts and pages.
• Release planning needs a clearer view of how shared structures are distributed across the site.

Why manual work is risky #

Shared structures are risky to review manually because their impact is usually indirect.

• Looking only at the shared definition does not reveal which sources depend on it today.
• Changing a definition when only a subset of references should move can widen the impact too much.
• Treating shared-entity work like a normal page edit makes preview and QA harder to reason about.

How DXM Block Toolkit helps #

DXM Block Toolkit helps teams check both the shared definition and its reference footprint before they update either one.

• Inventory and source review help distinguish the shared definition from the sources that depend on it.
• Source-backed evidence reveals the blast radius of changing a pattern, template part, navigation structure, or similar shared entity.
• Refactor mode selection keeps entity_definition and entity_reference work separate so preview and apply stay explicit.
• Teams can review shared structures alongside normal content sources instead of treating them as invisible implementation details.

Concise workflow #

A concise impact-check workflow keeps definition changes and reference changes clearly separated.

1. Run a fresh scan and identify the shared pattern, template part, navigation structure, or similar entity involved in the change.
2. Review the current definition and the exact sources that reference it.
3. Decide whether the change belongs at the shared definition level or only at selected references.
4. Use the matching Refactor mode or review workflow so preview, apply, and validation align with the intended boundary.
5. Share the source-backed impact list with the team before implementation or rollout starts.

If you need the operational steps, continue with How to Choose the Right Refactor Mode .

Related use cases #

Use a related workflow when shared-structure review becomes broader usage discovery, redesign impact analysis, or controlled replacement work.