Manifest-suffixed image not showing up

[niccolomineo]

Hi, apparently a static image cannot be displayed with the standard static template tag when using a manifest-appending storage.

The issue seems to be in utils.django_url_fetcher:34, where find() is invoked: file finders are not able to find the manifest file, because STATIC_ROOT does not and cannot appear in STATICFILES_FINDERS at the same time.

A temporary workaround is to hardcode the file path with the prepended static root inside the template file.

I would like to propose a couple of alternative solutions:

#49 does not remove the current finding behaviour, but simply checks whether the collected file exists.

#50 Only performs said check ('cause is it really needed to trigger the finders in the first place?)

[n1ngu]

Pretty much related: #47

[fdemmer]

Thank you for bringing this up and already thinking of solutions! It's somewhat related to #47, but also very different :)

My notes from analyzing the problem; scenario and settings:

• STATICFILES_STORAGE = ...ManifestStaticFilesStorage
• STATIC_URL = '/static/'
• WEASYPRINT_BASEURL is not set!
• in a template use {% static 'css/main.css' %}
• runserver on localhost
• django_url_fetcher() receives http://localhost:8000/static/css/main.95fde747c1c3.css
• ... since django_url_fetcher() only deals with file:// URLs, it does nothing, the file is fetched via http (which "works", but obviously is not ideal and only, if there is actually something serving the file at that URL).

Same settings as above, but:

• WEASYPRINT_BASEURL = ''
• django_url_fetcher() receives file:///static/css/main.95fde747c1c3.css
• ... that matches the required file:// prefix for using a local file, but as you pointed out Django's file-finders are built to find main.css in STATICFILES_DIRS or static subdirectories in each app and not in STATIC_ROOT after being collected.

The idea behind using the file-finders in the URL-fetcher was, that one does not need to run collectstatic to be able to use static files. With ManifestStaticFilesStorage the URL-fetcher gets the "wrong" filename to "find" that way.

I am going to think further on this... your suggested PRs are possibilities, I am just not sure yet if I want to go around opening files just like that :) ... my current idea/approach would be a "reverse manifest lookup" to find the files' original names.

[niccolomineo]

Hi, any updates on this?

[fdemmer]

Allright, put something together... went for the "reverse manifest lookup" solution... maybe you can try it out? It's in the develop branch.

It should work with the second scenario described before:

• In a template use {% static 'css/main.css' %}
  • There should be absolute paths with the configured STATIC_URL in the HTML.
• Add WEASYPRINT_BASEURL = '' or WEASYPRINT_BASEURL = '/' to your settings.
  • WeasyPrint converts '' to the current directory of the process using os.path.abspath(), so using '/' is probably the safer practice. The end-result is the same as long as the asset paths are absolute (i.e. start with a /), because of how os.path.join() works with absolute paths.
  • This disables automatically providing the base_url based on the request by django-weasyprint.
  • WeasyPrint will prefix any path that does not "look like an URL" with "file://".
  • And that causes django_url_fetcher() to try to find the original name from the hashed one in an attempt to find those files in the filesystem via staticfiles finder.
• It is necessary to run collectstatic to generate the staticfiles.json manifest to look up the filename!

[niccolomineo]

At last, I was able to try it on a pet project and it seems to run fine. Thanks!