WordPress Full Site Editing: Fix Broken Templates & Styles

You updated your block theme, or a client edited something in Appearance → Editor, and now the homepage template shows the wrong layout, the header block is missing, or your custom colors reverted to theme defaults. If you're running a block theme (Twenty Twenty-Four, Twenty Twenty-Five, or any FSE-ready theme), this is one of the most common support tickets we see — and it has almost nothing to do with a broken site. It's a template-precedence problem.

Symptom: templates or styles disappear after an update or edit

The usual reports look like one of these:

• You update the theme from the WordPress dashboard, and your homepage reverts to a generic default layout — the hero section, custom header, or footer you built in the Site Editor is gone.
• Appearance → Editor → Templates shows a template as Customized, and reverting it wipes out changes you don't remember making.
• Global styles (fonts, colors, spacing) reset to theme defaults after an unrelated plugin update.
• A template part — usually the header or footer — shows twice, or not at all, on specific pages.
• You see This template no longer exists when clicking into a page's template from the block editor.

None of this throws a fatal error or shows up in your error log, which is what makes it frustrating: the site still works, it just doesn't look like what you built.

Cause: WordPress is choosing between two copies of every template

Classic PHP themes store templates as .php files and that's the end of the story. Block themes don't work that way. Every template and template part effectively exists in two places, and WordPress has to decide which one wins:

1. The theme's files — HTML template files inside /wp-content/themes/your-theme/templates/ and /parts/, plus the theme's theme.json for global styles.
2. The database — any time you edit a template or global style in the Site Editor, WordPress saves that edit as a custom post in the wp_template or wp_template_part post type (or a wp_global_styles entry). This database copy overrides the theme file, permanently, until you explicitly reset it.

That's the whole mechanism behind every symptom above:

Plugins that inject their own block patterns (page builders, SEO plugins with schema blocks, WooCommerce) can also register templates or parts with a slug that collides with your theme's, which produces the same duplicate/missing symptom without touching the Site Editor at all.

Why it's hard to catch before it happens

The Site Editor UI doesn't clearly flag that something is now different from the theme file, outside of a small Customized badge that's easy to miss if you're not looking for it. Most site owners only find out something changed when a visitor points out the homepage looks wrong.

Fix: find out which copy is live, then choose deliberately

1. Check which templates have database overrides

Go to Appearance → Editor → Templates → Manage all templates. Any template showing a Customized label has a saved database copy overriding the theme file. Click it, then use the options menu (three dots) → Clear customizations to drop the database copy and fall back to the theme's original file — do this only if you're sure you don't need the saved changes, since it's not reversible from the UI.

2. If you want to keep the customization, export it first

Before clearing anything, use Appearance → Editor → (three-dot menu) → Export to download a zip of your current templates and styles. This gives you a rollback point and, more usefully, a set of files you can move into a proper child theme so they stop living only in the database.

3. Reset global styles cleanly

In the Site Editor, go to Styles → (revert icon at top) → Reset to defaults. If styles keep reverting on their own after that, check for a caching or optimization plugin that's clearing custom post types on cache flush — WP Rocket, LiteSpeed Cache, and similar tools occasionally do this when a full cache clear is configured too aggressively. Exclude wp_global_styles and wp_template post types from any database-cleanup routine.

4. Fix duplicate or missing template parts

Duplicate headers/footers almost always mean two parts share a slug. Check via SSH or File Manager:

grep -r "slug" wp-content/themes/your-theme/parts/
grep -r "slug" wp-content/themes/your-child-theme/parts/

If a plugin is the source, deactivate it temporarily and check Appearance → Editor → Patterns to see if the duplicate part disappears. Rename the conflicting part's slug in your child theme rather than editing the plugin.

5. Recover a broken template from a backup, without a full site restore

You don't need to roll back the entire site to fix one template. If you're on Getwebup hosting with JetBackup, restore just the single row from wp_posts where post_type is wp_template or wp_template_part and the post_name matches the broken template — phpMyAdmin's row-level restore from a backup snapshot handles this without touching anything else on the site.

Prevention: stop editing the theme's live database copy directly

• Use a child block theme. Create /wp-content/themes/your-theme-child/ with its own style.css, theme.json, and a templates/ folder for any template you customize. Child block themes inherit everything else from the parent automatically, and your customizations survive parent theme updates because they live in files, not in a database row the updater can orphan.
• Version control theme.json. Even a simple git repo for your theme folder means you can diff what changed after an update instead of guessing.
• Test theme updates on staging first. This is the single biggest gap we see — block theme updates change template markup far more often than classic theme updates do, so updating live and checking later is riskier than it used to be.
• Audit plugins that register block patterns or templates (page builders, WooCommerce, SEO tools) after any update, especially if they touch the header or footer.
• Export your Site Editor customizations periodically even if you're not planning changes — it takes thirty seconds and gives you a restore point independent of your regular site backups.

Full Site Editing gives you a lot of control without touching PHP, but that control lives in the database by default. Once you know that, most of these theme-update-broke-my-site tickets turn into a five-minute fix instead of a rebuild.