Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

document file serving in development #104

Closed
webmaven opened this issue Jun 2, 2011 · 21 comments
Closed

document file serving in development #104

webmaven opened this issue Jun 2, 2011 · 21 comments
Milestone

Comments

@webmaven
Copy link

webmaven commented Jun 2, 2011

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.

@stefanfoulis
Copy link
Contributor

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

@webmaven
Copy link
Author

webmaven commented Jun 4, 2011

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.

@stefanfoulis
Copy link
Contributor

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

@stefanfoulis
Copy link
Contributor

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.

@webmaven
Copy link
Author

webmaven commented Jun 6, 2011

Aha. Thank you for the answer. I'll leave the issue open since you've repurposed it.

@webmaven
Copy link
Author

webmaven commented Jun 6, 2011

Hmm. Unless I'm doing something wrong, it looks like filer expects it's own static resources like icons under /media instead of /static...

@stefanfoulis
Copy link
Contributor

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

@webmaven
Copy link
Author

webmaven commented Jun 6, 2011

Hmm. But I am defining STATIC_URL, and haven't overidden FILER_STATICMEDIA_PREFIX.

@webmaven webmaven closed this as completed Jun 6, 2011
@webmaven webmaven reopened this Jun 6, 2011
@stefanfoulis
Copy link
Contributor

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.

@webmaven
Copy link
Author

webmaven commented Jun 7, 2011

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.

@tobia
Copy link

tobia commented Nov 25, 2011

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/

Edit: uninstalling through pip and re-installing through setup.py solved the issue for me.

@airtonix
Copy link

airtonix commented Dec 5, 2011

@stefanfoulis

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

@andreif
Copy link

andreif commented Feb 20, 2012

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

@andreif
Copy link

andreif commented Feb 20, 2012

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

@tobia
Copy link

tobia commented Feb 21, 2012

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.

@andreif
Copy link

andreif commented Feb 21, 2012

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.

@tobia
Copy link

tobia commented Feb 21, 2012

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

@airtonix
Copy link

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.

@andreif
Copy link

andreif commented Feb 25, 2012

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?

@stefanfoulis
Copy link
Contributor

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.

@stefanfoulis
Copy link
Contributor

replaced by #202

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants