Local Community

Instant reload not reloading

Hi there,

The plugin is registering changes in CSS, but not reloading. The green “Local reload enabled” tag also pops up in my browser, but I still need to manually refresh for anything to happen.

I do use WP-SCSS, but that compiles into a .css which Local is properly identifying for changes. So I doubt that would have an effect?

Just noticed console gives an error as well:

“browser-sync-client.js?v=2.26.9:18 WebSocket connection to … failed”

Seems to fail on this line:

this.ws = this.usingBrowserWebSocket && !this.isReactNative ? e ? new p(t,e) : new p(t) : new p(t,e,r)

Similar issue. Adding a comment here because I’d like to see if the solution fixes my issue as well.

Error message:

WebSocket connection to 'wss://motus-labs.local/browser-sync/socket.io/?EIO=3&transport=websocket&sid=jBhxTzlwbYxZ28xvAAAJ' failed: 

I’ve reinstalled the Instant Reload addon with no effect

1 Like

Same problem here.

The green ‘Instant reload enabled’ appears in the browser. The Instant Reload session log detects changes fine - but the browser does not refresh.

Same issue on my end.
WebSocket connection to ‘wss://telappliant.local/browser-sync/socket.io/?EIO=3&transport=websocket&sid=zNYjBC04iO5ApI2yAAAA’ failed:

I’m trying to replicate and having trouble seeing that same error. Here are my specs:

  • MacOS BigSur 11.4 (intel hardware)
  • Local 6.0
  • Instant Reload add-on 1.0.1 (installed from within Local’s add-on tab)
  • Web Browser is a recent version of Chrome (91.0.4472.114)
  • QA on a new test site: Preferred environment (php 7.3.5, and nginx) using twentytwentyone theme, editing the style.css file.

Since you all are seeing similar errors, there definitely seems like an issue. Can you all describe in a little more detail your environment?

  • Does disabling browser-sync for the site and then re-enabling it clear out the error?
  • Are you using nginx for the site?
  • What browser are you working with?
  • For the CSS file that’s being edited, are you editing the file directly, or are you doing some sort of pre-processing like compiling Sass?
  • Random thought – how “large” is the site being worked on? More specifically, how many files is browsersync watching? I’m not 100% sure how to get that value right this second, but maybe note how many plugins and themes are installed on the site you’re working on.

Hi, Ben;

Just set up a completely fresh site to see if it would happen for me with a base installation of WordPress. It seemed to work with the same settings that you used, and then it started working on all my other sites, so I guess my problem is solved.

Great work. :+1:

Welp. I’m glad it’s working! But I also hate these bugs that disappear without us knowing why!

Either way, if you see it again, I’d love to know more about what’s going on and make sure that this addon becomes more resilient!

Ben, hopefully this helps a bit!

In terms of replicating this, I’m essentially using the same setup here:

  • MacOS BigSur 11.4 (intel hardware): I’m running macOS 10.15.7
  • Local 6.0: Same
  • Instant Reload add-on 1.0.1 (installed from within Local’s add-on tab): Same
  • Web Browser is a recent version of Chrome (91.0.4472.114): Same
  • QA on a new test site: Preferred environment (php 7.3.5, and nginx) using twentytwentyone theme, editing the style.css file. See below

More details:

  • Does disabling browser-sync for the site and then re-enabling it clear out the error? No
  • Are you using nginx for the site? Yes
  • What browser are you working with? Chrome
  • For the CSS file that’s being edited, are you editing the file directly, or are you doing some sort of pre-processing like compiling Sass? Sass (using gulp to compile it; have done this lots in the past, though). There are three stylesheets being compiled when I save a file.
  • Random thought – how “large” is the site being worked on? More specifically, how many files is browsersync watching? I’m not 100% sure how to get that value right this second, but maybe note how many plugins and themes are installed on the site you’re working on. Great question; I’ve been editing some relatively larger sites, but testing with a default test site actually DOES work fine. The style.css file on this site is essentially empty. The main stylesheet I load is about 5400 lines (so a bit smaller than twentytwentyone), not including the sourcemap (which is on one line but quite lengthy). The site has 35 plugins, though most of them are small plugins or plugins which don’t load anything on the frontend.

I did some further testing, actually, and here’s what I found:

  • On a sample site, Instant Reload works consistently. Please note that the error noted above DOES display in the console despite it working properly.
  • On a site where it wasn’t working, edits to the style.css file work, but inconsistently.
  • On a site where it wasn’t working, edits to the main sass file work, but inconsistently.
  • On a site where it wasn’t working, edits to a sass file that’s compiling but is not the main one (something that’s included via @import) do not work (I’ve seen it work a couple of times).
  • In most cases, including some where the browser is not reloading, the changes are detected. However, when I edit an imported file, changes sometimes aren’t actually detected at all.
1 Like

I should also mention that when this started, there was a separate error in Local where none of the addons were being recognized; Local wouldn’t let me install them because files were there. I corrected this by deleting each of their folders and they reinstalled correctly and now, other than this behavior with instant reload, those appear to be working properly.

Some of what you’re describing makes me wonder there’s something going on between Gulp and Browsersync.

I know that Gulp 4 has some pretty major changes and on at least one project I was working on, Gulp 3 was having issues with… everything :smiley:

It might be worth investigating an update to gulp 4, but that might be too much effort if this is the only issue you’re facing.


You mentioned that the site that you were having issues on had ~45 plugins. That seems like a lot, but I’ve been in those kinds of projects. I wanted to get some hard numbers, so I compared a new, blank site against a site that has 60 plugins.

