STATIC and MEDIA mix up

Issue #1347 resolved
Tomas Neme
created an issue

To conform to latest django standards, satchmo should use STATIC_URL instead of MEDIA_URL to look for the media it provides (jquery and blackbird as far as I can see right now), and keep the usage of MEDIA_URL for the store media such as product pictures, etcetera.

Comments (9)

  1. Hynek Cernoch

    Satchmo now supports Django 1.2.3 and 1.3

    Django 1.2.3 has no collectstatic, findstatic, STATIC_ROOT, STATIC_URL. We can not expect that all users have 1.3 or that they all desire to upgrade their configurations before it is necessary. The only thing we can do now is to define both equally in the skeleton/

    MEDIA_ROOT = STATIC_ROOT = os.path.join(DIRNAME, 'static/')
    MEDIA_URL = STATIC_ROOT = "/static/"

    Do you agree? Does it help?

    You can prepare a patch that will be used after the end of support Django 1.2.3.

  2. Tomas Neme reporter

    I know it's a big issue, I was thinking more of "new version" kind of thing, but no, this doesn't work since MEDIA_ROOT and STATIC_ROOT (or MEDIA_URL and STATIC_URL, cannot remember which pair) cannot be the same.

    I think the solution would rather be checking for the existence of STATIC_* settings and use those if they exist, falling back to MEDIA_* if they don't.

    I'll work on a patch if I have time, but my basic idea would be among these lines:

    • add satchmo settings variable for use instead of MEDIA_* within satchmo. make them both STATIC_* for satchmo-provided files and MEDIA_* for product pictures, etc.
    • set them accordingly, STATIC_* = config.STATIC_* if that exists, or MEDIA_* otherwise, MEDIA_* = config.MEDIA_*
    • use these instead of django.conf.settings in satchmo code.

    I know it doesn't sound like the most beautiful solution, but it's the only way I can think of to work around STATIC_* and MEDIA_* being forced to be different

    Does this solution sound good? Does it raise any alarms for anyone who knows the codebase better than I? Can anyone think of a better way?

  3. Hynek Cernoch

    Other issues about this are #1331 and useful are also duplictes #1327 and #1329.

    Do you mean by this that existing users must move/rename some directories and change their templates? Can you specify it? (MEDIA_ROOT a subdirectory of STATIC_ROOT is possible?)

    Hmm. when I have read about "Contrib support for easy handling of static files." in Django 1.3 release notes and that the app django.contrib.staticfiles is optional, I did not suspect that it could be a problem.

    Different MEDIA_* and STATIC_* would also require a change in, and more complicated documentation. For new installations it is suitable to make all at most prepared for Django 1.3. I can change clonesatchmo because I have a new unpublished version full compatible with Djago 1.3, I worked a few months ago.

  4. Tomas Neme reporter

    I'd try to do this as transparent for existing users as possible (totally transparent, if at all possible). I'll read those bugs and try to learn what I can before touching anything, but if it cannot be done transparently then the solution would be forking a "django 1.3 support" version, and releasing migration documents.

    I'll test if media can be a subdir of static. Or maybe the solution is different, maybe redefining collectstatic when stachmo is present..

    The thing I don't like is that now most my static files get collected automatically into /static/ except for the satchmo files which are under /media/ and I cannot change that because satchmo uses the MEDIA_ROOT setting in it's code. Server security settings might also be different for /static/ and /media/

    This is probably a duplicate of #1331 as well

  5. Anonymous

    I'd suggest using the STATICFILES_DIR directory for 1.3 based projects. It's not perfect, because Satchmo's files aren't collecting into a namespace. However, it's better than manually copying the files over.

        os.path.join(os.path.abspath(find_module('satchmo_store')[1]), '../../static'),
  6. Hynek Cernoch

    If we do not fix it with Satchmo 0.9.2-beta, we should wait for 0.9.3-beta.

    Have you a suggestion how to do it?

    IMHO, without your good suggestion it can be easier to wait for Django 1.4-beta together with discontinuing compatibility with Django 1.2. Then we "easily" motivate users to: 1) little update the tree structure 2) update settings 3) run collectstatic 4) reconfigure Apache or other server of static files
    Users without Django 1.3 can not maintain the modified file stucture because of possible practically unrealizable need to manually synchronize two or more directories repeatedly.

    We can provide a patch how impatient users can anticipate a future change or how they can configure the URL "/static/..." to be temporary served by a directory with other name.

  7. Log in to comment