* Avoid URL namespace collision for "wiki:*" by changing the
course-specific django-wiki instance/app name to something we will
never reverse.
* Update our custom implementation of the staticfiles app's
CachedFilesMixin internal methods `url_converter()` and `_url()` to be
compatible with Django 1.11. This installs multiple shims in order to
maintain compatibility with previous django versions.
This allows an overridding template from a theme to inherit from the
same corresponding standard template.
This is useful when you only want to override one or more named blocks,
but otherwise make no modifications to the standard template.
Comprehensive themes used to allow you to override JS within one of the
bundles created for Studio and LMS (specified in the common.py env
files). So for instance, the bundle that becomes lms-base-application.js
is defined like this:
base_application_js = [
'js/src/utility.js',
'js/src/logger.js',
'js/user_dropdown_v1.js',
'js/dialog_tab_controls.js',
'js/src/string_utils.js',
'js/form.ext.js',
'js/src/ie_shim.js',
'js/src/accessibility_tools.js',
'js/toggle_login_modal.js',
'js/src/lang_edx.js',
]
You could not add a custom file to this list in your theme, but if you
created a themes/mytheme/lms/static/js/dialog_tab_controls.js, then your
theme's version of that file would be wrapped into the bundle, which
would be created at {staticfiles}/mytheme/js/lms-base-application.js
It doesn't appear that this functionality has seen much use in practice,
and it adds minutes to the compile time for sites compiling multiple
themes, so this commit removes this capability. It is still possible to
create and invoke custom JavaScript that is theme specific, and will
compile out to {staticfiles}/mytheme/js -- it's just not possible to
override a file that becomes part of the standard Studio/LMS bundles.
all dirs must now go into COMPREHENSIVE_THEME_DIRS.
Move comprehensive theming setup section out of startup.py and into
settings files using new 'derived' functionality.
Add 'derive_settings' at the end of all top-level Django settings files.
Move validation of comprehensive theming settings into new apps.py
theming file.
Split theming code into code safe to run before settings are initialized
-and- after settings are initialized.
The system checks require database access, which is not available when building Docker images. This relaxes the check, allowing the command to execute without a database.
ECOM-6634
2. Add site configuration overrides to theming/helpers.py
3. Move microsite.get_value from theming/helpers to site_configuration/helpers
4. Move microsite_configuration.microsite.get_value usages to site_configuration.helpers.values
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
* mattdrayer: Add helpers.get_value test
* mattdrayer: Change to simpler implementation, per @douglashall
* mattdrayer: Address quality violations and test failures
