Instant reload not detecting file changes in directory junction

Local Add-ons Instant Reload
,
1

Ahoi,

I have an issue with instant reload.
Im running Local 6.1.5 on Windows 10. the site folder is located on another drive (not c:, I just mention this because of the apache "no input file specified bug). In the wp-content/themes folder i created a directory junction pointing to another directory on the same drive but outside the local folder for that site.
Instant Reload is not detecting changes when I edit a css file. When I edit a css file for another theme it works.
Is this a limitation by Instant Reload?

2

Welcome to the forums @justbj

I could see Instant Reload might have issues with a Windows junction.

Under the hood, Instant Reload is using Browser-Sync – so as a test, I suppose you could try installing browser-sync and see if that works. That would narrow down if it’s the Instant Reload add-on or something more fundamental.

To test this, you’ll need npm installed on you system, and then within a terminal, navigate to your theme and issue the following commands to install browser-sync and start that process. Be sure to update the proxy url to the url used by the Local site:

cd <path-to-theme>
npm install -g browser-sync
browser-sync start --proxy 'example.local' --files '*.css'

For more help, see the docs of Browser-sync:

3

I tested as you suggested.
Browsersync was successfully detecting file changes allthough the injection of css changes was not working (but this might be related to other problems). A page reload was triggered correctly when editing .php files.

I started browsersync in the d:\wordpress\wp-content\themes\my-theme folder (which acts as a junction to eg. d:\my-theme) as well as in d:\my-theme (filepaths are examples but reflect my actual setup).

Both times filechanges where detected. Instant Reload does not detect any filechanges.
Any more ideas?

4

Meanwhile I figured out why the injection of my previos test was not working:

Browsersync was replacing the wrong css file. The Wordpress installation has several plugins which seem to use the same filename for their css file (allthough of course tha path differs) as my theme does. Browsersync seems to just replace the first occurence of the filename it finds.

Still the problem persists, that instant reload seems to not be detecting any filechanges at all (as of the log in the local ui).

5

Whoah, I’ve never encountered that, but thanks for sharing that info!

Since it seems like this might be an issue with the Add-on itself and the code is open-source, can you create an issue on the repo so that we can start tracking the progress of this issue?