What issue or error are you experiencing?
On Mac, after upgrading from Local with Atlas add-on “getting started” to Nextjs v14 and Faustjs v3, Nextjs is throwing a websocket error. Research shows that it is possible that either the Local nginx config set of files or next.config.js may need an adjustment. After trying several variations of site.conf.hbs location without success, I thought I would reach out here.
When I type localhost:10023 directly into the browser instead of my-site.local, the websocket error does not appear. Instead, I get “HMR connected” in the browser console and:
GET http://localhost:10023/favicon.ico 404 (Not Found)
I have also tried various nextjs config changes so that my-site.local will hopefully work but with no luck:
// async rewrites() {
// return [
// {
// source: "/:path*",
// destination: "http://au-all-local.local/:path*",
// },
// ];
// },
// webpack: (config, { isServer }) => {
// if (!isServer) {
// config.module.rules.push({
// test: /\.css$/,
// use: ["style-loader", "css-loader"],
// });
// }
// return config;
// },
// webpack: (config, { dev }) => {
// if (dev) {
// config.devServer.hot = false;
// }
// return config;
// },
Here’s what I tried adding to site.conf.hbs:
# Proxy to Next.js dev server on port 10023
location / {
proxy_pass http://localhost:10023;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# Handle WebSocket connections for HMR
location /_next/webpack-hmr {
proxy_pass http://localhost:10023/_next/webpack-hmr;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 60s;
proxy_send_timeout 60s;
}
…and to site.conf.hbs, I tried adding:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
…which unfortunately crashes WP and causes a 500 status code.
What steps can be taken to replicate the issue? Feel free to include screenshots, videos, etc
This is the contents of my package.json
"dependencies": {
"@apollo/client": "^3.10.3",
"@faustwp/cli": "^3.0.1",
"@faustwp/core": "^3.0.1",
"@fortawesome/fontawesome-free": "^6.5.2",
"@fortawesome/fontawesome-svg-core": "^6.5.2",
"@fortawesome/free-brands-svg-icons": "^6.5.2",
"@fortawesome/free-regular-svg-icons": "^6.5.2",
"@fortawesome/free-solid-svg-icons": "^6.5.2",
"@fortawesome/react-fontawesome": "^0.2.0",
"@wordpress/base-styles": "^4.48.0",
"@wordpress/block-library": "^8.34.0",
"classnames": "^2.5.1",
"graphql": "^16.8.1",
"next": "^14.2.3",
"react": "^18.3.1",
"react-dom": "^18.3.1",
"sass": "^1.77.0"
},
"devDependencies": {
"next-secure-headers": "^2.2.0"
},
"engines": {
"node": ">=18",
"npm": ">=8"
}
System Details
-
Local Version: 9.0.2+6676
-
Atlas add-on Version: 1.7.3
-
Operating System (OS) and OS version: Mac OS Ventura 13.6.1
Local Logs
Attach your Local Logs here (Help Doc - Retrieving Local’s Log)
local-lightning.log (767.2 KB)
local-lightning-verbose.log (891.8 KB)
Security Reminder
Local does a pretty good job of scrubbing private info from the logs and the errors it produces, however there’s always the possibility that something private can come through. Because these are public forums, always review the screenshots you are sharing to make sure there isn’t private info like passwords being displayed.