1. 16 Feb, 2016 1 commit
  2. 14 Feb, 2016 1 commit
  3. 09 Feb, 2016 4 commits
    • Fix unit tests for glob updates. · b2be56f9
      The aforementioned change to `glob` surfaced a couple errors in the unit tests:
      
      1. `test_glob_literal` was still testing the old behavior of non-existing paths
         being filtered out.
      2. The post-process tests (`test_post_process_dry_run` and `test_post_process`)
         were now failing because post-process was being run without first collecting
         the media. This is a case where non-existing files were previously being
         filtered out silently but now cause an error. Running the collection stage
         before testing `post_process.
      David Trowbridge committed
    • Merge pull request #536 from davidt/setting_changed-compat · cb39e0d1
      Fix compatibility with Django < 1.8
      Timothée Peignier committed
    • Don't filter out "missing" files in the glob stage. · 5604b07c
      Commit bd6b9d89 dramatically changed the way that files are loaded, and had the
      side-effect of filtering out any files which were sourced by finders outside of
      the main `STATICFILES_DIRS`.
      
      In the case I'm trying to address, we have an extension framework (in Review
      Board and Djblets) which can load static media from third-party packages which
      are activated at runtime. This media is loaded by instantiating
      `StylesheetNode` and `JavascriptNode` from `pipeline.templatetags` in
      combination with a special finder. Because django-pipeline no longer uses
      finders before the compile stage, calling `storage.exists` (via
      `Package.sources` -> `glob`) silently filters these out.
      
      Inside `glob`, I agree that it's useful to test existence when trying to expand
      `*` or `?`, but when the path is just a normal filename, it should be safe to
      assume that the user knows what they're doing. This causes the paths to be
      emitted into the rendered template whether or not `staticfiles_storage` claims
      they exist, and anything which the configured staticfiles finders can't locate
      will surface as a 404 rather than being silently eaten.
      David Trowbridge committed
    • Fix compatibility with Django < 1.8 · 60262352
      The 1.6.1 release added a dependency on the `setting_changed` signal. In Django
      releases prior to 1.8, this signal is located in the `django.test.signals`
      module, and in 1.8, an alias was added in `django.core.signals`.
      
      This change adds a fallback import to restore compatibility with older versions
      for applications which cannot (yet) migrate to the newer Djangos. It has been
      tested against Django 1.6.11 and 1.8.9.
      David Trowbridge committed
  4. 08 Jan, 2016 1 commit
  5. 06 Jan, 2016 3 commits
  6. 05 Jan, 2016 1 commit
  7. 03 Jan, 2016 2 commits
  8. 02 Jan, 2016 10 commits
  9. 30 Dec, 2015 5 commits
  10. 29 Dec, 2015 4 commits
  11. 21 Dec, 2015 1 commit
  12. 20 Dec, 2015 4 commits
  13. 18 Dec, 2015 3 commits