The wrong file (with the same name) is reloaded on macOS

[graham73may]

Describe the bug

• If your CSS file is called style.min.css (in my case, a bunch of SCSS compiled down to style.min.css located at /wp-content/themes/testtheme/assets/css/style.min.css)
• AND your frontend also has another style.min.css that is being loaded from a different path (for example WordPress will likely add /wp-includes/css/dist/block-library/style.min.css)

Then the livereload.js fails to load the correct file... but only on macOS (and maybe Linux). Windows 10 is currently working.

To Reproduce
Repo: https://github.com/graham73may/livereload-debugging

This repo has a number of branches with a working and non-working example for both Gulp 3 and Gulp 4.

Start a local copy of the site, for this I'm using ddev.

1. ddev start, do the wp install etc.
2. cd wp-content/themes/twentytwenty/assets/src
3. npm install
4. Open PhpStorm
5. Right click wp-content/themes/twentytwenty/assets/src/gulpfile.js
6. Click Show tasks
7. In the Gulp tasks tool window, click watch, wait for it to finish starting up
8. ddev launch
9. Click the livereload chrome extension icon to connect the browser
10. Open a .scss file - wp-content/themes/twentytwenty/assets/src/scss/components/header.scss
11. Edit the background colour, it should update inside the browser without the need for a refresh

Expected Behaviour
The gulp task builds the CSS, causing a change to /wp-content/themes/testtheme/assets/css/style.min.css

The /wp-content/themes/testtheme/assets/css/style.min.css file is then re-loaded by livereload.

Actual Behaviour
The gulp task builds the CSS, causing a change to /wp-content/themes/testtheme/assets/css/style.min.css

The /wp-includes/css/dist/block-library/style.min.css file is then incorrectly re-loaded by livereload.

OS specific differences

macOS

I've been monitoring the livereload websocket and the network panel and on macOS which is where I noticed the incorrect file being loaded.

Here is the websocket message, getting notified about the correct path to the theme's CSS file.

But the style.min.css that is reloaded in the network panel to the left is the incorrect wp-includes file:
https://livereload-debugging-gulp3.ddev.site/wp-includes/css/dist/block-library/style.min.css?ver=5.4.2&livereload=1595454055654

• The websocket message has the correct path
• One file is reloaded
• The incorrect file is reloaded

Windows 10

Livereload is working for me on Windows 10, so what's different?

Watching the same project on Windows 10, under the same circumstances we get the same correct websocket message, showing the correct path the theme's updated CSS file:

But in the network panel on the left it has decided to reload:

• style.min.css from the theme (yay, this is what we needed!)
• print.css
• style.css from WordPress
• style.css from somewhere else

So it seems Windows is only "working" because it is basically reloading every CSS file.

• The websocket message has the correct path
• Multiple files are reloaded
• The correct file is reloaded (so livereload does appear to be working)
• Many incorrect files are reloaded

Final notes

I have been using this extension to enable the livereload.js client side script, but I'm 99% sure this is not using the latest version of livereload.js.

I have since removed the extension and I am loading the latest version of livereload.js manually but the issue still occurs. This can be found in branch gulp4-not-working-latest-livereload of my debugging repo above.

[graham73may]

Related / start of this rabbit hole:

ddev/ddev#2410

[smhg]

Thank you for the report @graham73may!

After scanning your description, it seems to (possibly) be 2 (unrelated) issues:

• Multiple stylesheets with the same filename are not reloaded correctly.
• On Windows, all stylesheets are reloaded.

Just to clarify: this repo (and its issues) are only for the livereload client. I can't help you with gulp/chrome/... other plugins.

But it seems these issues are related to the client anyway. I'll have a look at it.

[graham73may]

Hi @smhg,

Yes, your two bullet points are correct. Sorry, they felt related to me as I was comparing why the two OS's were behaving differently - but I think you're right, they are technically separate!

I believe the issue lies within this repo. I've tried the livereload-js that comes bundled within the chrome plugin and after that didn't work I tested installing this script/repo directly but the issue was still there.

Thanks!

[smhg]

First off all, the Windows issue seems to be completely expected as path matching happens based on forward slash (/). No matches means reloading all stylesheets (there is the reloadMissingCSS option to disable this, but that's not what you'd want in this case).

Focussing on the multiple stylesheet issue, I've added some tests for the path matching part (this repo never had many tests). It seems to work as you'd expect though.

@graham73may could you list the full URLs both stylesheets have inside your html source? That might help explain things.

[graham73may]

Hi @smhg,

Ok so Windows is a "best it can get" situation, that's fine. Essentially the reload functionality does feel like it is working.

macOS - Sure, let me add a bit more. I'm currently in the gulp4-not-working-latest-livereload branch. (Gulp 4 + not using the Chrome extension to add the livereload.js script).

1. Watch task is run
2. Edit a file, watch task triggers a scss rebuild, pertinent part of the output below (debug info enabled)

