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
Comments
|
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
Since filer puts public files 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 |
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. |
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 |
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 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?
|
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:
Just to recap, static files are provided by the various apps in their /static folders and are collected in a single directory by 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 |
The reason for falling back to I totally agree that separating staticfiles and media is the way to go and everyone should do it. Maybe we should just drop the |
replaced by #202 |
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.
The text was updated successfully, but these errors were encountered: