← Back to Blog

Creating and Editing Custom Templates

A custom template provides an alternative reusable layout for selected content.

Veyra Admin

4 min read

  • Guide
  • Intermediate
  • 5 minutes read
  • Reviewed August 5, 2026
  • WordPress themes and templates

A custom template provides an alternative reusable layout for selected content.

Examples include a full-width page, a landing page without the normal title, a documentation layout with a sidebar or a campaign page with a different header.

The implementation depends on whether the active theme is block-based or classic.

Custom Templates in Block Themes

Block themes can register templates through theme files and theme.json. Authorized users can also create or edit templates through the Site Editor or Template Editor.

A block template uses dynamic blocks such as Post Title and Post Content to display the current record. It can include template parts and patterns for reusable structure.

When a user edits a theme-supplied template, WordPress can store the customized version in the database. That version may override later file changes until it is reset.

Creating a Template in the Site Editor

A typical workflow is:

  1. Open Appearance → Editor.
  2. Open Templates.
  3. Add a new template or choose an existing one.
  4. Build the structure with blocks and template parts.
  5. Include the appropriate dynamic content blocks.
  6. Save the template.
  7. Assign it to supported content where required.
  8. Test several records, not only one example.

Interface labels can change between WordPress releases, but the underlying distinction between content and template remains.

Custom Templates in Classic Themes

Classic themes create custom page templates in PHP.

A file header identifies the template name and can optionally restrict the supported post types. The file then renders the structure using WordPress template functions.

Place vendor-theme customizations in a child theme rather than editing the parent directly.

Designing the Template Contract

Before creating a template, define:

  • Which content types may use it.
  • Which fields or blocks it expects.
  • Whether it includes a title and featured image.
  • Which global template parts it uses.
  • How wide and narrow content behave.
  • How it responds on small screens.
  • Whether editors can modify the structure.
  • What happens when optional content is missing.

A template should not require editors to remember undocumented layout tricks.

Avoiding Template Proliferation

Do not create a new template for every small variation.

Prefer:

  • Block styles for visual variants.
  • Patterns for reusable sections.
  • Template parts for shared regions.
  • Conditional code for small contextual changes.
  • A limited set of clearly named templates.

Too many templates make assignments inconsistent and increase testing work.

Updating Templates Safely

Treat templates as production code or governed configuration.

  • Test changes in staging.
  • Review every content type that uses the template.
  • Keep exports or version-controlled files.
  • Check database overrides.
  • Verify accessibility and responsive behavior.
  • Avoid deleting a template without migrating assigned content.
  • Document any plugin blocks required by the layout.

Frequently Asked Questions

Can I create a template without coding?

Yes, block themes and compatible themes allow template creation with blocks. Classic PHP templates require code.

Why does my new template not appear for a post type?

The template may not be registered for that content type, the theme may not support the relevant editor or permissions may restrict assignment.

What happens if I delete an assigned template?

Content normally remains, but WordPress will fall back to another available template and the layout can change.

Applying Creating and Editing Custom Templates in a Real WordPress Project

Separate content, presentation and permanent functionality. Test the editing workflow as well as the public output, because a theme decision affects templates, design controls, accessibility, performance and future redesign work.

A connected concept is WordPress Templates and Template Parts. Reading the two together helps separate the immediate task from the wider WordPress responsibility.

A useful implementation begins by writing down the current state, the intended outcome and the evidence that will prove the change worked. This prevents a configuration screen, plugin recommendation or code snippet from becoming the entire strategy.

A Reliable Workflow

  1. Define the outcome and the people affected.
  2. Inventory the current configuration, data and dependencies.
  3. Confirm a backup or rollback point.
  4. Rehearse the change on staging when production risk is meaningful.
  5. Apply one controlled change at a time.
  6. Validate the primary workflow and related functionality.
  7. Clear only the caches that are relevant.
  8. Record the final configuration, owner and next review date.

Validation Checklist

  • The intended WordPress object, setting or workflow changed.
  • Existing content and permissions still behave correctly.
  • Mobile, keyboard and authenticated states were tested where relevant.
  • Logs do not show new warnings or failed background work.
  • URLs, redirects and search signals remain consistent.
  • Another team member can understand the final state from the documentation.

Rollback and Documentation

A rollback is part of the procedure, not an admission of failure. Record which files, database state, settings and external services must return to the previous version. Document any data created between the change and rollback.

Official Reference Context

The Theme Handbook is the primary version-specific reference for this topic. Use the current documentation to verify interface labels, supported APIs and behaviour before applying instructions to a production site.

How to Verify the Result

  • Test representative templates on mobile and desktop.
  • Check keyboard navigation, headings, contrast and focus.
  • Switch editing contexts and confirm that the team knows where each design decision is stored.

Sources and Further Reading

Continue Learning