Re: reverse drops the project from the url returned
Another way that people can screw up SCRIPT_NAME determination in a
server is not to use WSGIScriptAlias, but use WSGIScriptAliasMatch and
not use it properly.
So, please post the actual Apache configuration snippet you are using
to map you Django application with mod_wsgi so can verify that the
configuration you are using is in fact correct.
Normally WebFaction recipes should create it correctly, but if you
have hand crafted it and followed one of the incorrect blog posts out
there about it, you could have problems.
Graham
On Jan 4, 6:23 pm, Graham Dumpleton
wrote:
> On Jan 4, 12:45 pm, davathar wrote:
>
>
>
>
>
> > Here's more information I've been able to find. Evidently there's a
> > problem in some configurations wheremod_wsgieither isn't receiving
> > or isn't passing SCRIPT_NAME.
>
> > When I use this test script in the wsgi file I get an empty string as
> > the value for SCRIPT_NAME. And from what I gather that's where /
> > helpdesk should be so it can be passed to django so it's aware of the
> > full path.
>
> > **
> > import cStringIO
>
> > def application(environ, start_response):
> > headers = []
> > headers.append(('Content-Type', 'text/plain'))
> > write = start_response('200 OK', headers)
>
> > input = environ['wsgi.input']
> > output = cStringIO.StringIO()
>
> > keys = environ.keys()
> > keys.sort()
> > for key in keys:
> > print >> output, '%s: %s' % (key, repr(environ[key]))
> > print >> output
>
> > output.write(input.read(int(environ.get('CONTENT_LENGTH', '0'
>
> > return [output.getvalue()]
> > *
>
> > So it may not be as much a django issue as an apache/wsgi one. I'm
> > not skilled enough to make that distinction though. For now I'm just
> > going to serve the app from the root and move it when I learn more or
> > the issue is fixed.
>
> > I tested the admin module and I get the same problem. Wherever the /
> > helpdesk is present in the URL everything serves properly. But when I
> > post a form, it's dropped from the path and I get "There is no
> > application mounted at the root of this domain. " because I have
> > nothing mounted at the root. I assume that message is served by
> > apache.
>
> > My host Webfaction uses multiple apache applications where the first
> > one is shared for the server. I don't get direct access to the
> > settings for this. Only control panel access which may make some
> > changes indirectly. I think it uses settings or maybe
> > SymLinks? to forward the request to another instance of apache that is
> > installed with Django on my share of the server. I have total control
> > of that apache. So, perhaps the first apache isn't passing any value
> > to the second one to indicate the first "mount point" is present.
> > This would be the "SCRIPT_NAME" from what I gather.
>
> Unless you are on an old server build, WebFaction uses nginx as front
> end, not Apache.
>
> In either case, the front end mount point isn't passed across. For it
> all to work properly, the front end mount point must match the backend
> mount point. You cannot mount on front end as /helpdesk and then have
> it proxy to / on backend for example. The backend must be mounted at /
> helpdesk as well.
>
> In respect of prior discussion, did you disable mod_rewrite in backend
> Apache?
>
> Graham
>
>
>
> > Yet another manifestation of the issue can be found by leaving off the
> > trailing slash at the end of the url : example.com/helpdesk/support/
> > case/1 will automatically redirect to example.com/support/case/1/ as
> > django adds the slash but drops the /helpdesk
>
> > ...com/helpdesk results in "There is no application mounted at the
> > root of this domain. "
>
> > com/helpdesk/ renders the app since my root urls.py contains "(r'^
> > $', 'helpdesk.support.views.home')," to call the support app home
> > view.
>
> > I hope some of this information helps. In the mean time all the work
> > I've had to do to "move" my code to the root has completely convinced
> > me of the wisdom of decoupling. ;-) And at the same time the reason
> > I'm even having the trouble is because of the use of functions like
> > reverse to avoid hard coding views and templates to urls!
>
> > Thanks for your feedback.
>
> > On Jan 3, 5:50 pm, Karen Tracey wrote:
>
> > > On Sun, Jan 3, 2010 at 5:15 PM, davathar wrote:
> > > > Ramiro, thanks for the links. That other thread does seem to describe
> > > > the same problem and results in it being identified as a bug in the
> > > > core urlresolvers. Unfortunately the work around of "RewriteRule ^/
> > > > studio$ /studio/ [R] " doesn't work for me for some reason. Maybe I'm
> > > > misapplying it.
>
> > > > Either way. I'm going to drop this for now and see what happens with
> > > > the ticket that was opened. It seems like this would be a very big
> > > > issue if everyone usingmod_wsgihad problems when using django from
> > > > anywhere other than th
Re: reverse drops the project from the url returned
On Jan 4, 12:45 pm, davathar wrote:
> Here's more information I've been able to find. Evidently there's a
> problem in some configurations wheremod_wsgieither isn't receiving
> or isn't passing SCRIPT_NAME.
>
> When I use this test script in the wsgi file I get an empty string as
> the value for SCRIPT_NAME. And from what I gather that's where /
> helpdesk should be so it can be passed to django so it's aware of the
> full path.
>
> **
> import cStringIO
>
> def application(environ, start_response):
> headers = []
> headers.append(('Content-Type', 'text/plain'))
> write = start_response('200 OK', headers)
>
> input = environ['wsgi.input']
> output = cStringIO.StringIO()
>
> keys = environ.keys()
> keys.sort()
> for key in keys:
> print >> output, '%s: %s' % (key, repr(environ[key]))
> print >> output
>
> output.write(input.read(int(environ.get('CONTENT_LENGTH', '0'
>
> return [output.getvalue()]
> *
>
> So it may not be as much a django issue as an apache/wsgi one. I'm
> not skilled enough to make that distinction though. For now I'm just
> going to serve the app from the root and move it when I learn more or
> the issue is fixed.
>
> I tested the admin module and I get the same problem. Wherever the /
> helpdesk is present in the URL everything serves properly. But when I
> post a form, it's dropped from the path and I get "There is no
> application mounted at the root of this domain. " because I have
> nothing mounted at the root. I assume that message is served by
> apache.
>
> My host Webfaction uses multiple apache applications where the first
> one is shared for the server. I don't get direct access to the
> settings for this. Only control panel access which may make some
> changes indirectly. I think it uses settings or maybe
> SymLinks? to forward the request to another instance of apache that is
> installed with Django on my share of the server. I have total control
> of that apache. So, perhaps the first apache isn't passing any value
> to the second one to indicate the first "mount point" is present.
> This would be the "SCRIPT_NAME" from what I gather.
Unless you are on an old server build, WebFaction uses nginx as front
end, not Apache.
In either case, the front end mount point isn't passed across. For it
all to work properly, the front end mount point must match the backend
mount point. You cannot mount on front end as /helpdesk and then have
it proxy to / on backend for example. The backend must be mounted at /
helpdesk as well.
In respect of prior discussion, did you disable mod_rewrite in backend
Apache?
Graham
> Yet another manifestation of the issue can be found by leaving off the
> trailing slash at the end of the url : example.com/helpdesk/support/
> case/1 will automatically redirect to example.com/support/case/1/ as
> django adds the slash but drops the /helpdesk
>
> ...com/helpdesk results in "There is no application mounted at the
> root of this domain. "
>
> com/helpdesk/ renders the app since my root urls.py contains "(r'^
> $', 'helpdesk.support.views.home')," to call the support app home
> view.
>
> I hope some of this information helps. In the mean time all the work
> I've had to do to "move" my code to the root has completely convinced
> me of the wisdom of decoupling. ;-) And at the same time the reason
> I'm even having the trouble is because of the use of functions like
> reverse to avoid hard coding views and templates to urls!
>
> Thanks for your feedback.
>
> On Jan 3, 5:50 pm, Karen Tracey wrote:
>
>
>
> > On Sun, Jan 3, 2010 at 5:15 PM, davathar wrote:
> > > Ramiro, thanks for the links. That other thread does seem to describe
> > > the same problem and results in it being identified as a bug in the
> > > core urlresolvers. Unfortunately the work around of "RewriteRule ^/
> > > studio$ /studio/ [R] " doesn't work for me for some reason. Maybe I'm
> > > misapplying it.
>
> > > Either way. I'm going to drop this for now and see what happens with
> > > the ticket that was opened. It seems like this would be a very big
> > > issue if everyone usingmod_wsgihad problems when using django from
> > > anywhere other than the root url. But there are few posts about it.
> > > So I'm going to start over and see if I missed something critical in
> > > my setup.
>
> > Just to clarify, though it is clear you've already found it, the ticket to
> > watch for the problem identified in that thread is:
>
> >http://code.djangoproject.com/ticket/12464
>
> > The other one (#9435) mentioned earlier describes a somewhat different
> > problem. The thread and ticket #12464 show a problem determining the script
> > name only when the PATH_INFO for the current request is completely empty.
> > So reverse called from (or url tag in a template rendered by) the view that
> > handles the root page sees a problem, when it is called as a result of a a
> > request for (in your case):
Re: reverse drops the project from the url returned
Here's more information I've been able to find. Evidently there's a
problem in some configurations where mod_wsgi either isn't receiving
or isn't passing SCRIPT_NAME.
When I use this test script in the wsgi file I get an empty string as
the value for SCRIPT_NAME. And from what I gather that's where /
helpdesk should be so it can be passed to django so it's aware of the
full path.
**
import cStringIO
def application(environ, start_response):
headers = []
headers.append(('Content-Type', 'text/plain'))
write = start_response('200 OK', headers)
input = environ['wsgi.input']
output = cStringIO.StringIO()
keys = environ.keys()
keys.sort()
for key in keys:
print >> output, '%s: %s' % (key, repr(environ[key]))
print >> output
output.write(input.read(int(environ.get('CONTENT_LENGTH', '0'
return [output.getvalue()]
*
So it may not be as much a django issue as an apache/wsgi one. I'm
not skilled enough to make that distinction though. For now I'm just
going to serve the app from the root and move it when I learn more or
the issue is fixed.
I tested the admin module and I get the same problem. Wherever the /
helpdesk is present in the URL everything serves properly. But when I
post a form, it's dropped from the path and I get "There is no
application mounted at the root of this domain. " because I have
nothing mounted at the root. I assume that message is served by
apache.
My host Webfaction uses multiple apache applications where the first
one is shared for the server. I don't get direct access to the
settings for this. Only control panel access which may make some
changes indirectly. I think it uses settings or maybe
SymLinks? to forward the request to another instance of apache that is
installed with Django on my share of the server. I have total control
of that apache. So, perhaps the first apache isn't passing any value
to the second one to indicate the first "mount point" is present.
This would be the "SCRIPT_NAME" from what I gather.
Yet another manifestation of the issue can be found by leaving off the
trailing slash at the end of the url : example.com/helpdesk/support/
case/1 will automatically redirect to example.com/support/case/1/ as
django adds the slash but drops the /helpdesk
...com/helpdesk results in "There is no application mounted at the
root of this domain. "
com/helpdesk/ renders the app since my root urls.py contains "(r'^
$', 'helpdesk.support.views.home')," to call the support app home
view.
I hope some of this information helps. In the mean time all the work
I've had to do to "move" my code to the root has completely convinced
me of the wisdom of decoupling. ;-) And at the same time the reason
I'm even having the trouble is because of the use of functions like
reverse to avoid hard coding views and templates to urls!
Thanks for your feedback.
On Jan 3, 5:50 pm, Karen Tracey wrote:
> On Sun, Jan 3, 2010 at 5:15 PM, davathar wrote:
> > Ramiro, thanks for the links. That other thread does seem to describe
> > the same problem and results in it being identified as a bug in the
> > core urlresolvers. Unfortunately the work around of "RewriteRule ^/
> > studio$ /studio/ [R] " doesn't work for me for some reason. Maybe I'm
> > misapplying it.
>
> > Either way. I'm going to drop this for now and see what happens with
> > the ticket that was opened. It seems like this would be a very big
> > issue if everyone using mod_wsgi had problems when using django from
> > anywhere other than the root url. But there are few posts about it.
> > So I'm going to start over and see if I missed something critical in
> > my setup.
>
> Just to clarify, though it is clear you've already found it, the ticket to
> watch for the problem identified in that thread is:
>
> http://code.djangoproject.com/ticket/12464
>
> The other one (#9435) mentioned earlier describes a somewhat different
> problem. The thread and ticket #12464 show a problem determining the script
> name only when the PATH_INFO for the current request is completely empty.
> So reverse called from (or url tag in a template rendered by) the view that
> handles the root page sees a problem, when it is called as a result of a a
> request for (in your case):
>
> ...com/helpdesk
>
> but not:
>
> com/helpdesk/
>
> because in the 2nd case PATH_INFO is not empty, it is '/'.
>
> Based on the urls you were mentioning earlier in the thread it wasn't clear
> whether the problem with reverse, in your case, is limited to reversals
> attempted while serving the root (for your project) page, when requested
> without a trailing slash. If the rewrite rule is not working, then I
> suspect you are seeing a different problem, but I don't know what is causing
> it. I have been able to mount Django projects not at the root of the URL
> tree with Apache/mod_wsgi, and reverse works correctly.
>
> Do the links within admin work? That was one curiosi
Re: reverse drops the project from the url returned
On Sun, Jan 3, 2010 at 5:15 PM, davathar wrote: > Ramiro, thanks for the links. That other thread does seem to describe > the same problem and results in it being identified as a bug in the > core urlresolvers. Unfortunately the work around of "RewriteRule ^/ > studio$ /studio/ [R] " doesn't work for me for some reason. Maybe I'm > misapplying it. > > Either way. I'm going to drop this for now and see what happens with > the ticket that was opened. It seems like this would be a very big > issue if everyone using mod_wsgi had problems when using django from > anywhere other than the root url. But there are few posts about it. > So I'm going to start over and see if I missed something critical in > my setup. > > Just to clarify, though it is clear you've already found it, the ticket to watch for the problem identified in that thread is: http://code.djangoproject.com/ticket/12464 The other one (#9435) mentioned earlier describes a somewhat different problem. The thread and ticket #12464 show a problem determining the script name only when the PATH_INFO for the current request is completely empty. So reverse called from (or url tag in a template rendered by) the view that handles the root page sees a problem, when it is called as a result of a a request for (in your case): ...com/helpdesk but not: com/helpdesk/ because in the 2nd case PATH_INFO is not empty, it is '/'. Based on the urls you were mentioning earlier in the thread it wasn't clear whether the problem with reverse, in your case, is limited to reversals attempted while serving the root (for your project) page, when requested without a trailing slash. If the rewrite rule is not working, then I suspect you are seeing a different problem, but I don't know what is causing it. I have been able to mount Django projects not at the root of the URL tree with Apache/mod_wsgi, and reverse works correctly. Do the links within admin work? That was one curiosity noted in the earlier thread (admin links did work) that pointed toward the fact that the problem was only when serving the root page. Karen -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: reverse drops the project from the url returned
Ramiro, thanks for the links. That other thread does seem to describe
the same problem and results in it being identified as a bug in the
core urlresolvers. Unfortunately the work around of "RewriteRule ^/
studio$ /studio/ [R] " doesn't work for me for some reason. Maybe I'm
misapplying it.
Either way. I'm going to drop this for now and see what happens with
the ticket that was opened. It seems like this would be a very big
issue if everyone using mod_wsgi had problems when using django from
anywhere other than the root url. But there are few posts about it.
So I'm going to start over and see if I missed something critical in
my setup.
Thank you -Shane
On Jan 3, 3:01 pm, Ramiro Morales wrote:
> On Sun, Jan 3, 2010 at 4:44 PM, davathar wrote:
> > Thank you for the responses so far. But I still haven't identified
> > the solution to this seemingly simple issue.
>
> > The behavior also happens when I use the URL tag in a template like
> > this "{% url case_url case.id %}" the result I get is "/support/case/
> > 1/ ".
>
> > So the inconsistency is that when I make a request for "http://
> >www.example.com/helpdesk/support/1/" django is correctly mapping to
> > the "case" view. But while processing the "case" view and explicitly
> > naming the "case_url" that points to it, any reverse lookups are not
> > returning the correct URL.
>
> > To me it looks like a bug since I would think it would work both ways
> > or neither.
>
> > I think it may have to do with my switch to django 1.1.1 and mod_wsgi
> > from an older 1.x version with mod_python.
>
> > When using mod_python, this was handled like so:
>
> >
> > SetHandler python-program
> > PythonHandler django.core.handlers.modpython
> > SetEnv DJANGO_SETTINGS_MODULE mysite.settings
> > PythonOption django.root /mysite
> > PythonDebug On
> >
>
> > But according to this:
> > http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
> > "Note that the django.root option introduced in Django 1.0 alpha
> > versions does not apply to mod_wsgi and is only necessary with
> > mod_python, due to mod_python not setting SCRIPT_NAME correctly. "
>
> > So where does that leave us? does mod_wsgi need some other
> > configuration?
>
> I'd suggest to read this recent django-users thread:
>
> http://groups.google.com/group/django-users/browse_frm/thread/ce14366...
>
> that point to this Django ticket:
>
> http://code.djangoproject.com/ticket/9435
>
> Another suggestion: Ty dropping the project name from all the imports
> and view names
> when setting your mod_wsgi deployment, just make sure themodules containing
> your
> settings.py, urls.py and all your apps are in the python module search path.
>
> HTH,
>
> --
> Ramiro Morales | http://rmorales.net
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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: reverse drops the project from the url returned
On Sun, Jan 3, 2010 at 4:44 PM, davathar wrote:
> Thank you for the responses so far. But I still haven't identified
> the solution to this seemingly simple issue.
>
> The behavior also happens when I use the URL tag in a template like
> this "{% url case_url case.id %}" the result I get is "/support/case/
> 1/ ".
>
> So the inconsistency is that when I make a request for "http://
> www.example.com/helpdesk/support/1/" django is correctly mapping to
> the "case" view. But while processing the "case" view and explicitly
> naming the "case_url" that points to it, any reverse lookups are not
> returning the correct URL.
>
> To me it looks like a bug since I would think it would work both ways
> or neither.
>
> I think it may have to do with my switch to django 1.1.1 and mod_wsgi
> from an older 1.x version with mod_python.
>
> When using mod_python, this was handled like so:
>
>
> SetHandler python-program
> PythonHandler django.core.handlers.modpython
> SetEnv DJANGO_SETTINGS_MODULE mysite.settings
> PythonOption django.root /mysite
> PythonDebug On
>
>
> But according to this:
> http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
> "Note that the django.root option introduced in Django 1.0 alpha
> versions does not apply to mod_wsgi and is only necessary with
> mod_python, due to mod_python not setting SCRIPT_NAME correctly. "
>
> So where does that leave us? does mod_wsgi need some other
> configuration?
I'd suggest to read this recent django-users thread:
http://groups.google.com/group/django-users/browse_frm/thread/ce1436670a3c55d5?hl=en
that point to this Django ticket:
http://code.djangoproject.com/ticket/9435
Another suggestion: Ty dropping the project name from all the imports
and view names
when setting your mod_wsgi deployment, just make sure themodules containing your
settings.py, urls.py and all your apps are in the python module search path.
HTH,
--
Ramiro Morales | http://rmorales.net
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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: reverse drops the project from the url returned
Thank you for the responses so far. But I still haven't identified
the solution to this seemingly simple issue.
The behavior also happens when I use the URL tag in a template like
this "{% url case_url case.id %}" the result I get is "/support/case/
1/ ".
So the inconsistency is that when I make a request for "http://
www.example.com/helpdesk/support/1/" django is correctly mapping to
the "case" view. But while processing the "case" view and explicitly
naming the "case_url" that points to it, any reverse lookups are not
returning the correct URL.
To me it looks like a bug since I would think it would work both ways
or neither.
I think it may have to do with my switch to django 1.1.1 and mod_wsgi
from an older 1.x version with mod_python.
When using mod_python, this was handled like so:
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonOption django.root /mysite
PythonDebug On
But according to this:
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
"Note that the django.root option introduced in Django 1.0 alpha
versions does not apply to mod_wsgi and is only necessary with
mod_python, due to mod_python not setting SCRIPT_NAME correctly. "
So where does that leave us? does mod_wsgi need some other
configuration?
On Jan 2, 10:25 pm, davathar wrote:
> Bill: Tried that, but it made no difference. case is resolving ok.
> The problem is with the first part "/helpdesk/" dropping off when
> doing a reverse. The same behavior happens when I use the URL tag in
> a template. "{% url case_url case.id %}" I get /support/case/1/
> without the /helpdesk in front of it.
>
> I'm pretty sure this is because I installed Django to be served not
> from the root, but rather from /helpdesk/. I use WebFaction as a
> host, and their control panel is where this is setup. I think it uses
> SymLinks to direct the shared Apache to the private one that only
> serves my Django app. But I'm not sure and can't find a way to tell
> for sure. There's nothing currently in the any of the Django files
> that refers to /helpdesk/ as part of the url. Yet the webserver
> resolves it properly with /helpdesk/ there and not without it.
>
> So I think that the first Apache server is resolving the /helpdesk/
> portion of the url and then forwarding everything after that to be
> handled by Django. So maybe django doesn't know about /helpdesk/
> internally.
>
> Surely I'm not the only person who setup django to serve from a sub
> url. And WebFaction is a popular Django host. There must be some
> simple setting I'm missing somewhere. Does anyone know what it is?
>
> Thank you in advance.
>
> On Dec 30 2009, 11:37 am, Bill Freeman wrote:
>
> > Since your urlconf is passing "case" as a named (keyword) argument, you
> > (may) have to pass it that way to reverse:
>
> > ...reverse('case_url', kwargs={'case':case.id})...
>
> > Bill
>
> > On Mon, Dec 28, 2009 at 8:22 PM, davathar wrote:
> > > I'm stuck on a "reverse" problem. The 'case' view is supposed to
> > > record posted info, then reload the same page. But it's dropping the
> > > first part of the URL on the redirect and I've not been able to figure
> > > out why.
>
> > > It should be going to .com/helpdesk/support/case/1/ But it's going
> > > to .com/support/case/1/
>
> > > I'm sure it's something simple as I've had the problem in the past and
> > > fumbled my way through it. But I can't find it this time. Hopefully
> > > the below pasted lines show all the necessary detail.
>
> > > Anyone see my error?
>
> > > helpdesk.urls:
> > > urlpatterns = patterns('',
> > > (r'^support/', include('helpdesk.support.urls')),
> > > )
>
> > > helpdesk.support.urls:
> > > urlpatterns = patterns('helpdesk.support.views',
> > > (r'^case/(?P\d+)/$', 'case',{},'case_url' ),
> > > )
>
> > > helpdesk.support.views:
> > > def case(request, case):
> > > return HttpResponseRedirect(reverse('case_url', args=(case.id,)))
> > > # Redirect back here after POST
>
> > > -Shane
>
> > > --
>
> > > You received this message because you are subscribed to the Google Groups
> > > "Django users" group.
> > > To post to this group, send email to django-us...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > django-users+unsubscr...@googlegroups.com.
> > > For more options, visit this group
> > > athttp://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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: reverse drops the project from the url returned
Bill: Tried that, but it made no difference. case is resolving ok.
The problem is with the first part "/helpdesk/" dropping off when
doing a reverse. The same behavior happens when I use the URL tag in
a template. "{% url case_url case.id %}" I get /support/case/1/
without the /helpdesk in front of it.
I'm pretty sure this is because I installed Django to be served not
from the root, but rather from /helpdesk/. I use WebFaction as a
host, and their control panel is where this is setup. I think it uses
SymLinks to direct the shared Apache to the private one that only
serves my Django app. But I'm not sure and can't find a way to tell
for sure. There's nothing currently in the any of the Django files
that refers to /helpdesk/ as part of the url. Yet the webserver
resolves it properly with /helpdesk/ there and not without it.
So I think that the first Apache server is resolving the /helpdesk/
portion of the url and then forwarding everything after that to be
handled by Django. So maybe django doesn't know about /helpdesk/
internally.
Surely I'm not the only person who setup django to serve from a sub
url. And WebFaction is a popular Django host. There must be some
simple setting I'm missing somewhere. Does anyone know what it is?
Thank you in advance.
On Dec 30 2009, 11:37 am, Bill Freeman wrote:
> Since your urlconf is passing "case" as a named (keyword) argument, you
> (may) have to pass it that way to reverse:
>
> ...reverse('case_url', kwargs={'case':case.id})...
>
> Bill
>
> On Mon, Dec 28, 2009 at 8:22 PM, davathar wrote:
> > I'm stuck on a "reverse" problem. The 'case' view is supposed to
> > record posted info, then reload the same page. But it's dropping the
> > first part of the URL on the redirect and I've not been able to figure
> > out why.
>
> > It should be going to .com/helpdesk/support/case/1/ But it's going
> > to .com/support/case/1/
>
> > I'm sure it's something simple as I've had the problem in the past and
> > fumbled my way through it. But I can't find it this time. Hopefully
> > the below pasted lines show all the necessary detail.
>
> > Anyone see my error?
>
> > helpdesk.urls:
> > urlpatterns = patterns('',
> > (r'^support/', include('helpdesk.support.urls')),
> > )
>
> > helpdesk.support.urls:
> > urlpatterns = patterns('helpdesk.support.views',
> > (r'^case/(?P\d+)/$', 'case',{},'case_url' ),
> > )
>
> > helpdesk.support.views:
> > def case(request, case):
> > return HttpResponseRedirect(reverse('case_url', args=(case.id,)))
> > # Redirect back here after POST
>
> > -Shane
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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: reverse drops the project from the url returned
Since your urlconf is passing "case" as a named (keyword) argument, you
(may) have to pass it that way to reverse:
...reverse('case_url', kwargs={'case':case.id})...
Bill
On Mon, Dec 28, 2009 at 8:22 PM, davathar wrote:
> I'm stuck on a "reverse" problem. The 'case' view is supposed to
> record posted info, then reload the same page. But it's dropping the
> first part of the URL on the redirect and I've not been able to figure
> out why.
>
> It should be going to .com/helpdesk/support/case/1/ But it's going
> to .com/support/case/1/
>
> I'm sure it's something simple as I've had the problem in the past and
> fumbled my way through it. But I can't find it this time. Hopefully
> the below pasted lines show all the necessary detail.
>
> Anyone see my error?
>
> helpdesk.urls:
> urlpatterns = patterns('',
> (r'^support/', include('helpdesk.support.urls')),
> )
>
> helpdesk.support.urls:
> urlpatterns = patterns('helpdesk.support.views',
> (r'^case/(?P\d+)/$', 'case',{},'case_url' ),
> )
>
> helpdesk.support.views:
> def case(request, case):
> return HttpResponseRedirect(reverse('case_url', args=(case.id,)))
> # Redirect back here after POST
>
> -Shane
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@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.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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: reverse drops the project from the url returned
I'm using mod_wsgi. which contains this to point to settings:
os.environ['DJANGO_SETTINGS_MODULE'] = 'helpdesk.settings'
application = WSGIHandler()
My settings.py has:
#
ROOT_URLCONF = 'helpdesk.urls'
#
INSTALLED_APPS = (
#
'helpdesk.support',
#
)
If I manually key in example.com/helpdesk/support/case/1/ it renders
the correct view. It's only on the redirect that I'm having trouble.
I've got django installed as an app at example.com/helpdesk/ so it's
not on the root. And I suspect this is related to the cause. But I
can't find where.
What I can't wrap my head around is that the url works when keyed in,
but won't reverse to the same thing.
On Dec 29, 12:35 am, Raja wrote:
> Are you running it through a mod-python handler? From your urls.py, it
> looks like it would handle ^support as the first level match and then
> continue for "/case", so the reverse URL seems to be correct, i.e. /
> support/case/1.
>
> How are you tacking the "/helpdesk" to your request initially?
>
> On Dec 29, 6:22 am, davathar wrote:
>
> > I'm stuck on a "reverse" problem. The 'case' view is supposed to
> > record posted info, then reload the same page. But it's dropping the
> > first part of the URL on the redirect and I've not been able to figure
> > out why.
>
> > It should be going to .com/helpdesk/support/case/1/ But it's going
> > to .com/support/case/1/
>
> > I'm sure it's something simple as I've had the problem in the past and
> > fumbled my way through it. But I can't find it this time. Hopefully
> > the below pasted lines show all the necessary detail.
>
> > Anyone see my error?
>
> > helpdesk.urls:
> > urlpatterns = patterns('',
> > (r'^support/', include('helpdesk.support.urls')),
> > )
>
> > helpdesk.support.urls:
> > urlpatterns = patterns('helpdesk.support.views',
> > (r'^case/(?P\d+)/$', 'case',{},'case_url' ),
> > )
>
> > helpdesk.support.views:
> > def case(request, case):
> > return HttpResponseRedirect(reverse('case_url', args=(case.id,)))
> > # Redirect back here after POST
>
> > -Shane
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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: reverse drops the project from the url returned
Are you running it through a mod-python handler? From your urls.py, it
looks like it would handle ^support as the first level match and then
continue for "/case", so the reverse URL seems to be correct, i.e. /
support/case/1.
How are you tacking the "/helpdesk" to your request initially?
On Dec 29, 6:22 am, davathar wrote:
> I'm stuck on a "reverse" problem. The 'case' view is supposed to
> record posted info, then reload the same page. But it's dropping the
> first part of the URL on the redirect and I've not been able to figure
> out why.
>
> It should be going to .com/helpdesk/support/case/1/ But it's going
> to .com/support/case/1/
>
> I'm sure it's something simple as I've had the problem in the past and
> fumbled my way through it. But I can't find it this time. Hopefully
> the below pasted lines show all the necessary detail.
>
> Anyone see my error?
>
> helpdesk.urls:
> urlpatterns = patterns('',
> (r'^support/', include('helpdesk.support.urls')),
> )
>
> helpdesk.support.urls:
> urlpatterns = patterns('helpdesk.support.views',
> (r'^case/(?P\d+)/$', 'case',{},'case_url' ),
> )
>
> helpdesk.support.views:
> def case(request, case):
> return HttpResponseRedirect(reverse('case_url', args=(case.id,)))
> # Redirect back here after POST
>
> -Shane
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
reverse drops the project from the url returned
I'm stuck on a "reverse" problem. The 'case' view is supposed to
record posted info, then reload the same page. But it's dropping the
first part of the URL on the redirect and I've not been able to figure
out why.
It should be going to .com/helpdesk/support/case/1/ But it's going
to .com/support/case/1/
I'm sure it's something simple as I've had the problem in the past and
fumbled my way through it. But I can't find it this time. Hopefully
the below pasted lines show all the necessary detail.
Anyone see my error?
helpdesk.urls:
urlpatterns = patterns('',
(r'^support/', include('helpdesk.support.urls')),
)
helpdesk.support.urls:
urlpatterns = patterns('helpdesk.support.views',
(r'^case/(?P\d+)/$', 'case',{},'case_url' ),
)
helpdesk.support.views:
def case(request, case):
return HttpResponseRedirect(reverse('case_url', args=(case.id,)))
# Redirect back here after POST
-Shane
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
