Bedrock + Valet = Broken media-views.js Response from Local Server

[AndrewM]

I’ve run into an interesting hiccup, and I =think= I’ve isolated it to Bedrock.

ENVIRONMENT

• MacOS running Valet 2.3.3 / nginx/1.17.2, PHP 7.2.21 / WordPress 5.2.2
• Out-of-the-box-nothing-added-yet Bedrock install via composer

WHAT HAPPENS

• When I go to the Customize view (/wp/wp-admin/customize.php), media-views.js refuses to load in the page. I see “net::ERR_SPDY_PROTOCOL_ERROR 200” in the console for the media-views.js file request and subsequent “Uncaught TypeError: … of null” messages.
• Request URL: https://devsite.ffs/wp/wp-includes/js/media-views.js?ver=5.2.2
• Nginx log at ~/.config/valet/Logs shows the following (reformatted for legibility):

2019/08/28 11:19:13 [alert] 
260#0: *3 zero size buf in writer t:1 r:1 f:0 
00007FE53980A800 00007FE53980A800-00007FE53980A800 
0000000000000000 0-0 while sending response to client, 
client: 127.0.0.1, 
server: devsite.ffs, 
request: "GET /wp/wp-includes/js/media-views.js?ver=5.2.2 HTTP/2.0", 
upstream: "fastcgi://unix:/Users/username/.config/valet/valet.sock", 
host: "devsite.ffs", 
referrer: "https://devsite.ffs/wp/wp-admin/customize.php?return=%2Fwp%2Fwp-admin%2F"

WHAT I’VE TRIED

• “valet which” returns “This site is served by [BedrockValetDriver]” if I link my site at the root level. It returns [WordpressValetDriver] if I link my site from its /web folder.
• I’ve tried installing a similar out-of-the-box-nothing-added-yet Wordpress setup using the old-school method of “wp core download”, etc and don’t experience the same error. It shows [WordpressValetDriver] as well.
• I’ve read online that this JS particular file can be problematic if you have an ad blocker or virus scanner running. I’ve disabled all of that and have tried in Chrome and Firefox.

Any idea whether this is a bug or if it’s something I’ve configured incorrectly?

[mensch]

It’s indeed a issue with Bedrock and Valet, I see these errors in the console and Valet log too. The problem is that Bedrock makes WordPress load the full JavaScript files instead of the minified ones during development and Valet’s nginx configuration can’t handle the size of one of those files.

A bug has been filed at the WordPress bug tracker, but I’m not sure they’re going to fix it on their end. On the other hand, it didn’t error in previous releases, as far as I know.

There’s a workaround listed in that issue thread. I’ve added this block of code in filters.php of my themes for the time being:

if (getenv('WP_ENV') === 'development') {
    /**
     * Quickfix loading of large JavaScript library
     * @return string
     */
    add_filter( 'script_loader_src', function ($src, $handle) {
        if (false !== stripos($handle, 'media-views')) {
            $src = str_replace('media-views.js', 'media-views.min.js', $src);
        }
        return $src;
    }, 10, 2);
}

[mensch]

Some follow-up on this. The issue cropped up again with another large library (from the Ultimate Member plugin) and so the filter workaround doesn’t seem to be sustainable in the long run.

Searching for the issue on Valet’s issue tracker turned up this report. The issue is apparently caused by a bug in nginx 1.17.2+, Homebrew currently ships 1.17.3. There’s a patch available, but I’m not sure it has been merged yet.

In the mean time, disabling gzip in /usr/local/etc/nginx/nginx.conf and restarting Valet seems to take care of the issue temporarily. I can confirm this works.