When I go to edit a user profile and upload a new profile pic it does not show up. Instead I see a broken link with the following error.
Page not found (404)
Request Method: GET
Request URL: http://127.0.0.1:8000/site_media/media/mugshots/4cfb402cad.jpg
Using the URLconf defined in dealr.urls, Django tried these URL patterns, in this order:
^$
^admin/
^accounts/
The current URL, site_media/media/mugshots/4cfb402cad.jpg, didn't match any of these.
What is strange about this is that inside my project folder I actually have /site_media/media/mugshots/ and the exact file that was uploaded (with the same filename), so I'm not sure why it is not displaying the picture. Do I need to do something to my URLS.PY to allow for the viewing of this file? That's the only thing I can think of.
It seems your server cannot find your files. Make sure you have configured your static and media roots in your settings.py (for manage.py runserver).
If you are using a production server you will need to tell it where those directories are.
As an example if you are working with nginx:
server {
[...]
location /static/ {
alias /path/to/my/staticfiles/;
}
}
Related
I have a question about my django settings and nginx in order to display a download link receives in an email generated by a Django view.
1- Context
The emailing part works fine. I can receive this one. In this email I created a link which let to download a file stored in MEDIA folder.
My issue is about the url generated in the email which works with localhost, but not on my testing environment.
2- My code in my local environment
In order to build my download link, I pick up the protocol and domain through :
url = self.request.build_absolute_uri(reverse('home'))
Then, in my message, I created a link like this :
Download link to your export file
In local, it gives me :
http://localhost:8000//download_export/<my_file>/
As you can see, I have a double slashes in my generated url which makes an error.
I solved this issue with :
url = request.build_absolute_uri('/').strip("/")
The urls.py file looks like this :
urlpatterns = [
url(r'^home$', HomeView.as_view(), name='home'),
...
url(r'^download_export/(?P<token>.*)/$', ExportDownloadView.as_view(), name='export_download'),
]
3- My code in my testing environment
In this environment, I'm using nginx as webserver. The application is available from : https://subdomain.domain.fr/dev3/<app_name>/home
The nginx.conf looks like :
location /dev3/<app_name> {
include uwsgi_params;
uwsgi_param SCRIPT_NAME /dev3/<app_name>;
uwsgi_pass unix://var/run/uwsgi/<app_name>.sock;
When I access to the generated download like sent from my testing environment, it gives me an access to :
https://subdomain.domain.fr/download_export/<my_file> and not https://subdomain.domain.fr/dev3/<app_name>/download_export/<my_file>
It misses something ? How I can add this part /dev3/<app_name> ? By default, all other urls access to https://subdomain.domain.fr/dev3/<app_name>/something but not my generated link.
Thank you
EDIT :
In my uwsgi.ini file, I have this both lines :
mount = /dev3/%n=main.wsgi:application
manage-script-name=true
So it should work
You should check media_root in settings.py on your staging environment. Here's a great article on serving media files in Django that might help.
I try to follow tutorial from Udemy,Learning Django from Scratch.I have come to this point
OK,then I change DEBUG in settings file to False.After that at localhost
Not Found
The requested URL / was not found on this server.
Why?
If your question is why you are seeing different response depending on the value of DEBUG, then the answer is that when DEBUG is True, Django will present you with the stack traceback so that you can debug what is going on and fix the problem.
But when the DEBUG is false, it means that your app is live and users can access it. You don't want to show your users all the traceback of your application if some error happens.
If that's not your question, the answer is that you just don't have that path configured in your app.
Hope it helps.
It's simple: there is no rule which match the "/" (root) route.
Add one in your urls module.
See: Django 404 error-page not found
Since there is nothing after localhost:8000, it is trying to look for a url with regex "^/". Your website does not actually have that pattern. The patterns your site does have are provided in the error message "^/store", "^/accounts", etc.
If you were to type localhost:8000/store into the url, it would try and find a matching url following the patterns in the webapp following the "^/store" pattern (presumably named store) store/urls.py.
If you would like to access a page at localhost:8000, you will have to add a new pattern to the list in your root directory's urls.py file.
I have a Django website that uses Nginx on a separate file server to serve up images uploaded by my users. When any user views another user's photos, the link to the photo will have this structure:
https://fs01.mysite.com/media/photos/<username>_<photo-id>.jpg
When the page is rendered, the user's photo is served up by the file server (fs). But what is the Nginx way of handling incomplete (one could also say incorrect) requests to subdirectories of the above URL? For example, if a user enters this URL:
https://fs01.mysite.com
...they see Nginx's default "Welcome to nginx on ..." page. If they enter this URL:
https://fs01.mysite.com/media
...they'll get the Nginx "404 Not Found" page. And if they enter this URL:
https://fs01.mysite.com/media/photos
...they'll get the Nginx "403 Forbidden" page.
How do you handle these situations in Nginx?
They see welcome page, because the nginx matches default vhost entry instead of yours. You should probably delete the default one (/etc/nginx/conf.d/default or /etc/nginx/sites-enabled/default, depending on the linux distribution you use) and make sure that server_name line matches your url (i.e. no slash at the end).
Looks like your location block matckes only media/ (with the slash at the end). Thats why you get 404 error - it matches different location block and is probably handled by Django.
You are not allowed to list the directory, so you get the Forbidden error.
I think that it is up to you how such cases are handled, just make them consistent. Make sure that you understand nginx configuration and the pathways different requests take. To avoid 403 error, you can put empty index.html file in that directory.
Received a notice from google webmaster tools that googles crawler bot has stopped crawling one particular site because of an "Unreachable robots.txt." Unfortunately google doesn't give any additional details about the crawler error beyond that.
I have
<meta name="robots" content="index, follow">
included as one of my meta tags in base.html template, which I do for every django app and I'm not having this problem with any of my other sites. Correct me if I'm wrong but I also thought robots.txt isn't necessary to have for google to index you.
I tried to resolve by installing and configuring django-robots (https://github.com/jezdez/django-robots) and adding this to my url conf:
(r'^robots\.txt$', include('robots.urls')),
My latest google crawler fetch (after pushing django-robots to prod) is still returning the same error though.
I don't have any special crawl rules and would be fine without even including a robots.txt file so google indexes the entire site. Anyone have any thoughts on a quick fix before I just go experiment with the other two methods mentioned here: http://fredericiana.com/2010/06/09/three-ways-to-add-a-robots-txt-to-your-django-project/?
I tried removing the robots.txt line from urls.py completely and fetching as google but that didn't resolve the issue.
(r'^robots\.txt$', include('robots.urls')),
I fixed this by modifying my root urlconf slightly
from django.http import HttpResponse
(r'^robots\.txt$', lambda r: HttpResponse("User-agent: *\nDisallow: /*", mimetype="text/plain")),
now googlebot is crawling it ok. Wish I understood better why this specific solution was effective for me, but it works.
Thanks to Ludwik for the assistance.
if you have permission then
Alias /robots.txt /var/www/---your path ---/PyBot/robots.txt
add alias to your virtual host. (in apache config file )
similarly for favicon
Alias /favicon.ico /var/www/aktel/workspace1/PyBot/PyBot/static/favicon.ico
In deploying a version of the Django website I'm working on to Microsoft's Azure service, I added a page which takes a query string like
http://<my_site_name>.azurewebsites.net/security/user/?username=<some_username>&password=<some_password>
However, I was getting 404 responses to this URL. So I turned on Django's Debug flag and the page I get returned said:
Page not found (404)
Request Method: GET
Request URL: http://<my_site_name>.azurewebsites.net/security/user/?username=<some_username>&password=<some_password>?username=<some_username>&password=<some_password>
Using the `URLconf` defined in `<my_project_name>.urls`, Django tried these URL patterns, in this order:
^$
^security/ ^user/$
^account/
^admin/
^api/
The current URL, `security/user/?username=<some_username>&password=<some_password>`, didn't match any of these.
So it seems to be appending the query string onto the end of the url that already has the same query string. I have the site running on my local machine and on an iis server on my internal network which I'm using for staging before pushing to Azure. Neither of these site deployments do this, so this seems to be something specific to Azure.
Is there something I need to set in the Azure website management interface to prevent it from modifying URLs with query strings? Is there something I'm doing wrong with regards to using query strings with Azure?
In speaking to the providers of wfastcgi.py they told me it may be an issue with wfastcgi.py that is causing this problem. While they look into it they gave me a work around that fixes the issue.
Download the latest copy of wfastcgi.py from http://pytools.codeplex.com/releases
In that file find this part of the code:
if 'HTTP_X_ORIGINAL_URL' in record.params:
# We've been re-written for shared FastCGI hosting, send the original URL as the PATH_INFO.
record.params['PATH_INFO'] = record.params['HTTP_X_ORIGINAL_URL']
And add right below it (still part of the if block):
# PATH_INFO is not supposed to include the query parameters, so remove them
record.params['PATH_INFO'] = record.params['PATH_INFO'].split('?')[0]
Then, upload/deploy this modified file to the Azure site (either use the ftp to put it somewhere or add it to your site deployment. I'm deploying it so that if I need to modify it further its versioned and backed up.
In the Azure management page for the site, go to the site's configure page and change the handler mapping to point to the modified wfastcgi.py file and save the configuration.
i.e. my handler used to be the default D:\python27\scripts\wfastcgi.py. Since I deployed my modified file, the handler path is now: D:\home\site\wwwroot\wfastcgi.py
I also restarted the site, but you may not have to.
This modified script should now strip the query string from PATH_INFO, and urls with query strings should work. I'll be using this until I hear from the wfastcgi.py devs that the default wfastcgi.py file in the Python27 install has been fixed/replaced.