My URLconf has:
url(r'^view-item$', 'appname.views.view_item', name='view-item'),
Now, if I go to http://myhost/path_to_django_app/view-item/, it works. However, {% url view-item %} returns '/view-item/'. Why is it doing this?
This problem occurred when I moved the application to a new server, so I'm guessing something must be configured wrong, but I don't even know where to look.
This may be due to the SCRIPT_NAME variable not being set correctly. The url tag will use this variable to compose the final absolute path to return.
You should check what request.META['SCRIPT_NAME'] is set to in one of your views. If it is not set correctly, then you may need to look into your backend configuration. If you are using mod_python, this usually involves making sure that django.root is set in the apache config. Check the installation docs for more info.
If you still can't get it to work, you can try adding this to settings.py:
FORCE_SCRIPT_NAME = '/path_to_django_app/'
The usual way to write your URl in django is with a trailing '/':
url(r'^view-item/$', 'appname.views.view_item', name='view-item')
or:
url(r'^view-item/', include('view.urls')),
Life will be much easier if you follow this convention.
Related
I use a regex for URL dispatching like described in the Django docs.
r'^remote/(?P<slug>[^/]+)/call_rfc/(?P<rfc_name>.+)$'
Unfortunately rfc_name can start with a slash!
Example:
https://example.com/remote/my_slug/call_rfc//MLK/FOO
The rfc_name is /MLK/FOO.
But this fails. Somewhere (I don't know yet if it is in the browser or in Django) the duplicate slash gets removed.
What is the best practice to handle URL parameters which can start with a slash?
It almost seems that you can consider the latest "slug" as a path. If that's the case, in your URL definition you can use path to represent that. You can have a look here to check if it helps.
path('remote/<slug:slug>/call_rfc/<path:rfc_name>', yourviewhere)
Or, you can perhaps write your custom path converter.
Where can I make changes if I want to make permanent changes in cookie-path value for my website. will that be in context.xml or web.xml or will that be using newCookie.setPath() method only? The server is Tomcat 6.0. I did look online but have not found anything, to the point.
Its just that there is some problem with the session tracking and admin thinks that this requires changing path of my session cookies from /site-folder to /. Is he wrong?
It might not be something considered good programming trick, but to change the sessioncookiepath value, web-app>METAINF>context.xml file is the place. For perticulary my problem, putting following code helped: Context sessionCookiePath="" This might be due to my website structure.
i'm trying to get full path of the requested url in Django. I use a such url pattern:
('^', myawesomeview),
It works good for domain.com/hello, domain.com/hello/sdfsdfsd and even for domain.com/hello.php/sd""^some!bullshit.index.aspx (although, "^" is replaced with "%5E")
But when I try to use # in request (ex. http://127.0.0.1:8000/solid#url) it returns only "/sold". Is there any way to get the full path without ANY changes or replacements?
BTW, I'getting url with return HttpResponse(request.path)
Thanks in advance.
The part of URI separated by '#' sign is called a fragment identifier. Its sense is to be processed on client side only, and not to be passed to server. So if you really need this, you have to process it with JS, for example, and pass it as a usual parameter. Otherwise, this information will never be sent to Django.
I have an entry in my urls.py that acts as a catch-all which loads a simple view if it finds an appropriate page in the database. The problem with this approach is that the URL solver will then never fail, meaning that the APPEND_SLASH functionality won't kick in - which I need.
I'd rather not have to resort to adding a prefix to the static page URLs to stop it being a catch-all. I do know about flatpages, which uses a 404 hook rather than an entry in urls.py, and I had kinda hoped to avoid having to use it, but I guess this problem might be exactly the kind of reason why one would use it.
Any way round this problem or should I just give in and use flatpages?
Make sure that your catch-all URL pattern has a slash at the end, and that the pattern is the last in your URLconf. If the catch-all pattern doesn't end with a slash, then it will match stray URLs before the middleware tries appending a slash.
For example, use r'^.*/$' instead of r'^.*' as your last pattern.
To do the same, but pass the url to the view as a named argument, use r'^(?P<url>.*)/$'.
The statement if it finds an appropriate static page in the database seems like your static pages are not quite static so, you either pass your links through urls.py (just like you do now), or you extract those pages from the DB, put them in a directory and configure that directory as one for serving static files
I'm having a problem with configuring Flatpages in Satchmo. I've used them before, in a pure django app, but now it just doesn't work, returning 301 http error when I'm trying to enter a flatpage-configured site.
What I've done to configure it:
added the middleware "django.contrib.flatpages.middleware.FlatpageFallbackMiddleware" to MIDDLEWARE_CLASSES as last in the list,
configured example pages in admin module.
Simply what the docs say about flatpages config.
I'm feeling helpless. Don't know how could I debug this issue. Any thoughts on that?
And of course help appreciated.
Thanks to suggestion by Peter I've managed to narrow the problem to my urls.py file, for the satchmo shop.
The urlpatterns has only one entry:
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),
This version does not work and moreover interfere with flatpages. But disabling flatpages from MIDDLEWARE_CLASSES and adding it to urls.py like the snippet below works:
(r'^(?P<url>.*)$', 'django.contrib.flatpages.views.flatpage'),
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),
However next problem is with the redirection from / to /shop/. With the above config it results in infinite loop.
Perhaps you know the reason for that behavior (redirect overriding flatpage) and maybe You could suggest some working solution to this problem or what should be done with requests to /.
It returns 301? That's Page Moved Permanently (HttpResponsePermanentRedirect) and there are no references to that in the flatpages directory so I don't think it's coming from there. In fact there are only about 5 references to HttpResponsePermanentRedirect in all of the standard 1.1.1 release.
Possible approaches:
Comment out the FlatPages middleware and see if the error changes (I'm betting it won't).
Try changing the order of your MIDDLEWARE classes and see if things change.
When presenting a problem like this it's better to get very specific by showing the exact code from applicable portions of settings.py (or whatever) and by giving other things like precise URLs and the urls.py patterns you are trying to match.
Update:
OK, some random thoughts:
The pattern (r'^(?P<url>.*)$', 'django.contrib.flatpages.views.flatpage'), will match anything. Any patterns after it will never be seen.
flatpages doesn't work by being called directly, it does its magic in middleware. It looks for 404 responses (Page Not Found) and then looks to see if that path exists in its table. If so, it calls a view that renders the page, etc. etc. If it doesn't find a match it let's the 404 continue on through middleware processing.
The pattern (r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}), will match anything (I just tested it). If you want to match an empty path, use r('^$', etc.). This is the source of your infinite loop.
If you are new to regular expressions the Django urls.py file can seem like F*cking Magic. I recommend starting very simply and add one rule at a time. Do some quick tests to ensure that the new rule a) matches stuff you want it to match, and b) doesn't match stuff it shouldn't. In particular, make sure that some of the rules that occur later in the file are still reachable. In this case they wouldn't have been which should have raised a red flag.