Dev Environment: Missing port leads to broken images

I configured a logo in the site settings, but the logo’s URL is missing the default port, i.e. the logo URL looks like this http://localhost/uploads/… rather than http://localhost:3000/uploads/….

I’m starting the development server like this:

RAILS_ENV=development bundle exec rails server

I found that Discourse.base_url is set to "http://localhost" and in config/database.yml, I find this note for the development.hostnames key:

### Don't include the port number here.
Change the "port" site setting instead, at /admin/site_settings.

However, such a site setting does not exist. What do I do?

2 Likes

It’s a hidden setting. Try changing it in the rails console.

bin/rails c

SiteSetting.port = 3000
3 Likes

This works, thank you.

Shouldn’t this be set to 3000 by default in development mode?

1 Like

No, I don’t think so. Not everyone is using port 3000 for development.

1 Like

It’s the default, though, isn’t it? That one has to set the hidden port setting is not at all obvious, hence seeing a logo in the development environment not load is unexpected. In other words, setting a custom logo should just work.

Logos work. It’s not something you usually care about in development.

Alternatively, I believe you can use these entries in sitesettings.yml

developer:
  force_hostname:
    hidden: false
    default: '<my-ip>'
  port:
    hidden: false
    default: '<my-port>'

@pfaffman gave me that tip! (and what a life saver that was)

4 Likes

I had the opposite problem to that of the original poster when setting up a dev site yesterday: I’m running my dev server behind a Nginx proxy so I want clean URL’s, but no matter what I changed in my settings, Discourse kept adding :3000 to many of my internal links including the site logo. I eventually tracked this down to lines 291 - 293 in lib/discourse.rb:

if Rails.env.development? && SiteSetting.port.blank?
    url << ":#{ENV["UNICORN_PORT"] || 3000}"
end

Commenting out these lines made my logo and other links work correctly, although I don’t know if this can lead to other things breaking down the road. It does seem a bit counter-intuitive to override SiteSetting.port in this manner.

2 Likes

I played around with this a bit more, and it seems that everything actually works correctly if I just set SiteSetting.port = 443 and also check the box for ‘force https’ (and I guess it would also work with port 80 and no https). I had read somewhere that I ought to leave the port settings empty, but I guess that was bad advice.