Skip to content


Subversion checkout URL

You can clone with
Download ZIP


document file serving in development #104

webmaven opened this Issue · 21 comments

5 participants


hint at docs on djangoproject about serving MEDIA_ROOT (

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 ./ runserver), documenting it would be a very good idea.

  • Do you mean static media or user uploaded media?
  • Are you using the develop version from github or a release?

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:

You can see our code using filer here:

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:
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


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.

@webmaven webmaven closed this
@webmaven webmaven reopened this

hmm. weird. This is where the settings gets evaluated:
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 ./ 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 runserver is not serving them at /media/

Edit: uninstalling through pip and re-installing through 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


Is this how one should fix this design decision or there is a better/righter way?

  1. fix prefix to static files in settings: FILER_STATICMEDIA_PREFIX = '/static/filer/'

  2. in site-packages, copy files from filer/media/filer/* to filer/static/ (on all servers)

  3. run collectstatic on prod server


This issue can be closed since 4733800 has fixed it.
/cc @stefanfoulis


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 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.