Assets path wrong with yarn build (yarn start OK)

[jokanane]

Hi,

a similar scenario might have been discussed before, but I haven’t found an answer to my problem, sorry.

When I refer to assets (e.g. SVG files) in .scss files as in …:

  .show-all {
    background-image: url("../images/svg/show-all.svg");
  }

… the following happens:

1. yarn start => everything works, SVG files are displayed
2. yarn build => SVG files don’t show up

If I look at Chrome’s inspector:

1. After yarn start, the assets are referred to as: background-image: url(http://localhost:3001/wp_site_name/wp-content/themes/theme-name/dist/images/svg/show-all.svg)
2. After yarn build, the assets are referred to as background-image: url(/wp-content/themes/theme-name/dist/images/svg/show-all.svg), which further resolve in the browser to http://localhost:8888/wp-content/themes/theme-name/dist/images/svg/show-all.svg

I might be dumb or blind, but I don’t get why the browser resolves the second one to…:

http://localhost:8888/wp-content/themes/theme-name/dist/images/svg/show-all.svg

… and not…:

http://localhost:8888/wp_site_name/wp-content/themes/theme-name/dist/images/svg/show-all.svg

…when I access the site at…:

http://localhost:8888/wp_site_name/

The built main.css looks good to me…:

.show-all {
  background-image: url(/wp-content/themes/theme-name/dist/images/svg/show-all.svg);
}

And the SVG files appear correctly in the dist/images/svg/ directory. It’s only the “wp_site_name/” part, which gets lost.

Further info:

In the early days using Sage, I had often trouble with BrowserSync and reload-loops, which has possibly thrown my config.json off. Here’s an example of what I typically have there:

{
  "entry": {
    "main": ["./scripts/main.js", "./styles/main.scss"],
    "customizer": ["./scripts/customizer.js"]
  },
  "publicPath": "/wp-content/themes/theme-name",
  "devUrl": "http://localhost:8888/wp_site_name",
  "proxyUrl": "http://localhost:3001/wp_site_name",
  "cacheBusting": "[name]_[hash:8]",
  "watch": ["app/**/*.php", "config/**/*.php", "resources/views/**/*.php"]
}

Finally, I’ve had the problem with asset paths for a long time, but got away with it as I got into a habit of converting simple SVGs to base64, which I then gave directly in the .scss files, but now I’ve got an SVG file so large that converting and having base64 data in .scss files is no longer feasible. It’s time to find and fix the real cause of the problem.

Any help much appreciated, thank you so much for your time!

[strarsis]

With HTTP2 inlining/spriting doesn’t incur significant performance improvements in most cases anyway.

[alwaysblank]

Have you tried changing publicPath in your config.json to /wp_site_name/wp-content/themes/theme-name? That value is used IIRC to generate absolute public paths to your assets, so without wp_site_name it’s going to generate all the wrong asset paths.

[jokanane]

Have you tried changing publicPath in your config.json to /wp_site_name/wp-content/themes/theme-name ?

I have now per your suggestion, and while the SVG shows up, wouldn’t /wp_site_name need to be sitename.com on server?

[alwaysblank]

If your production site is not in a sub-directory, yes, it need to be different, although you wouldn’t want to put the domain there–you’d just want to leave out wp_site_name. Generally best practice is for your site structure to match in development and production–i.e. if your production site is not in a subdirectory, your development site shouldn’t be in a subdirectory either, to avoid issues like this. I don’t know which version of Sage you’re on, but in Sage 9 you can set the SAGE_DIST_PATH environment variable at build time to get around this and specify a different path.

[jokanane]

Thanks for the explanation @alwaysblank - I think I’ve got it now.

First the conditions: I’m on Sage 9 and MAMP on local (no Bedrock, no Trellis). The sites are in subdirectories…:

/Applications/MAMP/htdocs/wp_site_name_1/
/Applications/MAMP/htdocs/wp_site_name_2/
/Applications/MAMP/htdocs/wp_site_name_3/

… which correspond to …:

http://localhost:8888/wp_site_name_1/
http://localhost:8888/wp_site_name_2/
http://localhost:8888/wp_site_name_3/

If I use just yarn start on local dev (which works) and yarn build for server (which also works), everything’s well. I’ve tested all this now.

It’s worth noting that all my sites run on shared hosting, which may or may not have all the tools available, so I’ve settled for building on local and deploying dist using git. (Could also be a bad habit and the tools or the lack thereof aren’t to blame.)

So then, I think I’ve never deployed a yarn build which appears broken on local … even when it would’ve worked!