Django-respondive-images dosen't find files when not in local - django

i use responsive-images https://pypi.org/project/django-responsive-images/
on my PC django works well and also django-responsive-images when i move all up to my website responsive images dosen't find images
in my template file if i use
<img class="card-img-top" srcset="{% srcset item.img 200x400 400x800 nocrop %}"
src="{% src item.img 400x800 nocrop %}" alt="Card image cap">
i get that error it seems dosen't find file
FileNotFoundError at /
[Errno 2] No such file or directory: '/code/uploads\\Item\\0\\817_img.jpg'
Request Method: GET
Request URL: http://www.mysite.it/
Django Version: 3.2.5
Exception Type: FileNotFoundError
Exception Value:
[Errno 2] No such file or directory: '/code/uploads\\Item\\0\\817_img.jpg'
Exception Location: /usr/local/lib/python3.9/site-packages/django/core/files/storage.py, line 238, in _open
Python Executable: /usr/local/bin/python
Python Version: 3.9.4
Python Path:
['/code',
'/usr/local/lib/python39.zip',
'/usr/local/lib/python3.9',
'/usr/local/lib/python3.9/lib-dynload',
'/usr/local/lib/python3.9/site-packages']
Server time: Tue, 25 Jan 2022 14:16:46 +0000
but if i don't use responsive images it works
<img class="card-img-top" src="{{item.img.url}}" alt="Card image cap">
do you know why it dosen't work?

ok i found a solution, maybe is a bug for django-responsive-images
on some OS there is no problem if image path inside database is:
media\images\myimage.jpg
or
media/images/myimage.jpg
but in other OS ( like unix in raspberry pi ) django-responsive-images works only if path is with / so when it try to modify/copy an image he founds it
(instead on Windows a path / is same as \ )
note: for Browsers there is no difference for :<img src="media\images\myimage.jpg"> and <img src="media/images/myimage.jpg">
so in a template if image.path have wrong slashes like media\images\myimage.jpg on unix/raspberrypi only works [1] img tag, instead on windows both works
[1]<img src="{{item.img.url}}">
[2]<img src="{% src item.img 150x300 nocrop %}">

Related

Next.js + Production build + Webp format images

I have a few images that are already in .webp format.
/public/images/Image.webp
and they work on my dev local environment but when I build and view the static site the image fails to show.
<picture>
<source
srcset="/images/architect/Header-Image.webp"
type="image/webp"
/>
<img srcset="/images/architect/Header-Image.webp" />
</picture>
Image of file location:
/public/
images/
architect/

django easy pdf can't display include static files (css/ images)

I am trying to include some images and css into my pdf using django-easy-pdf, however they aren't showing up.
getFile '/static/open-iconic/font/css/open-iconic-bootstrap.css' '...\\mysite\\__dummy__' '...\\mysite\\__dummy__'
Traceback (most recent call last):
File "...\Python\Python36-32\lib\site-packages\xhtml2pdf\context.py", line 828, in _getFileDeprecated
nv = self.pathCallback(name, relative)
File "...\Python\Python36-32\lib\site-packages\easy_pdf\rendering.py", line 35, in fetch_resources
path = os.path.join(settings.STATIC_ROOT, uri.replace(settings.STATIC_URL, ""))
File "...\Python\Python36-32\lib\ntpath.py", line 75, in join
path = os.fspath(path)
TypeError: expected str, bytes or os.PathLike object, not NoneType
line 0, msg: getFile %r %r %r, fragment:
My template file:
{% load static %}
<link href="{% static '/open-iconic/font/css/open-iconic-bootstrap.css' %}" rel="stylesheet">
my folder structure:
mysite
- mysite
- app
-static
The static files are working when serving normal webpages, but not in the pdf. Any suggestions?
From this Thread, Django-easy-pdf can render images from local file:// or remote http/https urls using WeasyPrint. This means you are going to edit your settings file for this setup to work in harmony with django-site. I modified demo app to illustrate this. clone/pull django-easy-pdf-demo-app
for the modified app.

Serving Static files - Django-nonrel in Appengine

