Browsersync not noticing php files

[GuiHarrison]

I’ve installed Sage for the second time now (first use of the theme) and I just can’t make BrowserSync notice any PHP files. My config.json looks like this:

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

I’m working on a Windows machine, Apache, php and mysql being handled by Ampps. I honestly don’t understand why the “publicPath” is “/wp-content/themes/theme-name” but I’ve seen this config online and this is the only variable that doesn’t make js saves loop reload for ever.

[josialoos]

I have the same problem, combined with Scss reloading problem, which I already described here:

Webpack sync is not working

I have the exact same Issue, this is my config.json: [08] I changed the name of my themefolder from “Roots Paradisepress” to “rootsparadisepress”, because I had an issue with the space in the directory name in wp-cli, when switching themes. my publicPath originally was: "publicPath": "\"/app/themes/Roots Paradisepress\"", → don’t understand the slash at the beginning of the path and the double quotation marks? Never seen anything like this … Changing the path to "publicPath": "/app/themes…

[josialoos]

This solved the problem for me:

XMLHttpRequest cannot load hot-update.json due to access control checks

Browsersync is running on port 3002 for you because something is already running on 3000 The proxyUrl isn’t currently able to detect when BS changes its port Can you kill whatever is running on port 3000 and try again? fkill is good for this: yarn global add fkill-cli fkill :3000 Then try running yarn start again and seeing if it loads your BS session at http://localhost:3000 instead of http://localhost:3002

For everyone having these or similar issues with browsersync and/or yarn not building/syncing Scss and Php Files, I would recommend this troubleshooting guide by @knowler:

Sage 9 browsersync not updating right

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 …

Thanks a lot to @ben and @knowler!

[GuiHarrison]

Thank you for your answer @josialoos! Unfortunately I’ve tried killing any :3000 process but there is nothing there to be killed.

Also:

• My devUrl is paired with WordPress URL;
• publicPath, as far as I’m aware, reflects file structure (however I don’t understand why start from wp root and not theme directory;
• I’m using proxy
• I’ve turned polling on and absolutely no message is displayed when php files are updated (scss and js works fine) and not errors while building
• browserSync delay is at 700

[josialoos]

I realized, that also having several browser tabs with localhost:3000 open is creating huge load time, so that some changes might not be printed.

As soon as I closed some of the tabs, the other ones startet loading the last changes, which before couldn’t be viewed.

So make sure to have only one tab with localhost:3000 open. (yarn will open a new :3000 tab every time you do yarn start)

@GuiHarrison what do you mean by “using proxy”?

[GuiHarrison]

Hmm that’s a good tip (however a bit worrisome because I like using different devices and browsers at once some times). But I did test having only one tab open.

By “using proxy” I meant using proxyUrl localhost:3000. In fact, what loads on the browser is always “localhost:3000/mysite”, no matter if I use ...:3000 or ...:3000/mysite at proxyUrl.

[josialoos]

Did you move or migrate your site? That sounds like a wrong site URL in the wordpress database …

I think having 3-4 tabs of :3000 open at a time might work aswell depending on your computer performance - especially, if they are opened on different devices, as browsersync is working client-side, not server-side I guess. Maybe the problem with webpack/browsersync is, that it is monitoring and compiling various files in the theme-directory, which can be quite much. If it then has to refresh multiple tabs on the same machine at a time and you might also have other software running in the background (e.g. adobe PS or Illu), that might result in memory overload.

[GuiHarrison]

Not really… fresh installation. It does sound like a URL mismatch, I agree. But I’m not aware of where is that mismatch happening. Also, why would scss and js work just fine and not php?
The one thing of note in the console is that it’s calling for a inexistent css file in a “dist” folder, which is weird. But the css is working fine!

[josialoos]

The one thing of note in the console is that it’s calling for a inexistent css file in a “dist” folder, which is weird.

If you are viewing the site on localhost:3000 the /dist-folder is not important, it is for the production-assets, which you produce with yarn build:production to be published to a remote server.

I don’t think that has anything to do with your problem.

But I think your devUrl and ProxyUrl in the config.json are wrong. They should be something like this:
“devUrl”: “example.test”,
“proxyUrl”: “http://localhost:3000”,

But don’t know if this is the reason why your php isn’t working.

publicPath looks good so far. its the relative path from the site folder to your theme folder.

[josialoos]

new idea @GuiHarrison: I just had this case here:

Scss file not affecting browsersync

After half an hour of headache I found out, that I uncommented the @import of my custom .scss-file in to the main.scss file. As soon as I removed the uncommenting, browsersync would work perfectly on again. Lesson learned: .scss files have to be @imported to the main.scss (or probably somewhere else like setup.php or so) in order to trigger browsersync.

I thought maybe something similar is causing your problem as well? Maybe your php-files aren’t correctly referenced or you edited the functions.php or some other major .php file, which now affects your problems?

And have you tried deleting the .cache-loader folder and manually refreshing your site then?

[GuiHarrison]

hmmm interesting! I’ll try that and get back to you.