This happens to me sometimes as well, but I think I’ve discovered it’s because, during the Sage install (w/composer create-project...), I’ve made a habit of just hitting enter to go with the default path to the theme directory instead of updating it to reflect the name of my theme. This means the publicPath in resources/assets/config.json is set to app/themes/sage instead of app/themes/my-theme. Correcting this seems to have resolved some of the issues. I don’t know if this could be the same mistake any of you are making, but I thought it would be worth sharing.
TL;DR: Make sure your publicPath in resources/assets/config.json is correct.
Update: After doing a few tests the issue does persist for me when updating a Blade template (I should have read the question better). I’ve been living in JS for the last little bit, which is very quick to trigger BrowserSync/Webpack to refresh/rebuild.
Yeah I have noticed the same issue. Sometimes it takes 4/5 saves of the files in order to trigger the reload. I have tried with Chrome, Firefox and Firefox developer edition and no luck.
Javascript and css files trigger the reload perfectly!
I get these issues and they’re most of the time related to issues with using self-signed certificates on development. But I don’t have a great fix right now.
If you’re getting these problems, and you’re using a self-signed SSL certificate on Development
Make sure you’ve set your certificate settings to ‘Always Trust’ (view the cert in your browser, drag it to desktop, open in Keychain Access and set Trust Settings to ‘Always Trust’)
Check config.json is using "proxyUrl": "https://localhost:3000", by default it’s just http://
Add the line "headers": { "Access-Control-Allow-Origin": "*" }, to config.json as well… for good measure
With a virtual local development server (i.e. Trellis/Vagrant), Browsersync tends to be a bit quicker than Blade compiling + Vagrant’s file syncing. Updating the delay will offset the refresh to account for the syncing.
Thank you for the suggestion, I tried doubling the delay (setting it to 1000) with no apparent impact on browsersync reloading the page.
However, in previous Sage 9 projects, the page was reloading as expected upon saving a .blade.php or .php file. As of now, it injects or removes some lines of html, but this causes issues if I change anything beyond basic html.
For example, if I have @foreach loop in my blade.php, and I make a change, it will update the first item in the foreach loop, which can cause some very bizarre formatting until I manually refresh the page.
As a side note, I am using Laravel’s Valet for my local development environment, but that has been consistent since working on my first Sage 9 theme.
That’s really weird. Usually this issue is non-existent for me in Valet environments — in fact, I’ll use Valet to avoid it.
The difficulty with this issue, is that it isn’t just one issue, but the similar output leads people to think it is. This makes troubleshooting on the forum troublesome as I can see people in this thread describe symptoms of a few different issues.
I don’t know if it will help you, but here are my debugging steps for issues for this sort:
Make sure your development URL is identical to your WP canonical URL
The devUrl value is set in resources/assets/config.json. If you used the Sage installer it would have prompted you to set it.
Make sure the publicPath reflects your file structure
Again, in resources/assets/config.json, make sure publicPath is set correctly. If you are using Bedrock it should be something like: /app/themes/my-theme-name. If you are using a normal WP structure it should be something like: /wp-content/themes/my-theme-name.
Make sure proxyUrl is pointing to the correct Browsersync session
When running yarn start use the proxy URL
If you are running the watch script (yarn start) then you should not be using your development URL (example.test) to view changes. Webpack HMR — which rebuilds the CSS and JS assets — only runs on the proxied URL (localhost:3000). HMR rebuilds the assets and injects them without reloading the browser. You will notice that when it is running, there will be no compiled stylesheet in your dist folder. This is to be expected since the styles are being injected.
I’ve tried adding that to module.exports in webpack.config.watch.js with no luck, but perhaps I’m not adding it in the right location. Would you mind showing me your module.exports layout?
How did you initially set up the site with Valet? The WP-CLI valet command? Or just valet link? Maybe try valet unlink and then valet link to see if it’s an issue with Valet. Or valet restart. Even the output of valet which could be helpful for debugging (tells you which driver it’s using).
I used the standard valet link command. If it’s helpful, where I am working, the standard file structure for a wordpress project is [project-name]/public/[wordpress-install] I typically cd into the public directory, then run valet link [project-name].
So far as I can tell, this all seems to work properly. I can access the wp-admin and for the most part webpack behaves as expected, aside from not fully reloading the page.
When I run valet which I get the following output:
I was unable to replicate your issue following the same setup you described.
Can you expand on this? What is the “very bizarre formatting”? Could it be that your styles are expecting the markup to be different? I was unable to reproduce what you’ve described when testing a foreach loop and some simple styling (i.e. :first-child is a different color).
It varies depending on the specific situation, sometimes its as simple as the first item updating to reflect the html / php changes, while all other items do not. At other times, it will actually break my layout.
For example, if I change the bootstrap column class on one item, the others do not update, and the layout is no longer formatted properly.
I was able to consistently reproduce the issue. Very strange. I think it could be an issue with the bs-html-injector Browsersync plugin. I don’t think it was designed to work with Blade templates — let alone PHP. I will expand on this in a new topic or an issue when I find the time.
That would make sense, as just regular html in the blade templates does not seem to have an issue being injected, its mainly when it is mixed with php / blade directives.
I also wonder if there could be a dependency that has updated since the first release of Sage 9?
When I was working on the first couple of themes based on Sage 9, the page would reload after saving a .blade.php or .php file, and that behavior persists in those projects, but I am not sure what would happen if I deleted my node modules and re-ran yarn, since newer projects behave differently.
Let me know if there’s any more information I can give you, and thanks for the help in trying to diagnose the issue!
I’ve followed all of these and tried solutions on numerous other boards. They all (usually) work for a while and then quit working. I don’t have any other projects using webpack and hot reloading that have this issue. As much as I love using blade in my template and everything that Sage provides, I’m feeling like I can’t do anything but use a different starter template until these issues get addressed by the Roots team.
I’m currently watching my site reload constantly. I have to make a few changes, run yarn build, and then refresh, hoping there’s no error because the build fails without telling my why as its currently set up.