Infinite redirect if using a port number

[dwille]

While setting up my new blog I found that WordPress? MU continuously re-directed me to the same URL (occurs in the if statement on line 9 of wp-signup.php). This was being caused by wpmu-settings.php on line 10. The variable $domain has the port stripped from it, which causes line 84 to return no result when it queries the database.

WP MU is installed at ​http://some.host.address:8080/blogs on my machine. VHOST is false.

[donncha]

Sorry, won't fix. It's very unlikely that a product site would use a port number and even for testing it complicates things.

[magnayn]

Oh dear.

I have just been caught out by this bug. We were trying to use mu for internal (non public facing) blogs in a corporate environment, as a fair number of companies are doing this these days, rather than having an admin create discrete wordpress installs per user.

Not only is it entirely common policy to have internal servers on alternate ports (8080, 88, 8000, etc); it's /particularly/ nasty to have it fail in a 'die in an infinite loop' rather than 'detect, report error'. At the very least that needs to be fixed, and the underlying problem ought to be fixed too. Wordpress is perfectly happy on alternate ports, why not MU.

[donncha]

WPMU will now die if a port number is used. Unfortunately it's an edge case, and not used very often. At least it'll die now gracefully with an error message.
Patches and fixes are welcome if your company depends on this facility.

[umbrae]

I know this ticket is 3 years old, but I just wanted to throw my hat into the ring here.

I was going to use varnish on my server as port 80 to reduce load and have apache running on a nonstandard port which varnish would passthrough. It looks like this gotcha is going to complicate things significantly.

Just wanted to give you one reason a product site may use a port number.

[umbrae]

If anybody else comes upon this and sees my issue, the way I solved it was to have both varnish and apache listening on port 80, but with apache only listening on the loopback interface (127.0.0.1) - that way they could share port 80.

Not the best solution, so I'm leaving this bug open for now.