Re: Continuing problems running Django when not site Root.
Okay I am finnally getting my brain around this. Thanks so much. I tried the code out and it works great, even on the login. I appreciate everyone's help and patience. On Aug 8, 9:49 pm, Malcolm Tredinnick wrote: > On Sat, 2009-08-08 at 13:41 -0700, Streamweaver wrote: > > Let me clarify. This method handles the RequestContext obviously since > > it's a login but what I mean is the SCRIPT_NAME variable isn't set for > > the template and can't be read as far as I can tell. > > Nothing is automatically set for a template. If you want access to a > particular quantity in a template, pass it in. You could even create a > context processor if you want it every time. Typically, SCRIPT_NAME is > *not* required in templates, since things like the url template tag > already handle it automatically and constructing the correct URL for > many things is more complex than just crashing together a few strings, > so it tends to be done via template tags or in views. Thus, SCRIPT_NAME > isn't a likely candidate for something that would be passed in all the > time. > > Regards, > Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Continuing problems running Django when not site Root.
On Sat, 2009-08-08 at 13:41 -0700, Streamweaver wrote: > Let me clarify. This method handles the RequestContext obviously since > it's a login but what I mean is the SCRIPT_NAME variable isn't set for > the template and can't be read as far as I can tell. Nothing is automatically set for a template. If you want access to a particular quantity in a template, pass it in. You could even create a context processor if you want it every time. Typically, SCRIPT_NAME is *not* required in templates, since things like the url template tag already handle it automatically and constructing the correct URL for many things is more complex than just crashing together a few strings, so it tends to be done via template tags or in views. Thus, SCRIPT_NAME isn't a likely candidate for something that would be passed in all the time. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Continuing problems running Django when not site Root.
Let me clarify. This method handles the RequestContext obviously since it's a login but what I mean is the SCRIPT_NAME variable isn't set for the template and can't be read as far as I can tell. On Aug 8, 4:15 pm, Streamweaver wrote: > I appreciate all the comment here and I definitly could be missing > something. > > I tried backing out to a fresh install as requested above. > > The issue as best I can understand it lies in the default login > scripts provided which are called as follows in my urls.py file > > (r'^accounts/login/$', 'django.contrib.auth.views.login', > {'template_name': 'accounts/login.xhtml'}), > (r'^accounts/logout/$', 'django.contrib.auth.views.logout', > {'template_name': 'accounts/logout.xhtml'}) > > The templates that normally handle rendering the SCRIPT_NAME property > don't do so here I think because this script isn't being passed the > RequestContext like other scripts. I'll take a look at the source > code for these items and it's likely I can pass a property to it but > I'm a bit unsure how since the request object isn't passed to urls.py > as far as I know. > > If you have more insight it would be helpful but so far my > investigation seems to be turning up that I can't use these magic > methods. > > Thanks again and I'll keep looking this weekend and post if I find > what I'm doing wrong. > > On Aug 7, 10:49 pm, Malcolm Tredinnick > wrote: > > > On Fri, 2009-08-07 at 14:44 -0700, Streamweaver wrote: > > > [...] > > > > Is there anyway around this? Anyone know if fixing this on the Django > > > roadmap? > > > It was fixed over a year ago (before Django 1.0 came out). If you are > > using anything later than that, you don't have to do *anything* to worry > > about SCRIPT_NAME, although the variable is set in the request.META > > dictionary so you can use it to construct URLs if you want to do that > > manually. > > > Regards, > > Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Continuing problems running Django when not site Root.
I appreciate all the comment here and I definitly could be missing something. I tried backing out to a fresh install as requested above. The issue as best I can understand it lies in the default login scripts provided which are called as follows in my urls.py file (r'^accounts/login/$', 'django.contrib.auth.views.login', {'template_name': 'accounts/login.xhtml'}), (r'^accounts/logout/$', 'django.contrib.auth.views.logout', {'template_name': 'accounts/logout.xhtml'}) The templates that normally handle rendering the SCRIPT_NAME property don't do so here I think because this script isn't being passed the RequestContext like other scripts. I'll take a look at the source code for these items and it's likely I can pass a property to it but I'm a bit unsure how since the request object isn't passed to urls.py as far as I know. If you have more insight it would be helpful but so far my investigation seems to be turning up that I can't use these magic methods. Thanks again and I'll keep looking this weekend and post if I find what I'm doing wrong. On Aug 7, 10:49 pm, Malcolm Tredinnick wrote: > On Fri, 2009-08-07 at 14:44 -0700, Streamweaver wrote: > > [...] > > > Is there anyway around this? Anyone know if fixing this on the Django > > roadmap? > > It was fixed over a year ago (before Django 1.0 came out). If you are > using anything later than that, you don't have to do *anything* to worry > about SCRIPT_NAME, although the variable is set in the request.META > dictionary so you can use it to construct URLs if you want to do that > manually. > > Regards, > Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Continuing problems running Django when not site Root.
On Fri, 2009-08-07 at 14:44 -0700, Streamweaver wrote: [...] > Is there anyway around this? Anyone know if fixing this on the Django > roadmap? It was fixed over a year ago (before Django 1.0 came out). If you are using anything later than that, you don't have to do *anything* to worry about SCRIPT_NAME, although the variable is set in the request.META dictionary so you can use it to construct URLs if you want to do that manually. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Continuing problems running Django when not site Root.
Django since 1.0 onwards is usually fine with SCRIPT_NAME. Quite possibly you have tweaked something in settings or setup urls.py wrong to cause the issue. I would suggest you start over with a fresh Django installation and create the most minimal working example of what you are trying to do and which demonstrates the problem. Then come back and post what your Apache/mod_wsgi configuration is, what you changed in settings, what you have in urls.py and the details of what and what the template contains. In short, it is impossible to help when others don't have a problem and we have no idea of what you have set your configuration to or how you are trying to do what you are doing. Graham On Aug 8, 7:44 am, Streamweaver wrote: > There's been some discussion here about what to do when you're trying > to run a Django site not under the root domain. > > So for a site likehttp://mysite.com/django/ > > Django (or WSGI?) doesn't seem to be able to be able to handle the > SCRIPT_NAME ('/django' in this example) portion of the url well. You > have to add the request context to the application and views as well > as account for it in the templates. > > Fair enough I guess and I refactored my application to handle this so > far. > > I'm running into pretty big problems with using Django's login > framework in this context. > > First there are the various login settings of 'LOGIN_URL' and such, > and these can't be passed a context. I got around this by adding > another variable to the settings file I can see in addition to having > to read the SCRIPT_NAME in the views and templates. > > I continue to have a problem though in that the generic login > functions seem to have no way to handle SCRIPT_NAME and I suspect this > problem extends to generic views in general. > > Is there anyway around this? Anyone know if fixing this on the Django > roadmap? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Continuing problems running Django when not site Root.
There's been some discussion here about what to do when you're trying to run a Django site not under the root domain. So for a site like http://mysite.com/django/ Django (or WSGI?) doesn't seem to be able to be able to handle the SCRIPT_NAME ('/django' in this example) portion of the url well. You have to add the request context to the application and views as well as account for it in the templates. Fair enough I guess and I refactored my application to handle this so far. I'm running into pretty big problems with using Django's login framework in this context. First there are the various login settings of 'LOGIN_URL' and such, and these can't be passed a context. I got around this by adding another variable to the settings file I can see in addition to having to read the SCRIPT_NAME in the views and templates. I continue to have a problem though in that the generic login functions seem to have no way to handle SCRIPT_NAME and I suspect this problem extends to generic views in general. Is there anyway around this? Anyone know if fixing this on the Django roadmap? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---