Hacks which embed knowledge of the mount point in the application
generally indicate that you are doing something wrong in your
configuration.
Stop trying to jump to solutions when hasn't even been determined what
you are doing wrong.
As suggested, post the mod_wsgi configuration you are using so can
confirm that for starters, that that isn't the problem.
Graham
On Aug 2, 3:40 am, Streamweaver <streamwea...@gmail.com> 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=enandthey
> > 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 -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
