Improve Satchmo Django 1.3 staticfiles support

Create issue
Issue #1331 resolved
José Moreira created an issue

Satchmos Django 1.3 staticfile un-support (?) creates issues on:

  • PDF invoices
  • Downloadable product downloads
  • maybe others

i have forked to project to work on it myself, but i'm aware of the current status on this and would like like to create duplicate efforts, so i opened the ticket, for now.

Comments (16)

  1. Chris Moffitt repo owner

    Thanks for opening the ticket. This is something I've wanted to tackle but haven't had the time to yet.

    Keep us updated on your progress.

  2. José Moreira reporter

    Django 1.3 still supports "no contrib.staticfiles" mode, so i need to figure out how to cope both ways, but it should't be hard. Also i'm not deep on the Satchmo codebase, but i'll give it a go and update the issue with news.

    For now i just have a fork on from which i have been pulling the latest upstream fixes.

  3. José Moreira reporter

    Satchmo (tip) holds static files on "satchmo/static/" and has a "satchmo_copy_static" command on the "" app.

    I figure that the "satchmo/static/" folder could be moved into a "" app "static/satchmo" folder.

    The "satchmo" sub-folder is helpful to separate static files by folder on the "collectstatic" command destination folder.

    This would allow those files to be picked automatically up by django 1.3 contrib.staticfiles and since the "satchmo_copy_static" just copies the files from a pre-defined folder, currently something like:

    static_src = os.path.join(satchmo_store.__path__[0],'../../static')

    it guess it could be updated for backwards/no contrib.staticfiles compatibility.

    Most related changes at the template level would be to prefix the current static files with "satchmo".

    Any opinions?

    EDIT: As far i know, some files in the static folder are only required by some apps. Ideally every app would have it's static folder, but that would add complexity to the "satchmo_copy_static" command (that only looks up a single folder).

  4. Chris Moffitt repo owner

    There is not necessarily a requirement to keep the satchmo_copy_static command. However, we do need to make sure it is easy for people to know where to go to edit css etc.

    I'd recommend you float your ideas on the satchmo list and see what the group thinks. I personally haven't used the static serve component in 1.3 but anything we can do to speed up the deployment process is good.

  5. José Moreira reporter

    By "I figure that the "satchmo/static/" folder could be moved into a "" app "static/satchmo" folder." i meant just moving "satchmo/static/" to "satchmo/apps/satchmo_store/shop/static/satchmo".

    As far as i know and i may be wrong, that static folder seems to be a common place for satchmo static files, including optional modules, so instead of going as far as breaking static files per app (django 1.3 static files can pickup static files per app and copy to STATIC_ROOT/MEDIA_ROOT), it would just be moved into a required satchmo app and the command updated to copy files from there, if it's required for backwards compatibility.

    I'll post an e-mail to the community about it.


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

  7. Hynek Cernoch

    Critical is not the issue but the timeline for milestone 0.9.2 because most users will probably also upgrade to Django 1.3. and this can be percieved as regression.

  8. Hynek Cernoch

    I will do it in two phases:

    1) for Satchmo 0.9.2 compatible with Django 1.2 - 1.4

    • Added a new item STATIC_URL to the context created by satchmo_store config context processor. If no settings.STATIC_UR is defined with old Django, it uses settings.MEDIA_URL.
      All {{ media_url }} is changed to {{ STATIC_URL }} , because they are only javascripts and css. This is done automatically by installing a source and users of Django 1.2 need not change anything more.
    • Users upgrading a store to Django 1.3+ should create a new empty directory store/static-collect in the project directory, where static files will be collected. Create new settings values as below run collectstatic and create mapping of *_URL to *_ROOT pairs respective in the production webserver config.
    • It is recommended, that old users create a directory "store/media", they change MEDIA_ROOT to it and move product images and category images to it in order to save space. If they do not want, these images will only be duplicated, nothing worse.
    # changes for Django >= 1.3
    STATIC_ROOT = '.../store/static-collect/'
    STATIC_URL = '/static/'
    MEDIA_ROOT = '.../store/static/'
    # or uncomment following line if product+category images has been moved easily
    # MEDIA_ROOT = '.../store/media/'
    MEDIA_URL= '/media/'
    # Remove line ADMIN_MEDIA_PREFIX !!

    Note: New STATIC_URL does not only duplicate Django "static" context processor, it improves it, because Satchmo variant of STATIC_URL context variable solves the SSL problem if static files are provided by different subdomain (i.e. settings.STATIC_URL starts with http://) but the secure page needs secure static files.

    I am not sure if it fixes also the problem #1329 (Other related #1347 and #1327 should be fixed.)

    2) Phase for Satchmo 0.9.3, Django 1.3+

    • Changed source paths as Josè recommended and use ./ collectstatic instead of satchmo_copy_static.
    • Removed a line from STATICFILES_DIRS.
  9. Hynek Cernoch

    José Moreira wrote

    Most related changes at the template level would be to prefix the current static files with "satchmo"

    I think existing eshops owners would not like it at all, many new ones also do not like to have "satchmo" in url, but for people doing integration Satchmo with other applications it is good. If such prefix should be added to templates, it should be by an configurable variable. (Currently I ignore it.)

  10. Log in to comment