hint at docs on djangoproject about serving MEDIA_ROOT (http://readthedocs.org/docs/django-filer/en/latest/installation.html#permissions-on-files)
Original Issue reported by @webmaven:
/media/ URLs don't work for local development
I'm not sure exactly what to do about this, but if there is a solution to getting /media/ URLs to work correctly when running locally (ie. with ./manage.py runserver), documenting it would be a very good idea.
I mean user-uploaded media.
We're currently the develop version in a fork of your repo (to which we haven't made any changes, but we want to always be sure we're using the same version in development and production) here: https://github.com/CivComs/django-filer
You can see our code using filer here: https://github.com/CivComs/commons_site
If there is something we need to do to get those /media/ URLs to resolve correctly when developing locally, please let me know.
this should work out of the box if you have setup django to serve media files from django in development. this is described in the django docs: https://docs.djangoproject.com/en/1.3/howto/static-files/#serving-other-directories
I'd go with the second example:
from django.conf import settings
from django.conf.urls.static import static
urlpatterns = patterns('',
# ... the rest of your URLconf goes here ...
) + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
Since filer puts public files in MEDIA_ROOT/filer by default that should just make things work. For private files things are a bit more complicated, but that is documented in http://readthedocs.org/docs/django-filer/en/latest/installation.html#permissions-on-files
I agree it would be a good idea to add this to the docs. Also skimming the docs I found a mention of the no longer existing FILER_STATICMEDIA_PREFIX settings.
I'll re-purpose this Issue to fix those two things.
Aha. Thank you for the answer. I'll leave the issue open since you've repurposed it.
Hmm. Unless I'm doing something wrong, it looks like filer expects it's own static resources like icons under /media instead of /static...
actually I got something mixed up there. FILER_STATICMEDIA_PREFIX still exists and is what you can use to define the place where django-filer should look for the static stuff like css and js. It will default to STATIC_URL/filer if STATIC_URL is defined. Otherwise it will fallback to MEDIA_URL/filer
Hmm. But I am defining STATIC_URL, and haven't overidden FILER_STATICMEDIA_PREFIX.
hmm. weird. This is where the settings gets evaluated: https://github.com/stefanfoulis/django-filer/blob/develop/filer/settings.py#L19
I could not see an error while staring at the code for a few moments. Perhaps I missed something. Maybe that or thing is not working.
OK, my sincere apologies. It turns out that somehow switching from a release version to pulling from the develop branch screwed something up. Deleting all django-filer eggs and source directories and doing another pip install --requirement=requirements.txt fixed everything on the local machines. What clued me in, finally, was that one of the developers' machines was breaking the production site whenever he deployed, due to filer getting ignored by the ./manage.py collectstatic command. It turned out it was being ignored on every machine, but the others all had copies of those files previously collected. I'll try to come up with a reproducible test case, but it is entirely possible this is a bug in pip.
I'm having a similar issue. I just did a clean install with pip install django-filer and pip install cmsplugin-filer as suggested in the readme. It installed all filer's js, css and images in site-packages/filer/media/ (instead of static/) and manage.py runserver is not serving them at /media/
pip install django-filer
pip install cmsplugin-filer
Edit: uninstalling through pip and re-installing through setup.py solved the issue for me.
this can be solved if you just put actual static files in a folder called static... /mindblowing
and treat them like actual static files throughout your application templates.
that way when someone who uses your "pluggable"(lol) application, can simply use the collectstatic management command to "collect" them in production into their chose path for the statics files...
during development there is no need since the django1.3 dev runserver automatically collates all INSTALL_APPS static directories into one large virtual static directory at the URL defined in the users settings.py
Is this how one should fix this design decision or there is a better/righter way?
fix prefix to static files in settings: FILER_STATICMEDIA_PREFIX = '/static/filer/'
in site-packages, copy files from filer/media/filer/* to filer/static/ (on all servers)
run collectstatic on prod server
This issue can be closed since 4733800 has fixed it.
I'm not sure 4733800 fixes it. I only gave a cursory glance at the code, but it seems to me it still makes confusion between STATIC and MEDIA prefixes. Look at this line:
FILER_STATICMEDIA_PREFIX = (getattr(settings,'STATIC_URL', None) or settings.MEDIA_URL) + 'filer/'
Just to recap, static files are provided by the various apps in their /static folders and are collected in a single directory by manage.py collectstatic in production. They are usually served with a /static or /sitestatic prefix, but can be put on other servers in a CDN or such. Media files are uploaded by the users and are usually stored in /media, which can be mapped to a RAID array or whatever.
Those two kinds of files have different prefixes because they have very different lifecycle requirements, not to mention directory permissions, in a production server.
What is wrong with it? Perhaps it would be cleaner to write
FILER_STATICMEDIA_PREFIX = (getattr(settings,'STATIC_URL', settings.MEDIA_URL)) + 'filer/'
It uses your static url if you define it in your settings. If not, then it falls back to media. There is no confusion.
I admit not being familiar with django-filer much (I haven't worked with it recently) but I think a given piece of configuration is either "static" or "media", it cannot change based on user settings.
I mean, if a file is provided by django-filer and will never change for the lifetime of the app, then it falls into the definition of "static" and I can safely host in on a different server, on Amazon cloud or such. In this case, it's distributed in a 'static' folder along with the app, is collected with collectstatic, and it will be loaded by the browser from STATIC_URL, which I will set to the URL of my slice of Amazon cloud.
On the other hand, if a file is something uploaded by the user, then it is "media". It must be stored in the same server where Django is running, in a special directory where Django can write new files. The actual directory goes into MEDIA_ROOT and the url where Apache will serve the files goes into MEDIA_URL.
Now. How can a given piece of data (whatever goes under FILER_STATICMEDIA_PREFIX in this case) fall into one camp or the other, depending on whether the user has customized his STATIC_URL setting or is simply using Django's default value?
Edit: unless I'm completely misunderstanding your code there :-)
tobia, i agree with you.
Projects that in any way end up serving (what I expect to be static non-user-editable-files) from the place where i mount user uploads on a ZFS raid array... this makes me very upset.
I no longer use this project due to a number of reasons, this being the primary one.
STATIC_URL is /static/ by default. Could you guys provide an example of a usable Django app without STATIC_URL setting? I cannot. The code line above is for some extreme cases which I simply fail to imagine. I do not see a point of this discussion. The issue was resolved, wasn't it?
The reason for falling back to MEDIA_URL in FILER_STATICMEDIA_PREFIX is for people using pre-staticfiles django versions. Before there was django-staticfiles and django.contrib.staticfiles it was up to the developer (or apps like django-appmedia) to copy the media from each app into the main media directory. At that time it was custom to mix static files and uploaded media.
I totally agree that separating staticfiles and media is the way to go and everyone should do it. Maybe we should just drop the MEDIA_URL fallback to clarify this.
replaced by #202