Chrome Devtools Workspaces mapping no longer working
Asked Answered
S

2

5

This used to work a charm, and I've set up probably a dozen times in the past, using the same hardware / software, but now it fails:

After an attempted edit in the live styles editor, or directly in this tab in the sources panel

The necessary permissions to edit are in place, because I can edit the file within Devtools, if I open it directly from the local workspace in the sources tab, edit and save it, but this of course is no better than using any other IDE, since I can't see and immediately persist my changes like I used to:

enter image description here

No LESS / SASS / Taskrunner cleverness here, just plain CSS files.

I've looked at Sawbuck, Devtools on Devtools, and see no errors.

I've completely disabled the firewall.

I'm using Windows 7, Chrome 56 (and tried Canary, 58, too), and the server's file system is mounted as a network drive, on Z:.

The one slightly odd thing is how the workspace mapping seems to treat the files as directories after I establish the link of a resource, by either right clicking the remote resource and choosing "Map to file system resource..." or a local resource and choosing "Map to network resource...", but this may always have been the case, and I never noticed- in any case, I've also manually added a mapping of the parent directory, and the site's root directory, but the outcome is the same; no persistent edits.

enter image description here

I'm usually too proud to ask a question about something like this, and spend ages trying to figure it out on my own, but I feel like I'm hitting a brick wall for too long now. I'd be grateful for any pointers, if you've had a similar experience.

Silicon answered 18/2, 2017 at 9:52 Comment(2)
Could be a bug fixed in the latest chrome canary several hours ago.Prophecy
Unfortunately not, that's to do with source maps, and not doing any of that stuff here! Thank you though! Source maps may in fact be the answer to this problem though...Silicon
S
6

It seems to be down to the cache-busting query string which WordPress adds-

You can see it in my screenshot: ?ver=4.7.2

clearly I must have only used this DevTools Workspace feature before integration into Wordpress. Here is a relevant Chromium bug report.

For now, adding this to functions.php in WordPress in order to remove the cache-busting suffix allows me re-enable persistent edits:

function fj_remove_version( $url ) {
    return remove_query_arg( 'ver', $url );
}

add_filter( 'style_loader_src', 'fj_remove_version' );

In future, it looks like Persistence 2.0, recommended at the end of the bug report, will be the solution. It can be enabled as a Chrome DevTool experiment now.

Silicon answered 1/3, 2017 at 21:27 Comment(3)
I am seeing the same problem but have not control over the server side of things. Does anyone know if there is a solution to this problem?Priapus
I found that Chrome automatic mapping to workspace is considering (1) the file name, (2) file content, (3) the last modification date (header field "Last-Modified"). Make sure that all these are in sync with the resource that is served to the website.Estren
@Estren Your comment fixed things for me. I had been pulling my hair out for half a day.Ethiopic
G
0

It's really important that Chrome sees remote and local file in same folder, same name, same size and most importantly same date modified value.

If webserver/website is putting "?ver=xyz" besides css and other files, that's ok, this doesn't matter.

If you're uploading files with FTP (also within your IDE), it will change the date-modified value, so this wont' work. To fix this, use winSCP "keep remote directory up to date" function and upload files in binary mode.

If it still doesn't work, check in Chrome "Date-modified" headers for file retrieved from webserver and file opened from your local system. These should match.

If your webserver is constantly changing "date-modified" header to current datetime, it means that modified value on server is in the future, probably because of daylight-saving time and wrong server or winscp (or other syncing app) configuration, and apache probably cannot provide "modified-date" header in the future. You can fix this by setting this correctly in WinSCP under advanced session settings.

winscp session settings

Gregoriogregorius answered 5/4, 2023 at 16:59 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.