[Proposal] Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py
aditya
=========
This page of the Django documentation shows how to use the 'Sites'
framework to get the domain of the current site:
http://docs.djangoproject.com/en/dev/ref/contrib/sites/
I've noticed that 'domain = Site.objects.get_current().domain' is
becoming a common idiom in Django. Most recently I've seen it being
used in django-disqus as a way to get the url of the current site
(Disqus tracks comments by associating each comment with a specific
url). I'm also seeing it being used for RSS feeds and for mailers.
The trouble is, there is no straightforward way to configure the name
and domain of a site.
Currently, Django uses "example.com" for both the domain and the
name. The only way to change that is to wade into the actual
database. I'd like to propose adding two optional variables to
settings.py:
SITE_DOMAIN and
SITE_NAME.
If either of these are defined, they will override "example.com" when
the new site is created.
Implementation
============
This is quite easy to implement. In the create_default_site function,
add these 5 lines:
from django.conf import settings
try: def_domain = settings.SITE_DOMAIN
except: def_domain = "example.com"
try: def_name = settings.SITE_NAME
except: def_name = "example.com"
and then create the new site using:
s = Site(domain=def_domain, name=def_name)
I hope this is the correct place to post this! I wanted to hear what
other people thought of this proposal.
Rajeev J Sebastian
I think this is a very good idea!
Regards
Rajeev J Sebastian
Gabriel Hurley
should probably read up on the "Sites" framework that ships with
Django:
http://docs.djangoproject.com/en/dev/ref/contrib/sites/
All the best,
- Gabriel
aditya
Aditya
Gabriel Hurley
The "Site" model in that code comes from the
django.contrib.sites.models, part of the Sites framework I mentioned
above. This is not some bizarre buried database mishap; this is the
app developer taking advantage of a contrib app that is included in
Django.
You complain "The trouble is, there is no straightforward way to
configure the name and domain of a site" but if you actually *include*
django.contrib.sites in your INSTALLED_APPS you'd see that it's EASILY
configurable using the Django admin, and that it in fact offers you
some very useful features if you want to publish similar content on
multiple domains.
As of Django's 1.0 release the Sites framework is supported as an
*optional* component, allowing developers to take advantage of it in
their apps without requiring that everyone use contrib.sites. This is
accomplished using the RequestSite object. You can read about that
here:
http://docs.djangoproject.com/en/dev/ref/contrib/sites/#requestsite-objects
However, if you're in the habit of using 3rd-party apps that take
advantage of the Sites framework, I strongly suggest you simply *add*
"django.contrib.sites" to your INSTALLED_APPS in settings. Then you
can edit it via the Django admin, the Django shell, or by whatever
method you choose.
Adding another setting in place of the actual contrib.sites app would
be a *different* solution to the problem solved by RequestSite, but I
don't see that it offers any real advantages.
Please read the docs I linked you to carefully. It really does explain
everything you need to know to understand why your proposal is off-
base. Again:
http://docs.djangoproject.com/en/dev/ref/contrib/sites/
All the best,
- Gabriel
Rajeev J Sebastian
Gabriel,
I think, you haven't read the proposal correctly.
The suggestion was that, syncdb for e.g., would create the default
Site using the settings SITE_DOMAIN and SITE_NAME instead of blindly
using 'example.com'.
This prevents the need to go in an edit the domain within the admin
(or run some python code in shell) everytime one does a syncdb. It is,
quite simply, a suggestion to allow overriding the django default when
creating the *default* Site object.
Regards
Rajeev J Sebastian
Chuck Harmston
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Will Hardy
> provide?
Convenience. It moves the definition of the site away from the
database, and away from fixtures files and into the settings.
Personally, I am yet to need multiple sites for a single database, and
would much prefer being able to set the domain using settings files
(eg host="localhost:8000" for my settings/local.py on my dev,
host="production.com.au" for settings/__init__.py etc).
For my needs, being able to define the domain in the settings is much
more powerful and convenient than storing it in the database and an
initial_data fixture isn't going to be able to play very cleanly with
my settings configuration.
Just adding my +1 vote for a standard,
Site.objects.get_current()-compatible way to set the domain name in
django.conf.settings. Bonus points if no site table is created and no
ModelAdmin turns up in admin on auto_discover.
Rajeev J Sebastian
> This particular use case (having predefined sets of information loaded into
> the database on either syncdb or other command) is what Django's fixture
> loading/creation system is for.
> http://docs.djangoproject.com/en/dev/ref/django-admin/#what-s-a-fixture
> http://docs.djangoproject.com/en/dev/howto/initial-data/#providing-initial-data-with-fixtures
> Does this proposal add any functionality that fixtures do not already
> provide?
> Best,
> Chuck
Thanks Chuck, but no, that doesn't solve the issue (the solution was
outlined by the OP).
Its just easier to have this in the settings (imo), because at the
point of time (or phase of development) where this is useful, there
are usually no fixtures.
Regards
Rajeev J Sebastian
aditya
solution though. It is not as simple as my proposal, but certainly
more elegant.
Aditya
On Mar 13, 6:57 am, Chuck Harmston <ch...@chuckharmston.com> wrote:
> This particular use case (having predefined sets of information loaded into
> the database on either syncdb or other command) is what Django's fixture
> loading/creation system is for.
>
>
> Does this proposal add any functionality that fixtures do not already
> provide?
>
> Best,
> Chuck
>
> On Sat, Mar 13, 2010 at 5:50 AM, Rajeev J Sebastian <
>
> rajeev.sebast...@gmail.com> wrote:
> > On Sat, Mar 13, 2010 at 3:56 PM, Gabriel Hurley <gab...@gmail.com> wrote:
> > > "domain = Site.objects.get_current().domain"
>
> > > The "Site" model in that code comes from the
> > > django.contrib.sites.models, part of the Sites framework I mentioned
> > > above. This is not some bizarre buried database mishap; this is the
> > > app developer taking advantage of a contrib app that is included in
> > > Django.
>
> > > You complain "The trouble is, there is no straightforward way to
> > > configure the name and domain of a site" but if you actually *include*
> > > django.contrib.sites in your INSTALLED_APPS you'd see that it's EASILY
> > > configurable using the Django admin, and that it in fact offers you
> > > some very useful features if you want to publish similar content on
> > > multiple domains.
>
> > > As of Django's 1.0 release the Sites framework is supported as an
> > > *optional* component, allowing developers to take advantage of it in
> > > their apps without requiring that everyone use contrib.sites. This is
> > > accomplished using the RequestSite object. You can read about that
> > > here:
>
> >http://docs.djangoproject.com/en/dev/ref/contrib/sites/#requestsite-o...
> > django-develop...@googlegroups.com<django-developers%2Bunsu...@googlegroups.com>
Gabriel Hurley
being proposed without understanding the existing solution.
Personally, I use a custom model that inherits from Site to manage my
sites, so it's not like I'm thrilled with the current system either.
I would actually be +0 on adding this as a feature for some future
released, particularly if it was simple, and Site.get_current()-
compatible.
Getting some feedback from the core devs would be great, but they've
definitely got more important things on their minds with the 1.2
deadlines looming. (the ticket list is shrinking fast, though! Keep up
the great work!)
All the best,
- Gabriel
Rajeev J Sebastian
> I'm not arguing that the proposal is inherently bad, just that it was
> being proposed without understanding the existing solution.
That's not what I got from your harsh responses.
The existing "solution" is to modify the default Site created by
Django, either by using admin or by writing a script.
It's just far easier to define SITE_DOMAIN and SITE_NAME and make a
small modification to
django/contrib/sites/management.py:create_default_site that makes use
of these settings, instead of "example.com".
Anyway, nothing to get so worked up about as you have done.
Regards
Rajeev J Sebastian
Rajeev J Sebastian
> I'm not arguing that the proposal is inherently bad, just that it was
> being proposed without understanding the existing solution.
> Personally, I use a custom model that inherits from Site to manage my
> sites, so it's not like I'm thrilled with the current system either.
>
> I would actually be +0 on adding this as a feature for some future
> released, particularly if it was simple, and Site.get_current()-
> compatible.
One more thing: the OP was not suggesting the replacement of
Site.get_current(), as you seem to have misunderstood.
Regards
Rajeev J Sebastian
James Bennett
> The trouble is, there is no straightforward way to configure the name
> and domain of a site.
Sure there is: create a Site object, or edit an existing one, setting
the values you want on it.
> Currently, Django uses "example.com" for both the domain and the
> name. The only way to change that is to wade into the actual
> database.
You say this as if it's something obviously evil and horrible and
terrible, but provide no explanation of *why* it's bad. You then
propose solving this problem by adding two new settings to Django
which will be used only when syncdb installs the sites app and then
never referenced ever again.
If you want this proposal to be taken seriously, you'll need to:
1. Explain why you think it's such a bad thing for a framework which
offers easy ways to interact with your database to... ask you to
interact with your database.
2. If it turns out there's a real problem, provide a solution which
doesn't involve one-time settings and which, preferably, leverages
existing and proven features of Django rather than trying to add new
ones just for this case.
Admittedly these will be rather high hurdles, since I don't honestly
see what the problem is here; yes, you'll end up editing the default
Site object, but there are things which need a Site object to exist as
soon as contrib.sites is installed, and so we just default to the
safest possible thing: the example domain name reserved for this sort
of use by RFC2606.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
aditya
could change those values by adding django.contrib.sites to my
INSTALLED_APPS. That's why I said there was no straightforward way of
configuring those values.
I wish Django had some sort of 'sample proposals' on their site. You
say "provide a solution...which, preferably, leverages
existing and proven features of Django" but to be honest I thought my
solution did that already – it added nothing more than a try
statement. How would I have made it any simpler than that?
In any case, thanks for the response.
On Mar 14, 6:27 am, James Bennett <ubernost...@gmail.com> wrote:
sub...@gmail.com
encompass, but would you really even find yourself using it?
I don't see the technical difference here--pre-syncdb, you either have
to 'wade' to the database or you have to 'wade' to this item in
settings.py. Its not as though you really need to create the same site
again and again. And if you do, there's fixtures.
-S
David Larlet
Le 14 mars 2010 à 12:27, James Bennett a écrit :
> On Fri, Mar 12, 2010 at 4:39 PM, aditya <blueman...@gmail.com> wrote:
>
>> Currently, Django uses "example.com" for both the domain and the
>> name. The only way to change that is to wade into the actual
>> database.
> 2. If it turns out there's a real problem, provide a solution which
> doesn't involve one-time settings and which, preferably, leverages
> existing and proven features of Django rather than trying to add new
> ones just for this case.
Just my 2 cents, the "Django way" to deal with one-time settings is to ask directly the user (see admin user's creation) during the syncdb call. But, most of the time, I end up adding fixtures for the admin and launch syncdb with the --noinput option. Faster.
That's a bit off-topic but this can lead to security issues given that your default fixtures will load whatever the environment. How do you handle this: fixtures by environment? Maybe we should reconsider the <appname>/sql/<modelname>.<backend>.sql pattern to add an environment info?
Regards,
David
Yuri Baburov
How do you like the following idea:
startproject command puts a fixture for django.contrib.sites (and
fixture for superuser probably) to the root folder or whatever, to be
loaded with syncdb?
That way also encourage users to get more familiar with fixtures.
Of course it's too far for 1.2, so it can be implemented with 1.3 timeline.
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
jens
> How do you like the following idea:
> startproject command puts a fixture for django.contrib.sites (and
> fixture for superuser probably) to the root folder or whatever, to be
> loaded with syncdb?
IMHO it would be a great, if django can set the SITE_ID dynamic, based
on the current domain.
There exist some old links related to this:
http://groups.google.com/group/django-developers/browse_thread/thread/d9f1088de7944de3
http://code.djangoproject.com/ticket/4438
http://www.djangosnippets.org/snippets/1099/
Gert Van Gool
(http://code.djangoproject.com/ticket/8896).
Let urlresolvers also route according to hostname.
-- Gert
Mobile: +32 498725202
Web: http://gert.selentic.net
2010/3/15 jens <google...@jensdiemer.de>:
Chris
> Hello all,
>
> How do you like the following idea:
> startproject command puts a fixture for django.contrib.sites (and
> fixture for superuser probably) to the root folder or whatever, to be
> loaded with syncdb?
> That way also encourage users to get more familiar with fixtures.
> Of course it's too far for 1.2, so it can be implemented with 1.3 timeline.
This I like.
I also like the idea of sites prompting the user for a domain when
syncdb creates the contrib.sites tables.
Or maybe have the sites framework not add an 'example.com' entry on
creation by default and let the system raise an exception when it
tries to get the current site to remind the developer to add a site
object. Or maybe instead of raising an exception, have it try to get
SITE_URL from your settings.
I once accidentally had for a few days my sitemaps all pointing to
example.com because I forgot to change the url after a database purge.
Ouch.
Me honestly, I've never really liked the sites framework very much. I
don't *hate* it, but it's always been something that got in my way
more than it's granted me much convenience. The thing that bothers me
is how the overwhelming majority of sites (I'm assuming) have no use
for a sites framework, yet django kind of 'forces' you to use it for a
lot of functionality. For instance, the syndication framework,
sitemaps, the 'view on site' link in the admin interface, etc...
dalore
using internally. It's a straightforward way to modify the default
site object.
More details: http://oppian.com/labs/django-defaultsite/
Any comments/suggestions welcome.
Sincerely
Matthew Jacobi
Oppian Systems Ltd
Oldřich Jedlička
Because of this thread I decided to release a little app we have been
using internally. It's a straightforward way to modify the default
site object.
More details: http://oppian.com/labs/django-defaultsite/
Any comments/suggestions welcome.
I've just got to this thread and I'm using a little bit different approach (attached) - update when needed, not only when the Site model gets created. I also have a little app (called "common") to handle this task.
Regards,
Oldrich.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Felipe Prenholato
Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://chronosbox.org/blog
Twitter: http://twitter.com/chronossc
Rolando Espinoza La Fuente
<phili...@gmail.com> wrote:
> About idea of use settings.py to set a default site, -1
> About ask to user what is yours default site, +1
> This thing only runs at syncdb, so I really don't think that a entry in
> settings.py is needed.
+1 to the idea to just ask in syncdb, in the same way that admin user
is created.
Here is my proposal: http://gist.github.com/411456
Regards,
~Rolando
BrettH
The only issue that I have with sites is that the default site should
be 127.0.0.1:8000 since that's what runserver defaults to. Putting
example.com as SITE_ID 1 only makes novice django developers shout and
throw things because like me they 'add 127.0.0.1:8000 and delete
example.com' instead of replacing example.com and wonder why runserver
isn't serving their first hello world flatpage. I had a blog post
which included this tip, and it amazes me how many people commented
they had done the same thing, which suggests there is a large number
of people who make this simple but avoidable mistake. Since nobody
will ever use 'example.com' it should not be there in the first place.
On May 24, 12:16 pm, Rolando Espinoza La Fuente <dark...@gmail.com>
wrote:
>