Fix wp-env Could not find current WordPress version on Windows

by

Summary

A developer encountered a persistent failure when attempting to initialize a local development environment using wp-env. The tool threw a fatal error: “Could not find the current WordPress version in the cache and the network is not available.” Despite the developer having active internet access and successfully pinging networks via Docker, the tool could not bridge the gap between the host machine’s network state and the internal logic required to fetch WordPress core metadata.

Root Cause

The failure stems from a network resolution mismatch between the Node.js runtime environment and the underlying Docker abstraction layer. Specifically:

  • DNS/Proxy Discrepancies: The Node.js process running wp-env on the Windows host was unable to resolve external WordPress API endpoints, likely due to corporate proxy settings, VPN interference, or Windows Firewall rules blocking the specific Node.js binary.
  • Cache Invalidation Failure: The tool relies on a local cache of WordPress versions. Because the cache was empty or corrupt, the tool attempted a network fallback.
  • Environment Isolation: Even though the user confirmed “network access” by pinging through Docker, wp-env performs its initial version check on the host machine via Node.js before it successfully orchestrates the Docker containers. If the host’s Node process is blocked, the containers never even reach the stage of being able to use the network.

Why This Happens in Real Systems

In production-grade environments, “it works on my machine” failures usually occur due to environmental drift:

  • Implicit Dependencies: Software often assumes a “transparent” network, ignoring the reality of Layer 7 firewalls, Zscaler/Proxy interceptors, or MTU mismatches in virtualized network interfaces.
  • Host vs. Container Context: Engineers often confuse “The Docker network is up” with “The Host process can reach the internet.” In this case, the dependency check happens in the Host Context, making Docker’s network status irrelevant to the initial failure.
  • Permission Silos: Security software often treats CLI tools (like node.exe) differently than browsers (like Chrome), applying stricter outbound rules to non-interactive processes.

Real-World Impact

  • Developer Velocity Degradation: Engineers waste hours “reinstalling everything” (Node, Docker, Git) when the issue is actually a single network configuration or proxy setting.
  • Onboarding Friction: New hires are unable to spin up local environments, leading to immediate loss of productivity.
  • CI/CD Fragility: Similar issues manifest in automated pipelines where runners lack the necessary outbound egress rules to fetch version metadata or dependencies.

Example or Code

To debug if the host Node.js process can actually see the internet, use this minimal script instead of the heavy wp-env tool:

const https = require('https');

https.get('https://api.wordpress.org/core/versions/latest.json', (res) => {
  console.log('Status Code:', res.statusCode);
  res.on('data', (d) => {
    process.stdout.write(d);
  });
}).on('error', (err) => {
  console.error('Connection Failed:', err.message);
});

How Senior Engineers Fix It

A senior engineer ignores the “reinstall everything” rabbit hole and follows a systematic isolation strategy:

  1. Isolate the Layer: Determine if the failure is at the OS level, the Node.js level, or the Docker level. The provided error log proves the failure is at the Node.js level (on the host).
  2. Verify Proxy Configuration: Check for HTTP_PROXY and HTTPS_PROXY environment variables. If the user is behind a corporate proxy, they must configure Node.js to use it (e.g., using global-agent or setting environment variables).
  3. Check DNS Resolution: Test if nslookup api.wordpress.org works in the terminal. If it does, but Node fails, the issue is specifically how Node handles DNS or TLS.
  4. Bypass the Check: If the network is truly unfixable, a senior engineer would manually populate the wp-env cache directory (found in AppData/Roaming/wp-env on Windows) with the required version JSON files to satisfy the tool’s requirements without a network call.

Why Juniors Miss It

  • Symptom-Based Troubleshooting: Juniors tend to fix the symptoms (reinstalling Node/Docker) rather than the cause (the network path between the Node process and the API).
  • Assumption of Connectivity: They assume that if a browser can open a website, the terminal/CLI can also open it. They fail to account for process-specific network restrictions.
  • Tool-Centric Thinking: They treat wp-env as a “black box” and assume the error message “network is not available” means the hardware/Docker network is down, rather than realizing it’s a software-level socket error.

Leave a Comment