1. 30 May, 2017 1 commit
  2. 27 Apr, 2017 1 commit
  3. 11 Mar, 2017 1 commit
  4. 06 Oct, 2016 1 commit
  5. 29 Jul, 2016 1 commit
  6. 27 Jul, 2016 1 commit
  7. 30 Jun, 2016 1 commit
  8. 29 Apr, 2016 1 commit
    • WIP: xblock pipeline work (#10176) · 2497f0a0
      [PERF-303] Integer XBlocks/XModules into the static asset pipeline.
      
      This PR, based on hackathon work from Christina/Andy, implements a way to discover all installed XBlocks and XModules and to enumerate their public assets, then pulling them in during the collectstatic phase and hashing them.  In turn, the methods for generating URLs to resources will then returned the hashed name for assets, allowing them to be served from nginx/CDNs, and cached heavily.
      Christina Roberts committed
  9. 12 Apr, 2016 1 commit
  10. 28 Mar, 2016 1 commit
    • saleem-latif/WL-328: Multi-Site Comprehensive Theming · a796b563
      ziafazal: improvements need for multi-tenancy
      ziafazal: fixed broken tests
      ziafazal: no need to add setting in test.py
      ziafazal: added hostname validation
      ziafazal: changes after feedback from mattdrayer
      ziafazal: fixed branding and microsite broken tests
      ziafazal: make STATICFILES_DIRS to list
      ziafazal: added theme directory to mako lookup for tests
      ziafazal: added more protection in test_util
      saleem-latif: Enable SCSS Overrides for Comprehensive Theming
      saleem-latif: Incoporate feedback changes, Correct test failures, add tests and enable theming for django templates
      saleem-latif: Correct errors in python tests
      mattdrayer: Fix invalid release reference
      mattdrayer: Update django-wiki reference to latest release
      saleem-latif: Update Theme storages to work with Caching, Pipeline and collectstatic
      saleem-latif: Incorporate feedback changes
      mattdrayer: Pylint violation fix
      mattdrayer: Fix broken pavelib test
      Zia Fazal committed
  11. 16 Mar, 2016 1 commit
  12. 14 Mar, 2016 1 commit
    • ziafazal/WL-328: Multi-Site Comprehensive Theming · 954dae58
      ziafazal: improvements need for multi-tenancy
      ziafazal: fixed broken tests
      ziafazal: no need to add setting in test.py
      ziafazal: added hostname validation
      ziafazal: changes after feedback from mattdrayer
      ziafazal: fixed branding and microsite broken tests
      ziafazal: make STATICFILES_DIRS to list
      ziafazal: added theme directory to mako lookup for tests
      ziafazal: added more protection in test_util
      saleem-latif: Enable SCSS Overrides for Comprehensive Theming
      saleem-latif: Incoporate feedback changes, Correct test failures, add tests and enable theming for django templates
      saleem-latif: Correct errors in python tests
      mattdrayer: Fix invalid release reference
      mattdrayer: Update django-wiki reference to latest release
      Zia Fazal committed
  13. 08 Mar, 2016 1 commit
  14. 03 Mar, 2016 1 commit
  15. 29 Feb, 2016 1 commit
  16. 25 Jan, 2016 1 commit
    • Make comprehensive theme work with django templates. · 9b89bd32
      Comprehensive theming did not work with django templates (used by course wiki).
      
      The reason it didn't work was that in order for the theme to work, theme template folder
      has to be added to django template dirs setting *before* django startup.
      After django startup, modifying `settings.DEFAULT_TEMPLATE_ENGINE['DIRS']` has no effect,
      because at that point the template engine is already initialized with a copy of the
      template dirs list.
      
      Instead of running the theme startup code as an autostartup hook, we manually run it
      *before* `django.setup()`. This is fine because theme startup code doesn't have to do
      anything else besides modifying some settings and doesn't actually need django to be
      initialized.
      Matjaz Gregoric committed
  17. 10 Nov, 2015 1 commit
  18. 28 Oct, 2015 1 commit
    • Changes to handler URL generation · 9b88bdb0
      * The LMS now also monkey-patches
        xmodule.x_module.descriptor_global_handler_url and
        xmodule.x_module.descriptor_global_local_resource_url so that we can
        get LMS XBlock URLs from the DescriptorSystem. That functionality is
        needed in the block transforms collect() phase for certain XModules
        like Video. For instance, say we want to generate the transcripts
        URLs. The collect phase is run asynchronously, without a user context.
      
      * The URL handler monkey-patching is now done in the startup.py files
        for LMS and Studio. Studio used to do this in the import of
        cms/djangoapps/contentstore/views/item.py. This was mostly just
        because it seemed like a sane and consistent place to put it.
      
      * LmsHandlerUrls was removed, its handler_url and local_resource_url
        methods were moved to be top level functions. The only reason that
        class existed seems to be to give a place to store course_id state,
        and that can now be derived from the block location.
      
      * To avoid the Module -> Descriptor ProxyAttribute magic that we do
        (which explodes with an UndefinedContext error because there is no
        user involved), when examining the block's handler method in
        handler_url, I made a few changes:
      
      ** Check the .__class__ to see if the handler was defined, instead of the
         block itself.
      
      ** The above required me to relax the check for _is_xblock_handler on the
         function, since that will no longer be defined.
      
      90% of this goes away when we kill XModules and do the refactoring we've
      wanted to do for a while.
      David Ormsbee committed
  19. 23 Mar, 2015 1 commit
  20. 17 Jan, 2015 1 commit
  21. 01 Dec, 2014 1 commit
  22. 14 Oct, 2014 1 commit
  23. 11 Sep, 2014 1 commit
  24. 27 Aug, 2014 1 commit
  25. 29 May, 2014 1 commit
  26. 24 Jan, 2014 1 commit
  27. 02 Jan, 2014 1 commit
  28. 06 Sep, 2013 1 commit
  29. 27 Aug, 2013 1 commit