What I'm looking for is a piece of Django middleware that catches a FileNotFound exception and attempts to rsync the file from the production webserver. This way you can develop your site with a copy of production data without having to continually rsync down all the uploaded files.
I'm sure I've seen a solution to this problem on the internets, but hours of Googleing have so far produced nothing. Anyone know of where to find this?
The code I'd seen before is this:
http://menendez.com/blog/using-django-as-pass-through-image-proxy/
which doesn't catch the FileNotFound error, but the Http404 error, and then loads images from the live server. Unfortunately this doesn't fix the issue of FileNotFound when trying to read images off disk (for sizes etc).
Related
I've made a desktop app in Python to process .xls files with openpyxl, tkinter and other stuff. Now i'm looking to run this App on www.pythonanywhere.com. I was expecting to make an app to upload the file to the server, process it and then retrieve it changed to the user. But after long months struggling with Django i`ve reached the problem of static media. As I understood Django doesn’t serve files in production mode. Does this means that I can’t upload-process-download as I was planning? Or I can run in the view function the process algorithm on the request.file and then retrieve it changed, regardless of not serving static files? Am I missing something? Does Flask has the same issue? What’s the optimal solution? Apologize me for the many doubts.
PD: I took the time to read many similar questions and seems to be possible to upload and download, but then im missing something on handling static files and what that means
How can i get django to process media files on production when DEBUG = False on heroku server?
I know that it’s better not to do this and that this will lead to a loss of performance, but my application is used only by me and my cat, so I don't think that this will be unjustified in my case.
The reason this won't work is because the Heroku file system is ephemeral, meaning any files uploaded after your app code is pushed will be overwritten anytime your app is restarted. This will leave your app with image links in the DB which lead to non-existent files.
You can read more about it here:
https://help.heroku.com/K1PPS2WM/why-are-my-file-uploads-missing-deleted
Your best bet is using a bucket like Amazon S3 to upload your files to. It costs almost nothing for small use, and is very reliable.
https://blog.theodo.com/2019/07/aws-s3-upload-django/
I'm in the middle of migrating a Django project to Python 3 and updating several dependencies along the way.
Right now, I'm using Django 2.2.3.
After putting the code on the staging server I noticed that all responses are returned as bytestring literals:
b'<html>\n...'
This was very hard to narrow down because I first noticed it only on the staging server. Luckily I found out that this has nothing to do with NGINX nor Gunicorn but that DEBUG=True is actually the culprit.
The question is: what does DEBUG=True trigger that is messing up the response?
It took me a several hour long train ride to figure out but I finally found the root cause:
Going over my settings file looking for something where processing changes drastically between DEBUG=False and DEBUG=True, django-pipeline's MinifyHTMLMiddleware caught my eye. Disabling it does help indeed.
An issue about it has been opened back in May already, but I couldn't find it via Google. Hopefully this answer will help someone out there.
I have a sent file that keeps growing on my staging server. It stores a log of all emails sent and I don't know what's causing this behaviour, it doesn't look like a feature from the Django framework (1.8).
I can't find any reference of this log file in the source code. It's an issue for several reasons, including the fact that it causes the server to run out of disk space.
Maybe I'm missing something obvious in the Django config. I don't see how to fix this issue besides running a cron task to delete that file regularly. I'm open to better ideas.
Since I updated my production setup to Wagtail 1.11 I cannot load the admin page for images. Visiting /admin/images/ results in a 502 error. In my development setup I don't have the same problem
This is the result of a crash of the runner. The memory and CPU usage of the runners gets too high for the server to handle at which point they are killed. (Seen in top and restarts are shown in the logs)
This seems to be the same as https://github.com/wagtail/wagtail/issues/3575, but Wand is not used and no GIF images are uploaded to the system so this is not the cause. The following seemingly relevant python packages are used:
Django==1.11.3
gunicorn==19.7.1
Pillow==4.2.1
wagtail==1.11.1
Willow==0.4
The project is running on a fully updated Ubuntu 16.04 machine.
Does anyone have a suggestion of what can fix this bug?
Try removing some of the more recent or larger images and reloading the page. The problem could be the result of a corrupt or malicious image.
The easiest way to diagnose if this is the problem is to:
Move all images from the media/original_images folder to a backup folder.
Access the /admin/images page. If this was the problem the page should now load again.
Note all images that now do not have a thumbnail; these are the pictures crashing the application.
Move all picture except for the ones noted back into the media/original_images folder.
Except for the picture crashing your system, everything should now work similar to what it did before.