-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Check out RequestContext and setting it up with the setting in
settings.py:
http://docs.djangoproject.com/en/dev/ref/settings/#template-context-processors
Luke
luke.seelenbin...@gmail.com
"I [may] disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
Streamweaver wrote:
> Thanks for the great replies here.
>
> It seems from this there might be less repetition if I can just put a
> SITE_URL attribute in my settings.py file and then make that available
> to the template without having to go through the view. Is this
> possible or easy? Custom template filter perhaps but these seem
> pretty complicated and more intended to work like decorators than just
> pushing variables to the template. Hmmm, not sure.
>
> On Jul 31, 1:42 pm, Adam Yee <adamj...@gmail.com> wrote:
>> On Jul 30, 7:29 pm, Graham Dumpleton <graham.dumple...@gmail.com>
>> wrote:
>>
>>
>>
>>> If you are using mod_wsgi then you definitely do not need
>>> FORCE_SCRIPT_NAME as mod_wsgi does the correct think in respect of
>>> setting up SCRIPT_NAME/PATH_INFO. The only time it might not be right
>>> with mod_wsgi is if you used WSGIScriptAliasMatch to map the
>>> application and you didn't set up the directive properly. This can
>>> happen because how you set up pattern and target for that directive
>>> will control how SCRIPT_NAME is calculated. WSGIScriptAliasMatch
>>> should only be used if absolutely required.
>>> So, post how you configured mod_wsgi to mount your application just to
>>> eliminate that as possibility. Verify that FORCE_SCRIPT_NAME isn't set
>>> in settings.py or if it is that it is set to None.
>>> Someone with more Django knowledge would then need to tell you if you
>>> are specifying urls.py correctly, whether any other settings you need
>>> to check and whether how URL references are generated are correct. All
>>> I can tell you is that if mod_wsgi is set up properly, you should
>>> never need FORCE_SCRIPT_NAME with mod_wsgi.
>>> You may need to explain better what is meant by 'This is causing all
>>> my template links to break'. Ie., what errors are you getting, what
>>> are the URLs it is generating and what they should be etc.
>>> Graham
>>> On Jul 31, 12:09 pm, Streamweaver <streamwea...@gmail.com> wrote:
>>>> I'm not actually using {% url %} at this time. I am setup for
>>>> mod_wsgi and don't know how to go about configuring links in the
>>>> templates when the sites root is on a subdirectory. There isn't much
>>>> in the way of examples on FORCE_SCRIPT_NAME I can find and I'm not
>>>> really an apache admin so I'm a bit out of my depth here.
>>>> Is this the avenue I should be pursuing or is there some way to set
>>>> this up better. the url filter seems to violate DRY methodology.
>>>> Thanks again.
>>>> On Jul 30, 9:52 pm, Graham Dumpleton <graham.dumple...@gmail.com>
>>>> wrote:
>>>>> Using FORCE_SCRIPT_NAME is only appropriate for certain WSGI hosting
>>>>> mechanisms. Using it may simply hide the fact that the OPs application
>>>>> code is wrong to begin with.
>>>>> OP should indicate how they are hosting their application for real
>>>>> site. Ie., mod_python, mod_wsgi, fastcgi or other.
>>>>> Graham
>> Graham is right about needing to mount your site correctly. Post your
>> Apache config athttp://groups.google.com/group/modwsgi?hl=enand they
>> can help with that. I've not had to use FORCE_SCRIPT_NAME when using
>> mod_wsgi. What I found that works is passing the script_name in each
>> view context. This is violating DRY, but I haven't worried about that
>> too much. This is a way to make apps portable. If you still need or
>> want to use the {% url %} tag, you just need to preceed it by a
>> {{ script_name }} (I'm mostly sure, correct me if wrong). You can
>> give script_name to your context with request.META['SCRIPT_NAME'] if
>> it exists.
>>
>> hope this helps,
>> Adam
>>
>>>>> On Jul 31, 6:04 am, Alex Koshelev <daeva...@gmail.com> wrote:
>>>>>> If you are using `{% url %}` template tag or `reverse` function you can
>>>>>> set
>>>>>> FORCE_SCRIPT_NAME [1] settings variable specified for your deployment
>>>>>> project root. Or working with right web-server in front of django project
>>>>>> force it to tell proper SCRIPT_NAME himself.
>>>>>> [1]:http://docs.djangoproject.com/en/dev/ref/settings/#force-script-name
>>>>>> ---
>>>>>> Alex Koshelev
>>>>>> On Thu, Jul 30, 2009 at 10:55 PM, Streamweaver
>>>>>> <streamwea...@gmail.com>wrote:
>>>>>>> I have a django project that has worked just fine in development but
>>>>>>> I'm trying to move it to a demo site and the application is not on a
>>>>>>> root domain or sub-domain.
>>>>>>> Instead the site root URL is suppose to be something like
>>>>>>> https://site.domain.com/appname/
>>>>>>> This is causing all my template links to break. The {% url %} tag
>>>>>>> seems to work only for the site root and doesn't bring in the
>>>>>>> subdirectory name.
>>>>>>> What's the Django way of handling this? I'm surprised I haven't been
>>>>>>> able to find something about this.- Hide quoted text -
>>> - Show quoted text -
> >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkp0fpgACgkQXQrGVCncjPweTACeO1qhXSh903qwPX4yKGNGzLUc
jVkAn3MsZShZMbRhjWQ0JAkmeKuKt+fk
=bWAk
-----END PGP SIGNATURE-----
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