I've successfully got a basic Django-nonrel app up and running on Appengine. The templates are getting rendered properly, but the static content returns a 404 response.
There is no problem with the static content in the dev server launched using `python manage.py runserver'.
These are the relevant lines in static.py:
STATIC_URL = '/static/'
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder', # Refers to PROJECT_DIR/static
'django.contrib.staticfiles.finders.AppDirectoriesFinder', # Appname/static
)
STATICFILES_DIRS = (os.path.join(PROJECT_DIR, 'static'),)
In the relevant template:
{% extends "base.html" %}
{% load staticfiles %}
{% block title %}Adding Objects{% endblock %}
{% block content %}
<p>Placeholder for Objects</p>
<img src="{% static "test_pattern.gif" %}">
<img src="{% static "sample_overlay.gif" %}">
{% endblock %}
With this, static files in myproject/static directory and myproject/myapp/static directory are being served successfully in the dev server (python manage.py runserver).
This is my app.yaml:
application: appname
version: 1
runtime: python27
api_version: 1
threadsafe: yes
builtins:
- remote_api: on
inbound_services:
- warmup
libraries:
- name: django
version: latest
handlers:
- url: /_ah/queue/deferred
script: djangoappengine.deferred.handler.application
login: admin
- url: /_ah/stats/.*
script: djangoappengine.appstats.application
- url: /media/admin
static_dir: django/contrib/admin/media
expiration: '0'
- url: /.*
script: djangoappengine.main.application
Any clue how to fix this? I don't want the Appengine web server to handle static files, I want to route everything through Django (at least for now). Hence a solution like this isn't really acceptable in my case.
EDIT: I can easily get around this with this in my app.yaml and serving all static files from projectdir/static.
- url: /static
static_dir: static
But this solution seems dirty, I'd like to leave it all to Django.
Your adding the /static mapping in app.yaml is the correct method. It is not "dirty".
Also, you are adding the django library in app.yaml. That is not correct. Django-nonrel uses its own branch of Django, which you should import as a directory with your app. Adding the django call to libraries in app.yaml means you are importing 2 versions of Django, which can cause strange errors. Delete the Django library call in app.yaml, and import the Django version that is included with nonrel.

Import error from “Django Tutorial: a blog App” in windows 7

My blog app is under "mysite" project.
The error I get when I run the server with python manage.py runserver and I go to admin panel of django and then the error is
ImportError at /admin/
No module named dbe.blog
Request Method: GET
Request URL:
Django Version: 1.5.1
Exception Type: ImportError
Exception Value:
No module named dbe.blog
Exception Location: C:\Python27\lib\site-packages\django\utils\importlib.py in import_module, line 35
Python Executable: C:\Python27\python.exe
Python Version: 2.7.2
Python Path:
['C:\\Users\\farhan\\Downloads\\dist\\Django-1.5.1\\django\\bin\\mysite',
'C:\\Windows\\system32\\python27.zip',
'C:\\Python27\\DLLs',
'C:\\Python27\\lib',
'C:\\Python27\\lib\\plat-win',
'C:\\Python27\\lib\\lib-tk',
'C:\\Python27',
'C:\\Python27\\lib\\site-packages']
Server time: Sat, 17 Aug 2013 02:40:17 +0600
Seems like you've added '"dbe.blog" to installed apps setting, try "blog" instead.
EDIT:
#vikki has a good point, so maybe you should give us full traceback.
I suspected you were using a tutorial, so after googling dbe.blog tutorial I found this site. if that's what you are using, then I'm guessing the lines that refer to dbe.blog should, in your case, refer to firstblog. So from dbe.blog import ... should be from firstblog import .... In your templates the same applies to the url tag
<a href="{% url dbe.blog.views.main %}" >Back to Blog Frontpage </a>
should be
<a href="{% url firstblog.views.main %}" >Back to Blog Frontpage </a>

Django-Compressor throws UncompressableFileError

I'm using django-compressor and django-staticfiles (the external version, I'm on Django 1.2).
When I try to load my site, I get an error:
TemplateSyntaxError: Caught UncompressableFileError while rendering: 'css/facebox.css' isn't accesible via COMPRESS_URL ('/static/') and can't be compressed
I've verified COMPRESS_URL is equal to STATIC_URL, and the file is actually accessible at that URL.
Looking at the django-compressor code, I found where that exception is thrown:
def get_basename(self, url):
try:
base_url = self.storage.base_url
except AttributeError:
base_url = settings.COMPRESS_URL
# I added the following print statement:
print "url: %s, base_url: %s" % (url, base_url)
if not url.startswith(base_url):
raise UncompressableFileError("'%s' isn't accesible via "
"COMPRESS_URL ('%s') and can't be "
"compressed" % (url, base_url))
The first {% compress css %} block in my templates is this:
{% compress css %}
<link rel="stylesheet" href="/static/css/blueprint/screen.css" type="text/css" />
<link rel="stylesheet" type="text/css" href="{{ STATIC_URL }}css/facebox.css" />
{% endcompress %}
(Note that the first link doesn't use {{ STATIC_URL }}, but the second one does)
And I get this in my error log:
[Thu Oct 13 08:19:13 2011] [error] url: /static/css/blueprint/screen.css, base_url: /static/
[Thu Oct 13 08:19:13 2011] [error] url: /static/css/facebox.css, base_url: /static/
[Thu Oct 13 08:19:14 2011] [error] url: /static/css/blueprint/screen.css, base_url: /static/
[Thu Oct 13 08:19:14 2011] [error] url: css/facebox.css, base_url: /static/
As you can see, the screen.css file is processed twice, and successful the second time around. The facebox.css file, however, fails the second time, presumable because the {{ STATIC_URL }} isn't defined in the template context the second time the file is parsed.
Obviously I could solve the problem by not using {{ STATIC_URL }}, but that is not an acceptable solution.
Why would my css files be processed twice? They originally had media='screen, projection', but I removed that thinking it was causing the problem.
Relevant settings:
In [4]: from compressor.conf import settings
In [5]: settings.COMPRESS_ROOT
Out[5]: '/home/ianchat/static_files'
In [6]: settings.STATIC_ROOT
Out[6]: '/home/ianchat/static_files'
In [7]: settings.COMPRESS_URL
Out[7]: '/static/'
In [8]: settings.STATIC_URL
Out[8]: '/static/'
In [9]: settings.COMPRESS_OUTPUT_DIR
Out[9]: 'CACHE'
In [10]: settings.COMPRESS_CSS_FILTERS
Out[10]: ['compressor.filters.csstidy.CSSTidyFilter']
In [11]: settings.STATICFILES_FINDERS
Out[11]:
('staticfiles.finders.FileSystemFinder',
'staticfiles.finders.AppDirectoriesFinder',
'staticfiles.finders.LegacyAppDirectoriesFinder',
'compressor.finders.CompressorFinder')
I bumped into the same issue.
The answer was found here: https://github.com/jezdez/django_compressor/pull/206
The link's solution is doing handler500.
I decided to change 500.html template to avoid any {{STATIC_URL}} in it and the problem was solved.
It almost looks like STATIC_URL is not in your context. You do have the staticfiles contextprocessor configured, right? Have you tried to like the file without the compressor tags? Does {{ STATIC_URL }} show up correctly in the page when you load it?
I think compressor checks the url even if it accesses it through the file system looking at https://github.com/jezdez/django_compressor/blob/develop/compressor/base.py#L57
This is an old question, but one of the few search results when searching for this error message, so it might be worth someting to share my solution.
In my case it was a dead simple case: I hardcoded my static url and forgot the / at the beginning. So I had this:
<link type="text/css" rel="stylesheet" href="static/style.css" />
Which gave me the error. After changing to this:
<link type="text/css" rel="stylesheet" href="/static/style.css" />
It was fixed. Of course, I later realised, I should have used the setting STATIC_URL:
<link type="text/css" rel="stylesheet" href="{{ STATIC_URL }}style.css" />
Hope this helps anyone.
I've look at it some more and I'm pretty sure the exception is caused by trying to display an uncatched error page without the full context the first pass had. This causes the exception in django-compressor.[1]
The solution, of course, is to handle all errors.
[1] I'm also running some non-standard code to display static pages, maybe this interferes and the reason that the bug is not too common.
I ran into the same issue; in my case the problem was caused by using COMPRESS_OFFLINE_CONTEXT - which does not .update() the context but it replaces it altogether, thus removing STATIC_URL.
The solution in my case was just adding it back to the COMPRESS_OFFLINE_CONTEXT, after the local_settings import, otherwise any override there wouldn't have worked.