[SOLVED] FSE Custom Fonts Broken with Escaped URLs After Site Migration

Hello everyone,

I want to share a solution to a stubborn issue I encountered after migrating a WordPress site that uses a Full Site Editing (FSE) theme. I hope this helps others who run into the same problem.

The Problem (Symptoms)

After migrating a WordPress site from a subdirectory structure (https://old-domain.com/mysite) to a new subdomain (https://mysite.new-domain.com), all the custom fonts I had added using the FSE Font Library were broken.

The browser’s developer console was filled with errors like:

• CORS Policy Errors: Access to font at 'https://old-domain.com/mysite/...' from origin 'https://mysite.new-domain.com' has been blocked by CORS policy.
• 404 (Not Found) Errors: The browser was failing to load font files from the old URL.
• The site’s typography had reverted to the theme’s default fonts.

Why Standard Solutions Failed

I tried all the usual migration troubleshooting steps, but none of them worked:

1. WP-CLI Search & Replace: Running wp search-replace did not fix the font URLs.
2. File Search (grep): Searching the entire wp-content directory for the old URL string returned nothing, proving the old URL was not hardcoded in any theme files.
3. FSE Font Library: Deleting and re-installing the fonts via the Font Library (Appearance > Editor > Styles > Typography > Manage Fonts) did not resolve the issue.
4. Regenerating CSS / Clearing Caches: Clearing all server and browser caches had no effect.

The Root Cause

After extensive digging, the problem was identified in the database.

Full Site Editing themes store their global style configurations (including custom font paths) in the wp_posts table. This data is saved as a single post with post_type = 'wp_global_styles'.

The entire configuration is stored as a large JSON object in the post_content column. Crucially, the URLs inside this JSON object are saved with escaped forward slashes (e.g., https:\/\/old-domain.com\/mysite\/...).

Standard search-and-replace tools, including WP-CLI in some cases, can fail to correctly parse and update these escaped URLs deep within the JSON string. This leaves “ghost” URLs in the database that are used to dynamically generate the site’s CSS on each page load.

The Definitive Solution: Direct SQL Database Update

The only way to fix this is to run a direct SQL REPLACE() query on the database to find and replace the incorrect, escaped URL string.

Here are the steps:

Step 1: Connect to your database.
Log into your server via SSH and connect to your database client (e.g., sudo mysql -u root -p).

Step 2: Select your WordPress database.

USE your_wordpress_database_name;

Step 3 (Optional but Recommended): Verify the problem.
Run this SELECT query to see the broken data for yourself. You will see the old, escaped URLs in the output.

SELECT post_content FROM wp_posts WHERE post_type = 'wp_global_styles';

Step 4: Run the UPDATE query.
This is the command that fixes the issue. It targets only the global styles post and replaces the old URL with the new one.

Important:

• Replace 'old:escaped\\/url' with your old URL structure.
• Replace 'new.url' with your new URL.
• Note the double backslash (\\) in the old URL. This is necessary for SQL to correctly match the single \ in the database.

Example Query:

UPDATE wp_posts 
SET post_content = REPLACE(post_content, 'https:\\/\\/old-domain.com\\/mysite', 'https:\\/\\/mysite.new-domain.com') 
WHERE post_type = 'wp_global_styles';

You should get a Query OK, X rows affected message.

Step 5: Force WordPress to Regenerate Styles.
The database is now correct, but you need to make WordPress re-read it.

1. Log into your WordPress admin dashboard.
2. Go to Appearance -> Editor -> Styles.
3. Make a small, insignificant change (e.g., change a background color slightly, then change it back).
4. Click Save. This forces FSE to discard its old styles and rebuild them from the corrected database entry.
5. Clear all caches and do a hard refresh of your website.

The font errors will now be completely resolved.

I hope this detailed explanation helps anyone else struggling with this frustrating migration issue