2020-07-28T06:45:15.343Z gulp-sourcemaps:utils commentFormatter bound cssCommentFormatter
2020-07-28T06:45:15.343Z gulp-sourcemaps:write:internals:mapDestPath destPath comment
2020-07-28T06:45:15.346Z tinylr:server Changed event (Files: /Users/graham/sites/livereload-debugging/wp-content/themes/twentytwenty/assets/css/style.min.css)
2020-07-28T06:45:15.346Z tinylr:server Reloading client ws0 (url: https://livereload-debugging.ddev.site/)
[07:45:15] /Users/graham/sites/livereload-debugging/wp-content/themes/twentytwenty/assets/css/style.min.css reloaded.
[07:45:15] Finished '<anonymous>' after 28 ms
[07:45:15] Finished 'build-css' after 28 ms

In the browser, this then triggers a websocket message with these details (correct CSS file):

{
  "command": "reload",
  "path": "/Users/graham/sites/livereload-debugging/wp-content/themes/twentytwenty/assets/css/style.min.css",
  "liveCSS": true,
  "reloadMissingCSS": true,
  "liveImg": true
}

Watching the behaviour of the network tab in Chrome, I can see that the CSS file it has actually reloaded is:
https://livereload-debugging.ddev.site/wp-includes/css/dist/block-library/style.min.css?ver=5.4.2&livereload=1595918967900

So I guess we're looking at

/wp-content/themes/twentytwenty/assets/css/style.min.css
v.s.
/wp-includes/css/dist/block-library/style.min.css

Is that enough information?

[smhg]

I meant the URL inside the HTML source, because the livereload client parses those out and compares it to paths in reload events that come in over the websocket. I am assuming that comparison results in the wrong match.

I'm not experienced enough with ddev/wordpress/gulp/... to set it up myself, but if you could list those URLs I'll have a look at what exactly happens on that reload event.

[smhg]

Or, if possible, please paste the entire HTML source of the page on which the reload event is incorrectly handled. Thank you!

[graham73may]

Hi @smhg

Oh sorry, I misunderstood. HTML source before and after attached. Wrong CSS file has the livereload _GET variable.
before-and-after.zip

<link rel="stylesheet" id="wp-block-library-css" href="https://livereload-debugging.ddev.site/wp-includes/css/dist/block-library/style.min.css?ver=5.4.2&amp;livereload=1595923147835" media="all">
<link rel="stylesheet" id="twentytwenty-style-css" href="https://livereload-debugging.ddev.site/wp-content/themes/twentytwenty/style.css?ver=1.2" media="all">

---

The steps in "To Reproduce" of my original issue would get you up and running with everything you need. Instead of using PhpStorm to start the watcher you could run the script without installing it globally with the below commands:

cd wp-content/themes/twentytwenty/assets/src/node_modules/gulp/bin
node gulp.js watch

[smhg]

Both the pathname and the filename are different in your HTML source:

/wp-content/themes/twentytwenty/style.css?ver=1.2

The reload event sends:

/wp-content/themes/twentytwenty/assets/css/style.min.css

There is a partial match however with the first stylesheet (only by filename), so that's reloaded. Although it is an unfortunate combination, it seems to make sense.

Why both paths are different is out of the scope of this repo, so I'm going to close this issue. Feel free to leave additional feedback though.

[graham73may]

Sorry, I don't believe this is ready to be closed.

The reload event is sending the correct information. My snippet above wasn't all the .css files, that was just me highlighting the problem css file being appended with the livereload _GET variable.

Looking at all the .css called style in the HTML files we have:

<link rel="stylesheet" id="wp-block-library-css" href="https://livereload-debugging.ddev.site/wp-includes/css/dist/block-library/style.min.css?ver=5.4.2&amp;livereload=1595923147835" media="all">

<link rel="stylesheet" id="twentytwenty-style-css" href="https://livereload-debugging.ddev.site/wp-content/themes/twentytwenty/style.css?ver=1.2" media="all">

<link rel="stylesheet" id="twentytwenty-sbx-style-css" href="https://livereload-debugging.ddev.site/wp-content/themes/twentytwenty/assets/css/style.css?ver=1.2" media="all">

So:

• /wp-includes/css/dist/block-library/style.min.css (WP Core)
• /wp-content/themes/twentytwenty/style.css (WP Theme info style sheet, bit of a pointless one)
• /wp-content/themes/twentytwenty/assets/css/style.css (The theme's styles)

So it is still selecting the incorrect /wp-includes/css/dist/block-library/style.min.css WP core file to refresh.

[graham73may]

Ok spotted the inconsistency you mention. (This repo is just something I threw together quickly for this issue report, sorry).

I've changed the page to use the minified version, so the linked stylesheet is style.min.css and it is working correctly on macOS.

I guess the issue in that case is two-fold, and I'm happy to say, not related to this repo!

• my gulp watch task only triggering on the style.min.css and not both the style.css and style.min.css (they both changed, so it should trigger both right?)
• the repo was using style.css but the reload was only on style.min.css
• this was never a problem for me before because Windows was reloading all the CSS files

Thank you for helping spot why my workflow was not working when I moved it from Windows to Mac!

[smhg]

It might be worth to switch to another livereload server if possible. Many projects in the livereload ecosystem (including livereload itself) seem to have some maintenance issues. Gulp-livereload is for instance still using an older client.
I use livereload myself, but there are others.

Related to the Windows workflow: this should definitely improve. I'll open a separate issue for this.

[graham73may]

Thanks for the recommendation, I'll try and connect it up with my build process at the next opportunity. :-)

[smhg]

I've released version 3.3.0 which should fix the Windows path issue. Would you be able to test this?

You can overwrite your client with this version:
https://raw.githubusercontent.com/livereload/livereload-js/v3.3.0/dist/livereload.js

The result should be that on Windows you also get only a single CSS reload.

[graham73may]

Just tested with 3.3.1 on Windows 10 and it is only reloading one, correct CSS file.

Thank you! 🙏

[smhg]

Awesome! Thank you for testing @graham73may!