Daniel is correct. One more point though, there are cases where you may
want to use the full url instead of just "/django_project/", in which case,
you should use settings.BASE_URL or {{ request.get_host }}.
To use either of those in the template, the template would need to be
rendered with a RequestContext, the easiest way to do that is:
from django.shortcuts import render
def some_view(request):
return render(request, 'template/name.html', {'extra_view': 'context
variables'})
The render shortcut uses the request object to add a bunch of stuff to the
context as specified in settings.py:TEMPLATE_CONTEXT_PROCESSORS
For {{ request.get_host }} you would need to include
"django.core.context_processors.request",
For {{ BASE_URL }} you would need to create your own context processor:
# file: my_app/context_processors.py
from django.conf import settings
def base_url(request):
return {'BASE_URL': settings.BASE_URL,
'BASE_URL_NOSSL': settings.BASE_URL_NOSSL} #
Optional/non-standard setting
and then add "myapp.context_processors.base_url", to the
TEMPLATE_CONTEXT_PROCESSORS list.
Also note that settings.BASE_URL can be overwritten locally by adding the
following to the bottom of your settings.py:
try:
from local_settings import *
except ImportError:
pass
and then in local_settings.py (which is left out of your git or hg repo or
just not copied to your live server) add:
BASE_URL = '127.0.0.1' # or '127.0.0.1:8000' or whatever you actually use
More details on when you would want to use request.get_host vs BASE_PATH:
get_host is whatever the user was currently accessing your site from, so if
you have the same codebase being served on multiple subdomains or domains,
and you want to actually display to the user a the full url for the same
hostname, get_host would be what you would want.
BASE_PATH would be useful if you do something more advanced like allowing
logged out users to view the site in http or https protocols, but force
logged in users to use https. In order to accomplish that, you'd want all
of your links to be relative (as in no request.get_host or BASE_PATH)
except the links to login/signup which should be directly to the https
versions of the site in order to prevent the user from having to go through
and extra redirect step (not too bad for users in the same country with
good internet, but international sites and mobile sites should worry about
any unnecessary round trips to the server).
On Tuesday, June 4, 2013 7:25:50 AM UTC-7, Daniel Roseman wrote:
>
> On Monday, 3 June 2013 15:50:21 UTC+1, huw_at1 wrote:
>
>> Hi there, I've run into an issue whereby on production my Django project
>> is accessed from a URL such as http://example.com/django_project/.
>> Apache is configured to host the code under this URL since I do not want
>> the entire site managed by the Django project. My problem is that when I
>> run the Django test server I have a lot of broken links as it wants to run
>> the project from 127.0.0.1 instead of 127.0.0.1/django_project/. Ideally
>> I'd like to have the Django test server reproduce the apache configuration.
>> What is the best way to resolve this does anyone have any experience?
>>
>> Many thanks
>>
>> Huw
>>
>
> You should not hard-code any links. If you use `{% url %}` tags everywhere
> in templates, and `reverse()` everywhere in views, Django will just Do The
> Right Thing and calculate the correct links, according to the mount point
> of your site.
> --
> DR.
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
