Sage 9 browsersync not updating right

sage
, ,
1

A problem is starting to appear and it seams that it is getting worst.
After I make some changes in my blade.php (html content) file the browsersync don’t update. I have to hit save several times (sometimes more than 5) in order tos see some changes.
Any thoughts about this?

4 Likes
2

Bump.

I also get this regularly. Whatever cache-busting it’s supposed to be doing with each file save, doesn’t work. Tried multiple browsers.

2 Likes
3

Bump. I am also seeing this issue in my project and have not found a solution. (I will go to the GitHub repo as well but I’m commenting here first because a Google search brings this up as the first result.)

1 Like
4

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.

4 Likes
5

Bump.

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!

2 Likes
6

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

  1. 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’)
  2. Check config.json is using "proxyUrl": "https://localhost:3000", by default it’s just http://
  3. Add the line "headers": { "Access-Control-Allow-Origin": "*" }, to config.json as well… for good measure :smiley:
2 Likes
7

any updates on this issue?
also sometimes things are not compiled to the dist folder

8

Bump.

This started happening to me as well. For me, template files will not refresh period.

9

Try increasing the Browsersync delay value:

(h/t @ben)

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.

10

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.

1 Like
11

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.

You may also notice a MIME type ('text/html') error in the console as well. This too is to be expected since the stylesheet doesn’t exist. It can be ignored.

Workflow-wise I would recommend using the WP dashboard at the devUrl and the proxyUrl to see theme changes.

Turn on polling in Webpack’s devServer.watchOptions

https://discourse.roots.io/t/sage-9-browsersync-not-updating-right/10648/12?u=knowler

https://discourse.roots.io/t/sage-9-browsersync-not-updating-right/10648/15?u=knowler

Bump the Browsersync delay

See above:

https://discourse.roots.io/t/sage-9-browsersync-not-updating-right/10648/9?u=knowler

Try reinstalling the Composer dependencies or dumping autoload

If things still aren’t working, maybe try either of the following:

  • Dump the autoload: composer dump-autoload.

Or

  • Delete vendor.
  • Clear composer’s cache composer clear-cache.
  • (Re)install the composer dependencies: composer install.
4 Likes
12

I was running into a similar problem, and adding the following lines to module.exports in webpack.config.watch.js solved it:

    devServer: {
        watchOptions: {
            poll: true,
        },
    },

In my case, I believe the issue had to do with my OS’s ability to watch multiple files for changes in the way Webpack/BrowserSync wanted by default.

5 Likes
13

I’ve followed those debugging steps, but unfortunately I’m still getting the same behavior.

1 Like
14

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?

15 
module.exports = {
    devServer: {
        watchOptions: {
            poll: true,
        },
    },
    output: {
        pathinfo: true,
        publicPath: config.proxyUrl + config.publicPath,
    },
    devtool: `#cheap-module-source-map`,
    stats: false,
    plugins: [
        new webpack.optimize.OccurrenceOrderPlugin(),
        new webpack.HotModuleReplacementPlugin(),
        new webpack.NoEmitOnErrorsPlugin(),
        new BrowserSyncPlugin({
            target,
            open: config.open,
            proxyUrl: config.proxyUrl,
            watch: config.watch,
            delay: 700,
        }),
    ],
};
2 Likes
16

Much appreciated. Still no luck though unfortunately :confused:

1 Like
17

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).

18

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:

This site is served by [BasicValetDriver].

19

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).

20

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.

1 Like