Reusable Components

Advanced page design breaks down when every page becomes a one-off. Reusable components give you consistency, faster editing, and fewer layout bugs.

In a GeneratePress + blocks workflow, you typically reuse things via:

• Block patterns (starter layouts)
• Reusable blocks (synced content)
• Elements (sitewide or conditional components)

Choose the Right Reuse Tool

Tool	Best for	Watch-outs
Pattern	Repeatable layout skeleton	Changing a pattern does not update existing pages
Reusable block	Synced content snippet	Updates affect every place it's used
Element	Conditional, template-level output	Overlapping display rules can create duplicates

caution

Do not use synced reusable blocks for content that should vary per page (like unique testimonials). You will overwrite pages accidentally.

A Maintainable Component Design

Good components are:

• Named by purpose (e.g., "CTA: Book a Call")
• Scoped (styling does not leak globally)
• Versioned (changes are tracked)

Give Components Shared Tokens

Reusable components feel cohesive when they share a small set of tokens (spacing, radius, container width). You can define these once and use them across patterns, blocks, and Elements.

Token	Suggested use	Example value
--space-2	small gaps	0.75rem
--space-4	section padding	2rem
--radius-2	cards and notices	10px
--shadow-1	subtle elevation	0 10px 30px rgba(0,0,0,.08)

CSS: component tokens (safe defaults)

:root {
  --space-2: 0.75rem;
  --space-4: 2rem;
  --radius-2: 10px;
  --shadow-1: 0 10px 30px rgba(0, 0, 0, 0.08);
}

.cta-section {
  padding: var(--space-4);
  border-radius: var(--radius-2);
  box-shadow: var(--shadow-1);
}

flowchart TD
  A[Component library] --> B[Patterns]
  A --> C[Reusable blocks]
  A --> D[Elements]
  B --> E[Pages]
  C --> E
  D --> E

Register a Block Pattern (Child Theme)

If you want patterns as code (deployable), register them in your child theme.

Child theme: register a simple CTA block pattern

<?php
add_action( 'init', function () {
    if ( ! function_exists( 'register_block_pattern' ) ) {
        return;
    }

    register_block_pattern(
        'gp-child/cta-book-call',
        [
            'title'       => 'CTA: Book a Call',
            'description' => 'A reusable CTA section for landing pages.',
            'content'     => '<!-- wp:group {"className":"cta-section"} --><div class="wp-block-group cta-section"><!-- wp:heading --><h2>Ready to talk?</h2><!-- /wp:heading --><!-- wp:paragraph --><p>Book a 15-minute call and we\'ll map a plan.</p><!-- /wp:paragraph --><!-- wp:buttons --><div class="wp-block-buttons"><!-- wp:button --><div class="wp-block-button"><a class="wp-block-button__link">Book a call</a></div><!-- /wp:button --></div><!-- /wp:buttons --></div><!-- /wp:group -->',
            'categories'  => [ 'buttons' ],
        ]
    );
} );

tip

Keep the registered pattern content minimal. Use CSS tokens and utility classes for styling, so you don't bake too much design into the pattern markup.

Elements as Components

Elements are ideal for components that should be controlled by rules:

• A sitewide notice bar (exclude checkout)
• A post-end CTA (only on posts)
• A category-specific intro section

Rule of thumb:

• If it's about content reuse, use blocks (patterns/reusable blocks)
• If it's about where it appears, use Elements

Versioning and Deployment

If you are working in a proper environment, treat component changes like code changes:

1. Make changes on staging.
2. QA a small set of representative pages.
3. Deploy changes.

From a server repo you might run:

Typical deploy flow (example)

git status
git diff

caution

Synced content (reusable blocks) can change many pages at once. Always test at least one page per template type before publishing major edits.

Hands-On: Build a Small Component Library

1. Create one CTA pattern (layout skeleton).
2. Create one synced reusable block (e.g., a trust badge row).
3. Create one Element for a sitewide notice (with clear display rules).

Stretch goal: create a naming convention document (even a short note) so future components follow the same pattern.

QA Checklist

Check	Pass criteria
Naming	Components have clear, consistent names
Scope	CSS classes are component-scoped
Safety	Synced blocks are only used where global updates are intended
Rules	Elements do not overlap in the same location

Troubleshooting

Symptom	Likely cause	Fix
Updating a pattern changes nothing	Patterns are not synced	Use reusable blocks or Elements for global updates
Global change broke one page	Synced block used where it should vary	Convert that instance to a normal block

Quick Reference

• Patterns = starter layouts
• Reusable blocks = synced snippets
• Elements = conditional template output

What's Next

• Next: Integration with Plugins