django documentation, serving static files, 3 simple steps? Nope - django

https://docs.djangoproject.com/en/1.3/howto/static-files/
Trying to serve static files i was put on to the above link.
The link tells me when serving static files in development
Put your static files where they will be found, 'home/jamie/mysite/static/'
Done!
2.Make sure that django.contrib.staticfiles is included in your INSTALLED_APPS.
For local development, if you are using runserver...you’re done with the setup.
Done!
3.You’ll probably need to refer to these files in your templates. The easiest method is to use the included context processor which allows template code like:
<img src="{{ STATIC_URL }}images/hi.jpg" />
Done!
Wow, that seems too simple, surely it wouldn't work,
and sadly, no.
{{ STATIC_URL }} when i checked, equals None. Now STATIC_URL by default is none, therefore these instruction haven't done a thing. Surely i've done something wrong and the django documentation is right. But i cant figure out where in the three simple steps i've gone wrong.

Try setting STATIC_URL = '/static/' in your settings.py.

Related

Why is {% load static %} a dependency for {% get_media_prefix %}?

I've been using {% get_media_prefix %} for a very long time. I was explaining this to someone when he pointed this out.
Why do I need to declare {% load static %} in order to use it?
It even uses in the documentation's example code here.
To an extent I understand that static files and media files are similar in nature. Even when we use them with combination of nginx+gunicorn, nginx handles both of them(we let everything else proxy, but not these).
But still we have a separate MEDIA_URL and STATIC_URL as well as MEDIA_ROOT and STATIC_ROOT defined for these files.
Then why {% load static %} needs to be declared in order to use {% get_media_prefix %} ?
Thanks in advance.
In order to use a template tag in your HTML you must first load the module that contains it.
So, accorrding to the source code of get_media_prefix template tag, this template tag lives inside django/templatetags/static.py.
That's why you have to load it every time you use it, in every HTML template.
This, of course, applies to every template tag usage. At the top of every HTML file you load the template tags and then you use them. Just like you import a function in your python code.
UPDATE: From the Django 1.3 release notes:
In previous versions of Django, it was common to place static assets in MEDIA_ROOT along with user-uploaded files, and serve them both at MEDIA_URL. Part of the purpose of introducing the staticfiles app is to make it easier to keep static files separate from user-uploaded files. Static assets should now go in static/ subdirectories of your apps or in other static assets directories listed in STATICFILES_DIRS, and will be served at STATIC_URL.
As you can see, Django used to treat both static and media the same. Since Django 1.3 this changed, but the template tag not. No big deal. It's just a convention.

Why do I need to define both STATIC_URL and STATICFILES_DIRS?

If I define only one, the page displays without any CSS/JS. If I define both, the pages load fine. Why is that? I thought STATICFILES_DIRS is extraneous?
There's an answer here but it doesn't answer why I need both. It simply says what both does, which in my eyes is the same thing. What's the difference?
List of definitions for STATIC/STATIC_ROOT/STATICFILES_DIR
From what I have scoured on StackOverflow, I think I can sum it up as follows:
STATIC_ROOT is referenced as the static server, be it the default Django static server or the static server made on Heroku/etc. You point to this in urls.py
STATICFILES_DIR is referencing the stuff within static assets so if there are separate folders, one for CSS, one for JS, etc.
Feel free to add!
STATICFILES_DIRS is extraneous. You only need to use it if you are using a static files directory outside of the static files directories inside of your apps. Without seeing more of your code, and the structure of your project I can't even begin to guess why your pages aren't loading, but you definitely do not need to specify a STATICFILES_DIRS.

Difference between "load static from staticfiles" and "django.core.context_processors.static" in Django

As I am learning about how Django handles static files, I have seen two different ways of serving static files while still allowing portability.
One way is to do the following in the template:
{% load static from staticfiles %}
<img src="{% static "images/hi.jpg" %}" alt="Hi!" />
as documented here on the Django docs.
The other way I see is to load the context processor for static files, and then use
<img src="{{ STATIC_URL }}images/hi.jpg" alt="Hi!" />
as noted here on the Django docs. When using this method, I change STATIC_URL based on
if DEBUG:
STATIC_URL = 'localhost'
else:
STATIC_URL = 'some_static_server_url'
Which is considered better practice? Is one way better than the other? For example, this SO question has both methods as answers, and this one has the second method. Any insights would be helpful.
Both methods are essentially the same when using Django's default StaticFilesStorage. Both methods are ignorant of any actual files. Both methods just join together the STATIC_URL setting and the actual file path.
There can be a difference when using a custom file storage backend. If you need flexibility, e.g. if some files are stored with different static urls, you can override the backend's url method to return an url based on the actual location of the file. That won't be possible using the STATIC_URL setting. However, this situation is quite rare: most servers store their static files in a single location either on the same server or with a third-party service.
When you define the STATIC_URL setting and the static files are on the same domain as the website, it's better to define it as a root-relative url, e.g. '/static/'. This increases portability and is less likely to cause errors. You will no longer have to worry if you have covered all systems where the code can be deployed.

