SITE_ID
craphunter
I do have problem with SITE_ID. I don't really get this. What is it?
I am using the django registration from bitbucker. When I click on
register I get the following error-message:
You're using the Django "sites framework" without having set the
SITE_ID setting. Create a site in your database and set the SITE_ID
setting to fix this error.
Am I right that I do have to set an ID in my database?
For example
mysql > test.db table 1?
settings.py
SITE_ID = 1
Can somebody write me a little tutorial?
Thanks,
Craphunter
PS: Sorry, newbee!
Max Countryman
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
craphunter
it?
Craphunter
craphunter
What do I have to do?!
Craphunter
Max Countryman
werefr0g
I searched the web for your error message and found that maybe you should see at INSTALLED_APPS level [1].
Regards,
[1] http://www.pubbs.net/200908/django/40799-django-sites-framework.html
Tim Sawyer
> Yes, I have read it, but I don't really get it. What is the meaning of
> it?
Consider a website that has multiple blogs, all of which are deployed to
the same database.
Consider that you want each blog to be a separate URL: www.blog1.com,
www.blog2.com, but you only want one database for ease of backing up etc.
So, you have one codebase, one database, but multiple sites.
You can achieve this using SITE_ID. www.blog1.com has a settings.py
with SITE_ID = 1. www.blog2.com has a settings.py file with SITE_ID =
2. In your database, there are two rows in the django_site database
table, with serials 1 and 2. The table that holds the blog entries has
a foreign key to Site, and so identifies which site the blog post
appears on.
At least that's how I used it...hope that helps clarify it a bit!
Tim.
Benedict Verheyen
Hey Tim,
the way you used it would mean that you had different settings.py per site/url and thus
a project per url as 1 project can only have 1 settings file? Is this correct?
Have do you config the admin then so you see both sites in the same admin?
Regards,
Benedict
Tim Sawyer
Hi Benedict,
Yes that's correct. Each settings.py is a separate virtual host in
Apache. The rest of the source was common (on the pythonpath). So the
pythonpath was the same for each virtual host but there was a uniquely
named settings.py refered to from the mod-wsgi config.
These were distinct sites for distinct customers, so each site had its own
admin, limited to that site's data.
Here's the mechansim I used to limit the admin to that site's objects. I
think if you don't do any of this, each admin will have all the data
available in it, if that's what you want.
Each model had an additional manager:
from django.contrib.sites.managers import CurrentSiteManager
class Contest(models.Model):
...
objects = models.Manager()
on_site = CurrentSiteManager()
and in the admin.py I redefined the queryset:
class ContestAdmin(SiteOnlyAdmin):
def queryset(self, request):
return self.limitQueryset(request, Contest)
admin.site.register(Contest, ContestAdmin)
where limitQueryset is defined on the superclass as:
def limitQueryset(self, request, pObject):
return pObject.on_site.all()
Hope that helps,
Tim.
Benedict Verheyen
Tim,
that helped, thanks for sharing the information !
Regards,
Benedict
