I am using the latest checkout of the django trunk - when I am in the admin on the "change" page for an object/item, there is a nice little link that says "view on site".
The link points to a url such as:
http://example.com:8888/admin/r/22/15/
However, when I click on that link (or enter that link into my browser) I get redirected to:
http://example.com:8888//example.com:8888/video/15
Which isn't a valid url - but it's really, really close ... the same is happening when I try to get_absolute_url for a comment. I get the short little redirect but it doesn't take me to the right page.
Any ideas why this is happening?
Additional Info (edit):
have tried with 1.1.1 (same problem)
I have one site listed under sites which is 'http://example.com:8888'
I thought maybe it had to do with the port number at the end - but what is strange is the my object's get_absolute_url works without a hitch.
I think the problem is coming from django.contrib.contenttypes.views.shortcut which is doing some funny appending business to handle cross-site things ... which I don't quite understand.
get_absolute_url (for objects)
#models.permalink
def get_absolute_url(self):
return ('video_detail', [str(self.id)])
I figured it out: my site's 'domain name' was listed as:
http://example.com
But the 'http' is what is throwing it off. When I removed it and just listed it as:
example.com
It works. I just have to update my email templates to include the 'http', I think ... unless django comes with a built in for adding that in its sites package. Off to investigate ...
Related
I have installed django-comments-xtd following the quick start guide in the documentation here.
When I go to access the /comments URL, I only get a 404 error, and the message 'Raised by: wagtail.wagtailcore.views.serve'.
I followed the documentation without issue, and have installed other apps that work fine such as django-machina.
I am using django 1.11.13, python 2.7 and django-comments-xtd 2.1.0.
Why would this particular URL not be accessible? Templates exist in the correct location.
My files are setup exactly the same as in the documentation, happy to provide more info but not sure what to provide right now.
What can I do to try and troubleshoot the problem?
I think you are misreading the documentation and you do not actually have a problem. It just says:
mount the URL patterns of django_comments_xtd in the path /comments/
It does not say that you should access this URL. The fact that, as per your comment, you are not getting a 404 when you are accessing /comments/sent/ indicates that you have set up django-comments-xtd correctly.
For /comments/ to be a valid URL, the django_comments_xtd.urls you included would have to contain an empty URL pattern, like this:
url('', some_view)
If you look at the urls.py of django-comments-xtd, you will see that it does indeed include the urls.py from django-contrib-comments, but this doesn't define an empty URL pattern. So there is no URL pattern that would match /comments/.
The urls definition from django-comments-xtd will have to come before Wagtail's one (i.e. url(r'', include(wagtail_urls))) as it acts as a catch all and will therefore render other urls unreachable.
just food for thought. The email confirmation template uses
http://{{ site.domain }}{{ confirmation_url|slice:":40" }}...
You want to make sure your site.domain matches whatever your are using for development. This just fixed this error for me. I had a different domain setup in Django Admin
I'm creating an RSS feed that contains application links for the URLs, but Django is prepending the domain name to any link that doesn't begin with http. So, URLs that should be itunes:// are ending up as http://example.comitunes://...
Update:
Because I'm not building the feed based on a model, I'm using the following in the Feed class to create the links. I've verified that they are exactly as they should be when passed to item_link(), but Django appends http://example.com to the front of every link that doesn't begin with http:
def item_link(self, item):
return item['url']
if link is http://foo.com/some_external_domain/, there's no problem.
if link is itunes://some_itunes_store_link, Django turns that into http://example.comitunes://some_itunes_store_link
The domain name is correct. That's not the problem. The problem is that I can't have the domain name prepended to an application link without breaking that link. I can't figure out how to tell Django to stop correcting links that don't need to be corrected.
This isn't possible in Django.
According to Django's feed documentation:
If link doesn’t return the domain, the syndication framework will
insert the domain of the current site, according to your SITE_ID
setting.
My solution was to just build the entire RSS feed manually as a template. It's an unfortunate solution for what should be a simple option in Django feeds, but it works.
if 'HTTP_REFERER' in request.META and 'mysite.com' not in request.META['HTTP_REFERER'] or 'HTTP_REFERER' not in request.META:
return redirect('/')
if HTTP_REFERER is there and if it doesnot contain mysite.com or if HTTP_REFERER not given, it should redirect to startpage.
my code is deployed over 7 servers, scheduled via loadbalancer, the code in all those 7 servers are uptodate. but still, only sometimes, this redirect is not working.
what may I be doing wrong?
the case, where it is not working:
one newssite published a news about my page and pasted a deep link from my page. and I clicked on that link, and it didnot redirect. I got surprised and checked my code, everything was ok, and clicked again on the link and bingo, this time it did redirect me to startpage. I was happy, I thought it may be a caching or smthg. but later, I clicked on the link and the redirect didnot work again. then posted this question. the case is independent of browser type and version.
Firstly, this code could be shortened too:
if 'mysite.com' not in request.META.get('HTTP_REFERER', ''):
return redirect('/')
Secondly, HTTP_REFERER is not guaranteed to be present. It might just be users are using bookmarks, or browser autocomplete which will mean the HTTP_REFERER may or may not be present in the cases you are testing.
If a valid user of the site who uses a bookmark will be redirected. Likewise an invalid user who gets referred from somedomain.com/mysite.com will be redirected. In this case it might be better to use a startwith() when checking the referer. Is there not a better way you can manage what you are trying to do.
Maybe you can update the question with a little more context. I will be willing to help you as best as I can.
I recently upgraded my django framework from 1.3 to 1.4. Today I ran some tests on the login page. I have a switch which determines whether a 'reset password' link should be displayed on the login screen. This test worked nicely under 1.3, but doesn't under 1.4.
I've setup my own view and template for the login page as follows:
urlpatterns = patterns('framework.views',
url(r'^$', 'index'),
url(r'^login/$', 'login_view'),
url(r'^logout/$', 'logout_view'),
...
Upon some further investigation I noticed that if I browse to the login page the first time, it works. If I then remove the entries from my urls.py file (ie the /login/ entries), I can still browse to the /login/ page. Even when I restart the django test server, that url entry is still valid. Even deleting the urls.pyc file doesn't give me a 404. Its only when I try and post, that I'll get a 404. Incidentally, this phenomenon doesn't happen for some of my other urls.
I have a feeling the reason why my tests fail is that django somehow caches the /login/ request in some mysterious way and so the login page never refreshes for each of the tests I run on the screen. Does anybody know how to overcome this problem and perhaps also why it is that this particular feature has changed. Does it have anything to do with the newly implemented template response??
Do you use firefox? Try to remove Firefox cache, or whatever browser's cache you are using...
I ran into the same issue yesterday. I look around and i found a lot of people having this issue. Have a look at this...
Don't blame django as i did in first place ;) (i blamed me later, before knowing the real problem)...
Let's blame the protocol :P
Hope this solves your problem!
EDIT:
Here you have some possible solutions to your problem (if you use firefox):
1) http://support.mozilla.org/es/questions/848678
2) https://superuser.com/questions/23134/how-to-turn-off-firefox-cache
I know there is 404 error handling in django.
But is it better to just put that config in nginx ?
This ST thread has the solution for putting it. -
http://stackoverflow.com/questions/1024199/nginx-customizing-404-page
Is that how everyone handles it when using nginx ?
I have created my own 404.html & 500.html in the sites theme, want to display them.
I didn't know how to configure 404 & 500 errors in django.
Thanks to "namnatulco" who helped me.
Here are the steps:
Create 2 pages 404.html & 500.html
Place them in your modules template folder
In your modules urls.conf, enter these two lines:
handler404 = "myproject.mymodule.views.redirect_page_not_found"
handler500 = "myproject.mymodule.views.redirect_500_error"
In your view, define the functions
def redirect_page_not_found(request):
return render_to_response('logreg/404.html', {}, context_instance=RequestContext(request));
def redirect_500_error(request):
return render_to_response('logreg/500.html', {}, context_instance=RequestContext(request));
Test it by giving some incorrect URL e.g. - www.mydomain.com/aaaaaaaaaaaaaaaa
To test 500 error, inside your view, in your render_to_response, give an incorrect URL.
That's it. You should be set.
You haven't mentioned any reasons why you would want to put these pages in the Nginx server. I would recommend keeping it with the rest of your site, that is, on the Django server. Moving part of your site to the Nginx server is a good idea to solve scalability problem, but complicates your deploy. I certainly hope you aren't seeing a significant fraction of your site's traffic going to your error pages!
I recommend using an in-Django 404/500 handler. You can deliver meaningful alternate nav suggestions in a page style that is consistent with the rest of your site.
Make sure you do not return a page talking about the error but sporting a 200 return status -- human will understand it's an error, but programmatic access will not. I'm avoiding saying "search engines" here, but the truth is that they will probably represent 98%+ of your non-human visitors. See HttpResponse subclasses for details.