Rename the 'media' folder to 'static'

Issue #66 resolved
Anonymous created an issue

Doing so would be more friendly with the default settings of the staticfiles contrib app that comes with django 1.3

Comments (19)

  1. Anonymous

    Exact, but django has the luxury of adding an exception in AppStaticStorage.get_location() so that things 'just work'.

    The immediate advantage of doing this would be that with a default django installation users won't need to set up anything concerning the media for the admin_tools.

  2. coderanger

    In case it helps, shows how to create a backwards-compat loader for 1.3. You could include a copy of the loader in django-admin-tools with instructions on how to add it to your settings if you are using 1.3. Hopefully a new version of the standalone staticfiles will come out soon that adds support for static/ by default.

  3. Jannis Leidel

    Having implemented (and thought about) staticfiles a lot, I implore you to not ship a custom file finder with admin-tools. We try to standardize on one location for static app, similar to how the templates dirs work.

    The reason to not move the admin/media directory around is simple and crude backwards compatibility -- many users have symlinked to this specific directory (myself included in older projects), which is why it'd be a major pain to upgrade.

    One way of handling your issue is close to what @coderanger proposed: Move the files to static/ and tell the users on Django<1.3 to use the django-staticfiles app [1] instead of the contrib app. It has a setting (STATICFILES_MEDIA_DIRNAMES, [2]) that can be set to a list of directory names that should be searched, e.g. in your case ['media', 'static'].

    But if you can wait a few days, I'm almost ready with a new release (0.4.X) of django-staticfiles, that will be compatible with Django 1.3's staticfiles and make the transition for 1.2.X users a lot smoother.

  4. Anonymous

    Ideally with the new staticfiles framework, I'd say each subapp (menu, theming, dashboard) should have its own static folder.

    Django 1.3 really managed to get staticfiles function like templates. It's now delightful to override some css or add a bit a javascript to 3rd party apps.

  5. Jannis Leidel

    Ok, took me a bit longer to get it out: (also

    This app released as 1.0a1 is identical (mostly) to what will ship in Django 1.3 as django.contrib.staticfiles and can be used on older Django versions, too. I'd recommend using this in your docs since it'll make upgrading to Django 1.3+ much easier.

    +1 on putting static files of each app in its 'static' subdirectory, as proposed by Anonymous above, just as how app templates are shipped with each app.

  6. David Jean Louis repo owner
    • changed status to open

    Hi there,

    Jeffrey started some work on this:

    Jeffrey: thanks for taking time to address this issue, unfortunately I have some problems with the change:

    • and docs need to be updated to reflect the change
    • wouldn't it be better to go with the idea of a "static" directory inside of each app, like templates ? (as proposed by Anonymous and Jannis above)
    • the most important one: how can we make this change backwards compatible ? releasing it like this means it will break every installation that use the "symlink" approach to setup media files... I'm worried about that.


    -- David

  7. Jeffrey Gelens

    The first two points are easily fixed.

    Regarding the backwards compatibility, we'll have to think about a solution. (maybe a symlink from media to static? Not sure if this will work). Jannis?

  8. David Jean Louis repo owner

    Symlinks will probably work on unix environments indeed (no idea on windows...).

    Another solution is to keep the media dir unchanged for one release or two and warn users that it will be removed in future releases.

  9. Jannis Leidel

    Regarding the symlinking, I guess you could ship the files in both media/ and static/ for a while and warn users about a future change. I wouldn't recommend symlinking the dirs to each other since distutils can't handle it (IIRC) and Windows support is more than spotty.

    Alternatively, since symlinking seems to be an custom deployment step anyway, just warn users that the move happens in version X.Y and provide simple instructions to recreate the symlink.

    Pointing users to django-staticfiles (for older versions of Django) or django.contrib.staticfiles would also be sensible, of course, since we really try to solve the static files problem at the source (Django) and make it easier for app authors. staticfiles' collectstatic management command also has a --link option for anyone relying on symlinks.

  10. Jeffrey Gelens

    Sent a pull request. A suggestion to maintain the old "media" dir: Update all static files only in the static directories in each app. After that you can run ./ using staticfiles to collect all files in the central ./media directory. This way you won't have to edit the files in two locations.

  11. Anonymous

    Hi - I'm not clear why the /media and /static folders now have different contents. I'm using 1.3 and static files, and collectstatic doesn't seem to grab everything it needs... some stuff still lives in the media directory (e.g. the css).

    Is this still being cleaned up, or is the intention to properly duplicate the directories for a few releases?

  12. Chris Adams

    Are there any plans to ship this in an update on PyPI soonish? Currently if you "pip install django-admin-tools" all of the media will be broken which is a bad first impression.

  13. Log in to comment