We Keep Coding

site domain issue in Django project

I started django server with following command:
python manage.py runserver 192.168.31.79:8030
when I use following code,
from django.contrib.sites.models import Site
current_site = Site.objects.get_current()
print (current_site.domain)
the result will be 192.168.31.79:8000, why not port is 8030? Anyone could explain it for me? how could I retrieve 192.168.31.79:8030 via coding. many thanks.

When resolving the Site with get_current Django will first check if a SITE_ID is set in the settings file. If there is a SITE_ID it will return what is stored in the domain field (obtaining the cached version in SITE_CACHE or adding it to the cache and returning it).
If SITE_ID is not present Django will resolve the host with request.get_host() and first query to see if the domain exists within the cache then check if it is in a Site object.
If this does not produce a result it will remove the port and check again in the same manner.
I would try looking at each of your Site objects to see if the port has made it into the domain. If not look into what is being stored in SITE_CACHE.
Documentation at https://docs.djangoproject.com/en/dev/ref/contrib/sites/#django.contrib.sites.shortcuts.get_current_site

Issue with Sites system in Django

I have an issue with the Sites system in Django. My problem is when running Site.objects.get_current() on some pages on initial load of the development server I get an exception saying Site matching query does not exist. however if I load the main page of the site it loads just fine then I can go back to any other page with the exception and they load fine as well.
Has anyone come across this issue before?
Thanks,
Nick

get_current looks at the current hostname and detects whether you have a Site object with a matching domain name.
Perhaps on development you are using localhost or something similar. You need to create a Site object with the same domain name, i.e., via something like this which could be added to a migration:
if settings.DEBUG:
development_site_domain = 'localhost' # Or whatever yours is.
Site.objects.create(
name=development_site_domain,
domain=development_site_domain)
You must have a Site object in the database for any FQDN you access your app via. You also need to include the FQDN in your ALLOWED_HOSTS setting.
The alternative is to set SITE_ID = 1 (or any pk of an existing SITE_ID in your database). The drawback here is that your server will respond differently on local vs. on the server if you're using a dynamic SITE_ID on production.

add SITE_ID = 1 to your settings.py,
and run python manage.py syncdb to create corresponding tables if not exist, this will work
and then, you could login into your admin site:
click Site to modify defalut example.com to yours, this used when you edit an object, It will provide a View on site button if you defined a get_absolute_url function in your models.py

How to make Django test client send requests to different subdomains

I am using the django-subdomains project to enable subdomains in my django project, which works fine.
However, when writing tests, I cannot figure out how to make the Django test client send requests to different subdomains.
It only sends requests to the root domain even if I change the ROOT_URLCONF to point to one of the entries in SUBDOMAIN_URLCONFS with #override_settings. But it works if I directly change the ROOT_URLCONF in settings.py to the desired subdomain urlconf, which is obviously an unacceptable solution.
Also tried to subclass the Django TestCase class and set the "url" field to the subdomain urlconf but the request is still going to root, resulting in 404.
Finally, I tried to use subdomains.utils.reverse to get an absolute url, but the test client does not accept this at all.
This question may be related to Django Test Client and Subdomains. Someone mentioned in a comment that a hack has been used to solve this. Please elucidate said hack or even better, a proper solution to address this surely not-so uncommon use case.

HTTP_HOST = 'rede.example.com'
class TestIndexView(TestCase):
def setUp(self):
self.url = subdomain_reverse('network_index', subdomain='rede')
def test_render(self):
response = self.client.get(self.url, HTTP_HOST=HTTP_HOST)
self.assertEqual(response.status_code, 200)

Allowing users to use custom domains for Django app on Heroku

I have a Django app hosting on Heroku. In the app, the users create pages at http://domain.com/username
I'd like to give users the option to use their own domain name for their page using a CNAME. Ideally I'd like to avoid an A-Record in case I change hosts in the future and my IP changes.
This is completely new territory for me and dont even know where to start, or what to look for. Does anyone have a suggestion on where to start? I've seen mention of Wildcard DNS, but not sure how that ties into my app.
Any suggestions would be really appreciated.

Prelim Answer:
If you control the nameserver for the domain and have access to the RNDC Key, you can use the post-signup view/signal to squirt out a cname to your DNS server that will resove username.yoursite.com to yoursite.com. Make sure apache is set up to recieve a wildcard virtualhost to the correct app, and then use a custom middleware to read request.META['SERVER_NAME'].lsplit('.')[0] to see what the subdomain is. You can then use this information in your views to differentiate user subdomains.

What could cause a Django error when debug=False that isn't there when debug=True

Using the development server, it works with debug=True or False.
In production, everything works if debug=True, but if debug=False, I get a 500 error and the apache logs end with an import error: "ImportError: cannot import name Project".
Nothing in the import does anything conditional on debug - the only code that does is whether the development server should serve static files or not (in production, apache should handle this - and this is tested separately and works fine).

Just to say, I ran into a similar error today and it's because Django 1.5 requires the ALLOWED_HOSTS parameter in the settings.
You simply need to place this row to make it work ;)
...
ALLOWED_HOSTS = '*'
...
However, be aware that you need to set this parameter properly according to your actual host(s) (https://docs.djangoproject.com/en/dev/ref/settings/#allowed-hosts)!
Values in this list can be fully qualified names (e.g. 'www.example.com'), in which case they will be matched against the request’s Host header exactly (case-insensitive, not including port). A value beginning with a period can be used as a subdomain wildcard: '.example.com' will match example.com, www.example.com, and any other subdomain of example.com. A value of '*' will match anything; in this case you are responsible to provide your own validation of the Host header (perhaps in a middleware; if so this middleware must be listed first in MIDDLEWARE_CLASSES).
So basically it's better for you to use this type of configuration once you're in production:
...
ALLOWED_HOSTS = [
'.yourdomain.com',
]
...
thanks to gertvdijk for pointing this out

This happens if you have a circular import in one of your files. Check and see if you are importing something from Project and then importing something in Project from the original file that originally imported Project.
I ran into this same problem recently, and rearranging some of my imports helped fix the problem.

This can also happen if you do not have both a 500.html and 404.html template present. Just the 500 isn't good enough, even for URIs that won't produce a 404!

I had this problem as well. Although it persisted even when setting Allowed_hosts and already having 404 and 500 templates.
I also checked for circular imports, but that was not it.
I finally had django produce a log file, https://stackoverflow.com/a/15100463/1577916
I accidentally left in a "get_host" function which now exists under
HttpRequest (changed to HttpRequest.get_host())with Django 1.5.
for some reason that was not raising an error with Debug True OR False.