* Generate common/djangoapps import shims for LMS
* Generate common/djangoapps import shims for Studio
* Stop appending project root to sys.path
* Stop appending common/djangoapps to sys.path
* Import from common.djangoapps.course_action_state instead of course_action_state
* Import from common.djangoapps.course_modes instead of course_modes
* Import from common.djangoapps.database_fixups instead of database_fixups
* Import from common.djangoapps.edxmako instead of edxmako
* Import from common.djangoapps.entitlements instead of entitlements
* Import from common.djangoapps.pipline_mako instead of pipeline_mako
* Import from common.djangoapps.static_replace instead of static_replace
* Import from common.djangoapps.student instead of student
* Import from common.djangoapps.terrain instead of terrain
* Import from common.djangoapps.third_party_auth instead of third_party_auth
* Import from common.djangoapps.track instead of track
* Import from common.djangoapps.util instead of util
* Import from common.djangoapps.xblock_django instead of xblock_django
* Add empty common/djangoapps/__init__.py to fix pytest collection
* Fix pylint formatting violations
* Exclude import_shims/ directory tree from linting
2. Update COMPREHNSIVE_THEME_DIR to COMPREHENSIVE_THEME_DIRS
3. Update paver commands to support multi theme dirs
4. Updating template loaders
5. Add ENABLE_COMPREHENSIVE_THEMING flag to enable or disable theming via settings
6. Update tests
7. Add backward compatibility for COMPREHEHNSIVE_THEME_DIR
Resolves conflicts between reverts of pattern library test pages and multi-site comprehensive theming, and the re-introduction of pattern library test pages. Fixes a pipeline rendering test which relied on other tests updating assets. The test now ensures that static assets are available before running.
FEDX-93
These are developer only pages, so can not be seen in production
environment. On devstack, you can access these pages in LMS and
Studio at:
/template/ux/reference/pattern-library-test.html
This is the second attempt to enable the Pattern Library. The
first attempt broke Django Templates and didn't work correctly
with right-to-left styling.
Instead of attempting to derive the module portion of a RequireJS
override strictly from the path to the JS file, we now use a dictionary
where the module name must be explicitly specified. This allows us to
compensate for files which do not follow a naming scheme that is
compatible with RequireJS without having to normalize all files. This
is extremely important when using third-party dependencies.
