3

I'm running Nginx on port 8888 locally. fastcgi_params is sending SERVER_PORT to PHP-FPM, which I am able to verify with phpinfo() output and craft/storage/runtime/logs/craft.log. I'm also able to navigate all of the admin pages with the port number intact.

Unless I change General Settings > Site URL to include ":8888", I've noticed that all rendered links (homepage, sample "Recent News" block) do not include the different port. I am new to Craft; am I correct to assume that the Site URL must include the port number manually specified, despite the code having getServerPort() in the core code?

Edit: I added the following to general.php:

'siteUrl' => 'http://'.$_SERVER['SERVER_NAME'].':'.$_SERVER['SERVER_PORT'].'/',

This seems sub-optimal; is there a better way to do this? What do others do who run Craft on ports other than 80/443?

0

2 Answers 2

5
  1. For HTTP the default port is 80 and for HTTPS it's 443, obviously.
  2. If port is omitted in the site URL, then the default one is used.
  3. If you want to use a different port, you must specify a different port in the URL.

So, the logical conclusion is that the port must be present in the URL. When building URLs to entries, for example, the site URL is fetched to generate the final URL. So, unless that URL has port specified in it, you'll get URLs with the wrong port. That's exactly how it should work.

The best way to approach this, however, would be to use Craft multi-environment settings to set it up. That way you won't have to dig into the config files whenever you deploy your site.

3

I'm not sure why you believe this is sub-optimal? You only have to set this once.

I'm speculating here but since Craft makes no assumptions about your content, it stands to reason that it also makes no assumptions about how it should respond to a non-standard port unless you specify it—the key word there being non-standard.

In addition, Craft uses the siteUrl setting to build up the final URL it spits out on the front end for assets, links, etc. Craft will actually build up the link with the correct host you specified automatically. This is especially useful when you use a multi-environment config. (If you've ever used WordPress you can attest to how much of a pain this is, so being able to skip the search/replace step on the database is convenient.)

As for the environment variable config:

'siteUrl'  => 'http://'.$_SERVER['SERVER_NAME'].':'.$_SERVER['SERVER_PORT'].'/',

That certainly works but I would be wary of setting $_SERVER['SERVER_NAME'] dynamically in production, since $_SERVER_NAME could be spoofed. The article was written for EE, though the information contained applies regardless of CMS. The threat is small, even less so on nginx, but it's a consideration nonetheless.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.