Port forwarding address issues with WordPress + Docker + Codespaces, as of two weeks ago.

[possumbilities]

Did something change and/or break with how port forwarding is handled on Codespaces in the last 2-3 weeks?

Background

I've had a pretty close to basic WP docker setup, that mostly adheres to the official docker-compose.yml setup from WordPress. It's worked fine for months utilizing Codespaces on the web interface.

• The wordpress service has the ports set as: 8080:80
• the WP site builds with a WP_HOMEURL and WP_SITEURL url of: https://${CODESPACE_NAME}-8080.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}
• I run docker compose up
• It pulls, and builds, and automaps port forwarding to :8080 in the running Codespace.
• I open the URL of the pattern: ${CODESPACE_NAME}-8080.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}, and the site loads fine, lets me install WordPress, and login
• I visit the site frontend at: ${CODESPACE_NAME}-8080.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}/any-page-title, and its worked fine all this time, for months without issue.

The Problem

Two weeks ago: I spun up my Codespace, having changed no code from the last time it worked and now everything above works as described, EXCEPT for that last bit.

If I visit ANY frontend page route: ${CODESPACE_NAME}-8080.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}/any-page-title, I get automatically redirected to: ${CODESPACE_NAME}-443.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}/any-page-title, which is not the URL WordPress is running at.

Investigation

• I thought perhaps something had changed with the way Codespace is doing port forwarding and/or poxy-ing and that perhaps there is now a configuration that WordPress now lacks, so I looked and did find that WP attempts to send traffic to :443 as of version v5.7 if certain criteria is detected (which I believe this setup meets). However, I've been using versions v6, v6.1, and v6.2 for months with no issue whatsoever. So I thought perhaps the issue lay elsewhere.
• I removed WP's automatically reverse proxy https detection, which then sends traffic back to port :80 to test things further. And then when I tried to access a frontend in page at: ${CODESPACE_NAME}-8080.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}/any-page-title, I instead get redirected to: ${CODESPACE_NAME}-80.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}/any-page-title, which is also NOT where WordPress's URL is set to run, but interestingly should have mapped to :8080 automatically, right?
• So, I looked through the discussions, and noticed several issues related to Port Forwarding from about two weeks ago failing, or not working as expected, and I was working around then in other projects and noticed similar behavior.

[timnolte]

This is not a solution but an observation concerning the available environment variables. I too have been working on a setup that is loosely based on the WordPress Core Codespaces setup. I noticed that the Codespaces name & port forwarding domain environment variables don't exist within my PHP environment, they also seem not to be available properly during the container build process as the localhost domain is what ends up being populated in the database. In my case I have WordPress installed in a wp/ directory, similar to Bedrock by Roots.

[timnolte]

Just noting that I did get things working database wise by ensure that I was passing in the CODESPACE_NAME & GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN in my docker-compose.yml however, I too am faced with the redirect to the -443 domain. I noticed when I hadn't had the the WordPress site configured with the ${CODESPACE_NAME}-8080.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN} domain and things were being configured with just localhost:8080 I wasn't getting a redirect but with the domain name set correctly I am getting a redirect.

[timnolte]

OK, so I have gotten a working solution for this issue. What I setup in my wp-config.php file was the following code/logic.

// Configure site domain name for Codespaces if present.
$is_codespaces = boolval( getenv( 'CODESPACES' ) );
$codespace_name = getenv_docker( 'CODESPACE_NAME', '' );
$codespace_domain = getenv_docker( 'GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN', '' );
if ( $is_codespaces ) {
	$site_domain = $codespace_name . '-8080.' . $codespace_domain;
	define( 'WP_HOME', 'https://' . $codespace_name . '-8080.' . $codespace_domain );
} else {
	$site_domain = 'localhost';
	define( 'WP_HOME', 'http://localhost:8080' );
}
defined( 'WP_SITEURL' ) || define( 'WP_SITEURL', rtrim( WP_HOME, '/' ) . '/wp' );

// If we're behind a proxy server and using HTTPS, we need to alert WordPress of that fact
// see also http://codex.wordpress.org/Administration_Over_SSL#Using_a_Reverse_Proxy
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
	$_SERVER['HTTPS'] = 'on';
	$_SERVER['HTTP_HOST'] = $site_domain;
}
// (we include this by default because reverse proxying is extremely common in container environments)

In my docker-compose.yml I had to also ensure that I included the following environment variable setup.

    environment:
      CODESPACES: "${CODESPACES}"
      CODESPACE_NAME: "${CODESPACE_NAME}"
      GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN: "${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}"

I use and Apache service and a PHP-CFM main app service so I made sure that these were included in both service configurations.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[timnolte]

I opened up a PR to fix this. I haven't seen any new responses lately with more feedback.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[a-growbit]

Onliner hammer eval FTW till in 2025... GenAI is not ready for this.

    environment:
      WORDPRESS_CONFIG_EXTRA: $$site_domain = '${CODESPACE_NAME}-8080.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}'; $$site_url = 'https://'.$$site_domain.'/'; define('WP_HOME', $$site_url);  define('WP_SITEURL', $$site_url); $$_SERVER['HTTP_X_FORWARDED_PROTO'] = 'https'; $$_SERVER['HTTP_HOST'] = $$site_domain;

Please add a sub chapter there [1] on "How to use this image on GitHub Codespace" :°°°D

Refs

1. Update reverse proxy code and link docker-library/wordpress#648
2. https://github.com/orgs/community/discussions/155500
3. Update reverse proxy code and link docker-library/wordpress#648
4. Inject configuration using environment variable docker-library/wordpress#142