Chrome Devtools Workspaces mapping no longer working

Question

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:

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:

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.

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.

Answer 1

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.