Local Dev Server URLs Broken on Windows/macOS after PR #3029

[ITX351]

Hi,

I'm encountering an issue with local development using Docker where all site URLs are generated as http://0.0.0.0:4000, making the site inaccessible on Windows and some macOS browsers. This appears to be a direct consequence of PR #3029, which aimed to fix issue #3028.

Background:
Issue #3028 reported a problem where, when using Docker Compose or VS Code DevContainer, the site could be accessed locally (e.g., localhost:4000 or 0.0.0.0:4000), but internal links (navigation, CSS, JS) incorrectly pointed to the production URL (e.g., https://academicpages.github.io). This was due to Jekyll using the configured url instead of the local server address for asset URLs.

PR #3029 Changes:
To address this, PR #3029 made the following changes:

Removed the environment: JEKYLL_ENV=docker setting from the Docker Compose configuration.
Deleted the _config_docker.yml file (which contained url: "").
Changed the Jekyll serve command to jekyll serve -H 0.0.0.0 -w.
The intent was to force Jekyll into its default development mode, where it uses the --host argument (0.0.0.0 in this case) to generate URLs for assets and links.

Introduced Problem:
While this change successfully resolved the original issue for the PR author (who seemed to be on Linux, where 0.0.0.0 often resolves correctly in the browser), it introduced a significant cross-platform compatibility problem.

In development mode, Jekyll now uses 0.0.0.0 (from the -H 0.0.0.0 flag) as the base site.url. Consequently, all generated HTML links and asset URLs become http://0.0.0.0:4000/....

On Linux (Desktop): Browsers often interpret 0.0.0.0 as 127.0.0.1, so accessing http://0.0.0.0:4000 might work, masking the issue.
On Windows & macOS: Accessing http://0.0.0.0 directly in the browser typically fails or causes resource loading problems, as 0.0.0.0 is not a standard address for direct browser access. Users must specifically use http://localhost:4000 or http://127.0.0.1:4000, but the page content still references 0.0.0.0, leading to broken styles/scripts or security errors.
Analysis:
The deleted _config_docker.yml with url: "" was actually a safer approach for ensuring local links were relative or correctly overridden. The current solution prioritizes fixing one specific symptom (incorrect production URL usage) by hardcoding a host (0.0.0.0) that is not universally accessible as a browser address, breaking the experience for users on other operating systems.

Could we reconsider the fix from PR #3029 to ensure local development works reliably across Linux, Windows, and macOS? Perhaps reinstating a mechanism like _config_docker.yml or adjusting how the Jekyll environment is configured could resolve both the original issue #3028 and this new accessibility problem.

Thanks for your time and the great template!

[rjzupkoii]

I'm onboard with having a universal fix in place, most of my development takes place on Windows via WSL so I don't really use Docker enough to really be able to troubleshoot the nuances of serving the site outside of the container for all operating systems. So definitely going to need some help getting a definitive fix up for this one, and even then we may want to tag it with which environments it was tested on.

[ITX351]

Following up on the previous discussion regarding local development URLs breaking on Windows/macOS after PR #3029, I believe I've identified the actual root cause of the original issue reported in #3028.

Recap of PR #3029:
PR #3029 aimed to fix #3028, where local assets/links incorrectly pointed to the production URL (https://academicpages.github.io) instead of the local server URL. It did this by removing the JEKYLL_ENV=docker environment variable, deleting _config_docker.yml (which contained url: ""), and changing the serve command to jekyll serve -H 0.0.0.0 -w. While this made URLs use 0.0.0.0 (fixing the symptom for the author on Linux), it broke access for Windows/macOS users and introduced cross-platform issues.

Identified Root Cause:
Upon reviewing the changes leading up to PR #3029, I traced the original problem in #3028 to commit 37a2589. This commit introduced the Docker Compose command:
command: jekyll serve -H 0.0.0.0 -w --config _config.yml, _config_docker.yml

There's a critical syntax error in the --config argument: an extra space after the comma (_config.yml, _config_docker.yml).

This typo likely prevented Jekyll from correctly parsing and applying the _config_docker.yml file. Consequently, the url: "" setting in _config_docker.yml was ignored, and the production URL from _config.yml was used instead, manifesting as the issue described in #3028.

Proposed Solution:
The original Docker configuration approach using _config_docker.yml was sound. The problem was simply this overlooked syntax error.

Instead of removing the configuration mechanism (PR #3029), the fix should be to correct the command syntax by removing the extra space:
command: jekyll serve -H 0.0.0.0 -w --config _config.yml,_config_docker.yml

This would allow _config_docker.yml to correctly override the url, resolving the original issue #3028 while maintaining cross-platform compatibility (avoiding the http://0.0.0.0:4000 problem for Windows/macOS users).

I'm happy to submit a PR to correct the typo in the --config argument and restore the _config_docker.yml mechanism if this approach makes sense.

[rjzupkoii]

@ITX351 Yes, please feel free to submit a PR, thanks!