search

visiblevc / wordpress-starter

A slightly less shitty wordpress development workflow
688 stars 167 forks source link

loopback requests fail when 'site_url' points to localhost:xxxx #179

Open EvanShaw opened 3 years ago

EvanShaw commented 3 years ago

First of all, thank you for this great repo! I use the images everyday for local development.

Overview

In a local environment, where an arbitrary port is forwarded to the host machine (eg. -p 9000:80), requests to site_url, home_url, etc. that are invoked from within the container via wp_remote_post, cURL, etc. do not work since Apache only listens on ports 80 and 443. Because of this, things like wp-cron, which in this case would send a request to localhost:9000, fail.

At the moment, I'm getting around this by making Apache also listen on the published port, which I pass as a Docker environment variable to be used in my custom entrypoint:

sudo sh -c "echo \"Listen ${DOCKER_CONTAINER_PORT}\" >> /etc/apache2/ports.conf"
sudo sed -i "s/VirtualHost \*:80/VirtualHost \*:80 \*:${DOCKER_CONTAINER_PORT}/g" /etc/apache2/sites-enabled/000-default.conf

This is probably not an issue for people using the images in production. It's not really a bug, I guess, but I thought I would let you all know.

dsifford commented 3 years ago

Seems like a legitimate concern. Feel free to open a PR.

EvanShaw commented 3 years ago

@dsifford

The best solution would be to get a list of exposed ports dynamically from dockers REST API, or some such thing. This would alleviate the need for the user to explicitly define an environment variable with the value of the exposed port. Unfortunately, after snooping around a little bit, it doesn't seem like that's possible... at least according to this thread on moby/moby which has been open since 2014...

The environment variable approach, besides being verbose and redundant, also has its own problems:

  1. The user may mistakenly set the environment variable to the wrong port number
  2. If multiple ports are exposed you would have to list them as a comma-separated string in the environment variable, which is ugly and prone to error
  3. From a user perspective, it's not obvious what the point is

Do you know if it's possible to get a list of all exposed ports from within the container without using environment variables? I would much rather pursue this solution if it's feasible.

dsifford commented 3 years ago

Happy to entertain any ideas you might have, but agree that the fix you call out does sound like it's just fixing one bug but introducing another.