I basically took the first 3 pages of “block-compatible plugins” and installed them within a new site:

wp plugin install wordpress-seo jetpack wpforms-lite tinymce-advanced mailchimp-for-wp wp-smushit instagram-feed redux-framework ninja-forms seo-by-rank-math the-events-calendar shortcodes-ultimate smart-slider-3 ml-slider nextgen-gallery amp coblocks themeisle-companion formidable ultimate-addons-for-gutenberg photo-gallery contact-widgets mailpoet popup-builder caldera-forms youtube-embed-plus woo-gutenberg-products-block leadin foogallery complianz-gdpr custom-facebook-feed olympus-google-fonts forminator wp-seopress envira-gallery-lite kadence-blocks yikes-inc-easy-mailchimp-extender custom-twitter-feeds give layout-grid otter-blocks wordpress-popup form-maker luckywp-table-of-contents soliloquy-lite booking wd-instagram-feed calculated-fields-form metronet-profile-picture wp-recipe-maker feedzy-rss-feeds gutentor advanced-responsive-video-embedder robo-gallery slider-wd visualizer atomic-blocks event-tickets getwid stripe-payments --activate

After doing that, I did notice that instant reload felt sluggish, though I still was able to get the styles to reload. I think the sluggisness is likely due to there being so many CSS files that Instant Reload is watching:

Default site:

  ★  app/public % find wp-content -type f | wc -l
  348
  ★  app/public % du -sh wp-content
  7.4M	wp-content
  ★  app/public % find wp-content -name '*.css' | wc -l
    22

Site with lots of plugins:

  ★  app/public % find wp-content -type f | wc -l
  38993
  ★  app/public % du -sh wp-content
  675M	wp-content
  ★  app/public % find wp-content -name '*.css' | wc -l
  2277

After fiddling around a bit more I did get the styles to not refresh by creating a child theme:

wp scaffold child-theme irqa --parent_theme='twentytwentyone' --activate

The only caveat is that restarting the site (or maybe restarting Local?) got everything wired up again.

All that’s to say that something about this feels like a race condition or in some way a limitation on the resources that BrowserSync has available to it.

I’m using Gulp 4.

This site definitely isn’t the most complex or largest that I’ve worked on in the recent past, and it’s worked flawlessly for a long time. I also have multiple plugins installed on most sites I build that also use gulp for compiling their stylesheets, so I’d actually be a bit surprised if this was a size/number of stylesheets thing.

On a whim, I tried editing one of those plugins’ stylesheets, and live reload is actually working fine with that. I then went back to the theme stylesheet, which is still not working with instant reload. I tried deleting the .css file and the sourcemap, and it actually did instant reload on the next save – just once, and then it was broken again. Could the issue be the complexity of the stylesheet or some specific thing to do with the specific stylesheet that’s being instant reloaded?

Whether it’s working or not, I’m always seeing the websocket connection error in the console, so I’m not sure that’s actually the reason it’s broken; I might have only noticed that as a result of instant reload not working.

If you can think of anything else to try, I’d love to hear it! In the meantime, I’ll watch for when it’s working vs when it’s not, and see if I can come up with any other areas of commonality.

A few questions (just trying to think of other things to eliminate):

  • Does it matter for instant reload if there are multiple sites running that also are using instant reload?
  • Are there known conflicts with any Chrome addons?
  • Could SSL issues explain some of this if a site was loading with SSL partially broken?
1 Like

Oh, and here’s the output from the CLI commands you were running; not as bad as your test install with 60 plugins, but tracking (still!) 513 stylesheets:

jonschroeder@MacBook-Pro public % find wp-content -type f | wc -l 
30888

jonschroeder@MacBook-Pro public % du -sh wp-content 
1012M	wp-content

jonschroeder@MacBook-Pro public % find wp-content -name '*.css' | wc -l 
513

When you’d used scaffolding to create a child theme, I think you probably were able to break it due to something similar to the last time that I had an issue, actually; there was an problem where plugin updates while instant reload was active was causing the site to 504 error, but restarting it would fix it.

https://localwp.com/community/t/504-gateway-timeout/22387/10

Something about the number of files changing rapidly. Respectfully, I think that’s likely a different issue than this one, since we’re not talking here about many files changing at once (and plugin updates work fine for me now; thanks!)

1 Like

I think you’re right that this was an error that’s always showing. I’m seeing it in my browser console even when reloading works.

That’s a good idea. I wouldn’t think that it matters, but maybe.

I haven’t heard of anything. Do the styles refresh reliably in a blank chrome window, or even a different browser like Firefox?

I suppose maybe, but it seems like if those styles show up after manually refreshing the browser, then SSL likely isn’t the issue.

I’ll look into these items. I just had instant reload work (albeit slowly) yesterday on another site.

Ben – thanks for taking the time to try to narrow down the issue on this.

1 Like

Same issue here, instant reload addon doesn’t work.

My project define custom wp-content folder in wp-config.php
define (‘WP_CONTENT_FOLDERNAME’, ‘content’);

After change “content” back to “wp-content” instant reload is working.

Looks like the addon only watch “wp-content”. Could you update the addon so that it can read the actual content folder defined in “wp-config.php”? Or best of all could the addon provide options to define folder to watch by project.

Thanks a ton!

Welcome the forums @laokun !

This seems like a slightly different issue than what redblue was encountering, but these are great suggestions!

Can you create an issue on the Add-on’s Github repo so that the community can start chipping away at it?