Font Library writes absolute URLs to fonts.css — breaks after domain migration

  • evomentum
    July 17, 2026 at 1:52 am

    The font library writes absolute URLs into wp-content/uploads/generatepress/fonts/fonts.css. After a domain migration the file keeps the old host, and no search-replace can fix it, because it is a file and not a database row.

    Setup:

    • GeneratePress 3.6.1 / GP Premium 2.5.6
    • WordPress 7.0
    • Local fonts added through the font library (EB Garamond, Montserrat)
    • nginx, no CDN offloading — uploads are served from the site host

    Steps to reproduce:

    1. Add local fonts through the font library while the site runs on a staging domain.
    2. Migrate the site to the production domain, so that siteurl and home point to the new host.
    3. Run a full search-replace over the database.
    4. Open any page and inspect document.fonts.

    Expected:
    fonts.css resolves against the current site URL and the fonts load.

    Actual:
    fonts.css still holds url('https://old-domain.tld/wp-content/uploads/generatepress/fonts/…'). Every @font-face reports status: "error" and the page silently falls back to the fallback stack. The generated file is never rewritten, and no database tool reaches it.

    What I’ve done to fix this:
    Editing fonts.css by hand and removing the host, which leaves root-relative paths such as /wp-content/uploads/generatepress/fonts/eb-garamond/…woff2. All three @font-face rules load correctly, and the fallback rendering is gone. Tested and working.

    Request:
    Please write root-relative URLs into fonts.css by default. The file lives under the same host as the fonts it points to, so the host name carries no information and only creates a migration trap. Relative paths would make every migration, staging clone and domain change work without manual repair.

  • Ying
    July 17, 2026 at 7:26 am

    Hi there,

    Thanks for reaching out!

    We have a GitHub issue open for this issue already; it’s on our list to add an option to use the relative URL for font files.

    If you are running into the issue right now, you can disable the font, save, then re-enable the font, it will clear out the old absolute URLs and generate new absolute URLs for the new site.

  • evomentum
    July 19, 2026 at 3:28 am

    Good to know! Thanks. Can you link the github issue for me here, so I can subscribe to it?

    Thanks!

  • Alvind
    July 19, 2026 at 7:47 pm

    Hi there,

    Unfortunately, it’s in a private repository so we’re unable to share the GitHub issue link.

  • juicerocket.com
    August 15, 2026 at 5:10 am

    Following up — the disable/re-enable workaround does not actually solve this. All it does is regenerate absolute URLs for whatever domain the site is currently on, so the moment you migrate, clone to staging, or push to production, the fonts break again and the manual repair has to be repeated every single time. For anyone running a staging → production workflow that means the fonts fall back to serif on every deploy. That is not a viable fix — it is a chore that has to be redone forever.

    This is a bigger issue than it may look: it silently degrades typography on production sites after any domain change, with no error surfaced to the admin, and no database search-replace can reach it because it lives in a generated file (wp-content/uploads/generatepress/fonts/fonts.css). Agencies and anyone with a clone-based workflow hit this constantly.

    The fix is genuinely small: write root-relative paths (e.g. /wp-content/uploads/generatepress/fonts/…) into fonts.css instead of absolute URLs. The file always lives under the same host as the fonts it references, so the hostname carries no information and only creates a migration trap.

    Since the GitHub issue is in a private repo, could you please (a) give a rough target release for the relative-URL option, and (b) post an update on this thread when it ships so subscribers here are notified? A concrete timeline would help — right now this is a recurring production problem with only a manual band-aid.

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.