Missing images on yarn build, but yarn start works

[Lefevre_Christophe]

I’m having an issue with images assets not showing on yarn build:production while everything runs smoothly on yarn start. Is there something wrong with my virtualhost or config.json ?

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

Chrome’s dev tool shows this image url :

background-image: url(/wp-content/themes/angely/dist/images/pic1.jpg);

This seems correct at first but I noticed that my devUrl was ignored. The full URL being http://127.0.0.1/wp-content/themes/angely/dist/images/pic1.jpg instead of http://angely.local/wp-content/themes/angely/dist/images/pic1.jpg

If I upload the theme on a remote sever I have no issue at all.

Can anybody help? Thanks in advance.

[craigpearson]

When referencing images which are stored in your assets directory it’s always best to use relative urls like so:

background-image: url('../images/pic1.jpg');

Ref: https://roots.io/sage/docs/theme-development-and-building/#images-in-css

[Lefevre_Christophe]

That’s exactly how it is declared in my SCSS file. I was actually talking about the url that you see with Chrome’s inspector tool.

On yarn start the inspector shows an url that starts with http://localhost:3000 which works perfectly fine.

But on yarn build:production it shows an url that starts with http://127.0.0.1 instead of either http://127.0.0.1/angely or http://angely.local

[craigpearson]

Ahh I see, so that would be the correct behaviour, urls are relative on a build so your configuration appears to be setup correctly in terms of the sage theme. If for example you ran yarn run build:production and then sent your theme to production that URL would change based on where the theme is loaded from, based on compiled files having relative URLs.

My initial port of call would be to investigate your development machine hosts file, ensuring it correctly handles angely.local and also confirm that WordPress has the correct site URL in the WordPress dashboard.

Are you using the full roots stack for your local environment? I.e. Bedrock and Trellis?

[Lefevre_Christophe]

No i’m not using Bedrock and Trellis, i’m doing it the old way with Wamp. I know I should go for those time-saving tools asap but I haven’t learned them yet, so maybe in a near future

My virtualhost is set up like this :
(httpd-vhosts.conf)
# angely.local
<VirtualHost *:80>
ServerName angely.local
DocumentRoot “d:/wamp/www/angely”
<Directory “/”>
Deny from all
Allow from 127.0.0.1

(\windows\drivers\etc\hosts)
127.0.0.1 angely.local

The site URL in the Wordpress dashboard is http://127.0.0.1/angely

It’s most likely an issue with my how my virtualhost is configured but I can’t get my hands on what’s wrong.

[craigpearson]

Thanks for sharing that’s a huge help!

If you’d like your URL to read http://angely.local/* locally you will need to update your URL in the WordPress Dashboard to http://angely.local. You do not need to provide the subfolder in this URL as your vhosts config is automatically handling that via DocumentRoot “d:/wamp/www/angely”

If you’d like your URL to read http://angely.local/angely/* you would need to set your WordPress Dashboard URL to be http://angely.local/angely. You would then need to enable mod_rewrite (I assume this is already enabled to handle pretty permalinks). And in your htaccess file handle the subfolder rewrite. For example:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /angely/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /angely/index.php [L]
</IfModule>

The reason 127.0.0.1 is showing as your domain in inspector is because that’s what the URL is set as in WordPress

[Lefevre_Christophe]

Awesome! It works like a charm!

I thought that the virtualhost and localhost/subfolder were treated the same.

Thank you so much for you help Craig! You solved this problem in the blink of an eye, thumbs up!