Upgrade to gulp 5.0 breaks building theme assets (corrupted fonts, images, etc)

Developer help
1

Hi, Ghost community,

After uploading a custom theme to my Ghost site hosted on PikaPods, I’m encountering font loading errors in Chrome’s console:

  1. Failed to decode downloaded font: […/assets/fonts/Manrope[wght].woff2]
  2. OTS parsing error: Failed to convert WOFF 2.0 font to SFNT

These errors appear for both my custom theme and the original Solo themes. Here are some additional details:

  • Hosting: PikaPods
  • Hosting NS: Cloudflare (using proxies, but try to turn off it)
  • Browsers: Chrome (latest version), and many others
  • Font file: Manrope variable font (WOFF2 format)
  • Locally environment: No issues

Questions:

  1. What could be causing these font decoding and parsing errors?
  2. Are there any known issues with WOFF2 fonts on PikaPods?
  3. How can I troubleshoot and resolve these font loading problems?

Any insights or suggestions would be greatly appreciated. Thank you!

2

I’m getting this exact issue today as well, when I wasn’t before. How odd. woff2s returning with the same parsing errors. I’m on Digital Ocean using the official droplet.

3

I’d be happy to try loading a test theme on my Ghost Pro test site to see if the problem is there, too.

1 Like
4

When I try to download one of the woff2s directly (copying the actual URL from the network inspector), it downloads, and looks like a binary font file if i open it in a text editor (ie it’s not an html error, and the binary starts with ‘wOF2’), but i can’t actually open it as a font, so it is actually corrupting somewhere along the way.

5

I have an inkling that this might actually be the zipper in my gulpfile that’s corrupting these, rather than a server issue. Investigating further.

2 Likes
6

Ok it appears that was the problem. Fixed on my end. Hope this helps you as well @kmrdzk – at some stage recently I migrated from gulp 4 to 5, for no particularly important reason I remember.

There’s a breaking change in stream encoding in gulp 5, so you need to pass a new option of {encoding: false} to the src(…) line of zipper to account for this.

Eg:

pump(
    [
      src(["**", "!node_modules", "!node_modules/**", "!dist", "!dist/**"], {
        encoding: false,
      }),
      zip(filename),
      dest(targetDir),
    ],
    handleError(done)
  );
2 Likes
7

Thanks for that! I hit some weirdness with theme images getting messed up a couple weeks ago that I never solved, and I’m betting that this is the solution to that problem, too!

2 Likes
8

Exactly, I’ve tried to investigate and went around CORS (Cross-Origin Resource Sharing) issues and MIME-type configuration on the server side.

  1. CORS is not a concern when the fonts are served from the same host. (sever support team help me)
  2. Also, when I used curl for direct files on the server, this error appeared : > downloadable font: rejected by sanitizer - so, that might be that the font files were corrupted.

Then I replaced fonts sources from Google Fonts direct links and they worked!

Your Idea with the gulp zipper is brilliant. My gulp version also:

“name”: “gulp”,
“version”: “5.0.0”

Could you please exactly what gulp file should I edit to test it? I’m a newbie in coding

9

It really depends on your theme - there’s no one rule for how gulp is used in ghost themes, but if it follows the standard of the built-in themes, you’ll find a “gulpfile.js” in the root directory of the theme. You’ll want to make the change above within the function that zips up the files, which is probably called “zipper”.

Alternatively you could downgrade your gulp to v4 - this might be easier for you if you’re not confident in editing that code, and will probably work too (though might not, depending on what else is going on in that file)

1 Like
10

I’m going to retitle this thread, because I think we aren’t the only folks who are going to hit this bug and need this fix. :)

2 Likes
11

Great call. In that spirit, I should probably point out that there’s a chance my solution may have some subtle side effects and there’s perhaps a more robust change needed here.

This was the official change announcement –

Our streams now default to UTF-8 encoding. Previously, our streams took whatever data was emitted without considering any encoding. However, in this release, we resolved a 10 year old issue to support custom encodings and we default these to UTF-8. Most usage of gulp won’t need to change anything, but certain plugins may produce non-UTF-8 output and you’ll need to set { encoding: false } on your gulp streams.

So in that case, setting encoding entirely to false could throw up some random utf-8 issues elsewhere in the process? I don’t have time to dig further in as this change is working for me, but flagging it for future visitors :slight_smile:

1 Like