What does "Directory indexes are not allowed here." mean in a Django error?

I am trying to debug this bizarre 404 error that surfaced in my Django application.
Page not found (404)
Request Method: GET
Request URL: http://78.198.124.245/
Directory indexes are not allowed here.
You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False, and Django will display a standard 404 page.
What does "Directory indexes are not allowed here." mean? What is a directory index?
I Googled around, and the results I found all have to do with serving static files. However, I don't think I do that. What does this error mean?
Check your settings.py file for the STATIC_URL value. You want the value to be the subfolder where your static files are stored - generally STATIC_URL = '/static/'.
The answer depends on which django version you are using. For 1.4+ then just set the STATIC_URL
For 1.3.x its not so much what the STATIC_URL is set to as what your ADMIN_MEDIA_PREFIX is set to.
If you set it to /admin/ then django development server will attempt to serve static files for everything under /admin/ out of the contrib/admin/media/ folder
This means that http://127.0.0.0:8000/admin/postz/post/473 will attempt to find static content at django/contrib/admin/media/postz/post/473 and that's what the 404 is
If you are trying to access http://127.0.0.0:8000/admin/ then that would be an index.html inside of the admin media directory but the internal static server does not allow indexes so that's the error that it throws.
The accepted answer isn't exactly correct. Setting STATIC_URL may have worked as a side effect, but the real issue was that ADMIN_MEDIA_PREFIX was wrong.
The best settings would be:
ADMIN_MEDIA_PREFIX = '/media/'
or
ADMIN_MEDIA_PREFIX = '/admin/media/'
For 1.4 then just set the STATIC_URL as ADMIN_MEDIA_PREFIX is deprecated
https://docs.djangoproject.com/en/dev/releases/1.4/#django-contrib-admin
I had the same problem sometime ago and I also was looking for an answer but couldn't find anything useful. However, the problem for me was the the name I entered in the path in the urls file in my app didn't match the name of the function in views.
path('home-en', views.home_en, name="home")
Here 'home-en' should've been 'home_en' to match the name of the view function.
The reason for getting this error is that maybe trying to map our view with a custom url which luckily is a directory name.
so in this case, for e.g: we're storing our all static files in Static named folder and we're trying to create a url : path('static/',views.static_view).
So in this case it will not work.
what we can do, we can change the custom url to any generic url such as 'inex/' and it will work.

Serving static files in development with django-devserver

I finally got around to trying out django-devserver. It's installed and working but static files refuse to load (Django 1.3). (Note: static files work fine with the standard runserver management command, before switching to django-devserver, so all the configuration settings are fine.) I came across this bit in the README:
DEVSERVER_IGNORED_PREFIXES = ['/media', '/uploads']
A list of prefixes
to surpress and skip process on. By default, ADMIN_MEDIA_PREFIX,
MEDIA_URL and STATIC_URL (for Django >= 1.3) will be ignored (assuming
MEDIA_URL and STATIC_URL is relative)
Which seems very odd because the whole point of using runserver is to not have to have an actual real web server setup, especially just to serve static files in development.
Oddly, though, even though it mentions ADMIN_MEDIA_PREFIX, I found that the admin actually loads all its static resources fine, which leads me to believe that maybe I'm just missing something somewhere.
Anyone ideas?
From the URL in #MarkLavin's comment, I actually came across (rather, reminded of) the following:
# Add to end of urls.py
from django.contrib.staticfiles.urls import staticfiles_urlpatterns
urlpatterns += staticfiles_urlpatterns()
That will allow the static files to be served and is ignored in production, so there doesn't seem to be any side effects to the approach. However, it irks me a little to have to modify my urls.py just for this, but it's probably only temporary until the noted pull request is merged.
If anyone has any other solutions, feel free to add them, though.