Sage 9 browsersync not updating right

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

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

Bump.

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

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.

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

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

Bump the Browsersync delay

See above:

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

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

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

1 Like

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?

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

Much appreciated. Still no luck though unfortunately :confused:

1 Like

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:

This site is served by [BasicValetDriver].

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.

1 Like

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.

5 Likes

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!

1 Like

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.

1 Like

Can you please be more specific?

Starting off by sharing your config, and whatever else you’ve modified to try and fix your problem, would be a good start to solving the issues you’re running into

This should be a simple configuration issue

1 Like

Ben, here’s the webpack.config.watch.js file I’m working with:

const url = require('url');
const webpack = require('webpack');
const BrowserSyncPlugin = require('browsersync-webpack-plugin');

const config = require('./config');

const target = process.env.DEVURL || config.devUrl;

/**
 * We do this to enable injection over SSL.
 */
if (url.parse(target).protocol === 'https:') {
  process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0;

  config.proxyUrl = config.proxyUrl.replace('http:', 'https:');
}

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: 1500,
    }),
  ],
};

It’s hard to troubleshoot because it’s hard to know what fixes things and what doesn’t. I’ve had sporadic luck by temporarily moving my views folder out of the structure, hard reloading so it stops the the auto reload, and then moving it back in. It works sometimes, other times it just keeps cycling through the page refreshses on-end.

I’ve also dumped my composer files and redone that based on the suggestion here but it didn’t change anything.

FWIW, I had this same issue at a previous job on a different Macbook Pro, but most of our sites were built with Sage 8 so it wasn’t as big of a deal when a site got stuck in a reload loop.

I use Flyhweel’s Local to run it on my machine.

Also, here’s my config file:

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