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