When I compile my assets using bud, it uses the WP_SITEURL from the .env file to create the path to my assets. However, in Bedrock, the WP_SITEURL is configured as ${WP_HOME}/wp.
If I change WP_SITEURL to just ${WP_HOME} and run ‘yarn bud build’ the assets are loaded correctly, but that leads to all links in my website to break, because they expect the /wp suffix.
Perhaps I’m missing something very obvious here, but using my existing Bedrock .env values bud generates CSS asset paths that cannot be loaded ([siteurl]/wp/themes/[mytheme]/public. The asset paths should be [siteurl]/app/themes/[mytheme]/public.
module.exports = async (app) => {
app
/**
* Application entrypoints
*
* Paths are relative to your resources directory
*/
.entry({
app: ['@scripts/app', '@styles/app'],
editor: ['@scripts/editor', '@styles/editor'],
})
/**
* These files should be processed as part of the build
* even if they are not explicitly imported in application assets.
*/
.assets('images')
/**
* These files will trigger a full page reload
* when modified.
*/
.watch('resources/views/**/*', 'app/**/*')
/**
* Target URL to be proxied by the dev server.
*
* This should be the URL you use to visit your local development server.
*/
.proxy('http://mysiteurl.local')
/**
* Development URL to be used in the browser.
*/
.serve('http://0.0.0.0:3000/')
};
Beyond that, it looks like this commit introduced some stuff around the env vars you’re talking about, although based on the description that should only affect dev builds: fix: wp proxy by kellymears · Pull Request #1317 · roots/bud · GitHub If you’re seeing this happen on production builds, that may be a bug.
I noticed that assets which are being loaded via @asset or asset() in blade templates do not have the /wp/ prefix. And the compiled CSS and JS only have relative links. So my guess is that this has something to do with the code that handles the enqueue of styles and JS. I want to debug it further today and see if I find anything useful.
If I inspect my html I see that the Sage CSS and JS are being loaded like admin assets. For example jquery core and jquery migrate are both loaded from the /wp/wp-includes directory, so they should have a /wp prefix. But for some reason the Sage assets are prefixed with the same path.
The enqueue action is not the culprit, if I dump the contents of bundle(‘app’)->enqueue(), the path starts with /app/. Could it be that somehow the assets are being loaded as admin scripts and styles?
I have solved the issue, though I’m sad to say without finding the root cause. First I copied the /layouts/app.blade.php from my Sage9 theme and replaced the existing app.blade.php. The default Sage10 app.blade.php doesn’t have the <html> and <body> tags so I guess they are loaded elsewhere?
After this I ran the wp acorn commands to clear all cached and compiled assets:
wp acorn clear-compiled
wp acorn config:clear
wp acorn optimize:clear
wp acorn view:clear
And now all the Sage Css and JS assets are loaded with the correct relative paths.
Ah yes I do have Soil installed, and the issue is exactly as mentioned in the link to the bugreport. I’m skipping wp acorn optimize for now as this caused the /wp/ prefix in my asset URL’s.
And thanks for pointing out the base HTML in index.php!
@sanderdewijs I had the same issue. I have bumped up the Bud version to 5.8.x and it seems it is working fine for me. I have also reactivated the Soil plugin.