WordPress Full Site Editing: Database vs Theme Files

WordPress Full Site Editing gives you a visual editor for your entire site — header, footer, templates, global styles. What it doesn’t make obvious is that your changes can end up in two completely different places: your theme files on disk, or the database. They look identical in the editor. The implications for deployment, version control, and backups are completely different.

The two storage locations in WordPress Full Site Editing

When you edit a template or template part in the FSE editor, WordPress doesn’t automatically save back to your theme file. It creates a copy in the database — a custom post type — and uses that copy instead. Your theme file is still there, but it’s now silently ignored.

The database post types involved:

• wp_template — stores per-template overrides (single.html, archive.html, etc.)
• wp_template_part — stores header, footer, and other parts
• wp_global_styles — stores Global Styles changes (colors, typography, spacing set via Appearance → Editor → Styles)

Global Styles are always stored in the database. There is no “save to file” option for them in the editor. If you change your site’s font or color palette through the UI, that change lives in the DB regardless of what’s in your theme.json.

How WordPress decides which to use

The rule is simple: if a DB copy exists, it wins. WordPress checks for a wp_template record matching your theme and template slug before falling back to the theme file. The moment you hit Save in the FSE editor, a DB record is created and your theme file becomes a fallback that’s never reached.

This means:

• Deploying a new version of your theme file has no effect if a DB override exists
• Restoring a database backup restores the DB overrides but not necessarily your theme files
• A fresh WordPress install with your theme will look different from your live site if significant customization lives in the DB

How to tell what’s actually in use

Check for DB overrides via WP-CLI:

wp post list --post_type=wp_template --fields=post_name,post_status --format=table
wp post list --post_type=wp_template_part --fields=post_name,post_status --format=table

Any record with post_status=publish is an active DB override. Compare that list against your theme’s templates/ and parts/ directories to see exactly which files are being bypassed.

For Global Styles:

wp post list --post_type=wp_global_styles --fields=ID,post_title,post_status --format=table

A record here means your visual style customizations are in the DB. To see the actual content:

wp post get ID --field=post_content

The output is a JSON blob containing your theme.json overrides.

Pushing DB overrides back to theme files

If you’ve been editing in the UI and want to move those changes into your theme files so they’re in version control, the process is:

For templates and template parts:

# Get the DB content
wp post get POST_ID --field=post_content > templates/single.html

# Then delete the DB override so WordPress uses the file
wp post delete POST_ID --force

After deleting the DB record, WordPress falls back to your theme file. Confirm in the editor that it still looks right.

For Global Styles:

The JSON from wp_global_styles maps directly to theme.json structure. Extract the settings and styles keys and merge them into your theme.json. Then delete the DB record.

wp post get GLOBAL_STYLES_ID --field=post_content | python3 -m json.tool

This gives you readable JSON to work from. The keys under styles in the DB record correspond to the styles block in theme.json.

What belongs in git

For a fully file-driven FSE theme, git should contain:

• templates/*.html — all block templates
• parts/*.html — all template parts
• theme.json — all global style definitions
• style.css, functions.php — theme metadata and PHP
• patterns/ — any registered block patterns

The database should ideally have no wp_template, wp_template_part, or wp_global_styles overrides in production. If it does, you have customizations that aren’t in version control and will be lost or will diverge from your theme files.

When DB overrides are intentional

There’s one legitimate use case for leaving customizations in the DB: content editors who need to adjust templates without touching theme files or requiring a deployment. In a multi-author setup you might intentionally allow template customization through the UI and treat the DB as the source of truth.

If that’s your model, the implication flips: your database backup is what matters, and your theme files are just a starting point. Make sure your backup strategy covers the DB thoroughly, and be aware that theme updates will be shadowed by the DB overrides until you clear them.

The practical recommendation

For a single-operator site where you control both the theme and the server: keep everything in files. Do your template editing locally or in a staging environment, commit to git, deploy the files. Use the FSE editor in the browser for previewing and planning, but treat any save as something to extract back to a file before it goes to production.

If you’re managing WordPress with git, this is the piece that makes FSE themes actually deployable — once you know where the changes are stored, you can make sure the right things end up in the right place.