Query counts already happen at the model and Python API test layers.
Having query counts in the HTTP API tests makes things more brittle
because that includes middleware that this code should not be aware
of. We don't want to have to revisit these tests every time
another piece of middleware is added or removed.
Cached values were leaking across tests, causing difficult to debug errors,
particularly when using Config Models. As part of this work, certain tests
that had query counts that relied on those values being cached needed to
be adjusted up.
- Rename escape_json_dumps to dump_js_escaped_json
- Rename escape_js_string to js_escaped_string
- Update js_escaped_string to output empty string for None
- Introduce dump_html_escaped_json
- Move dump_js_escaped_json after the pipe as new best practice
- Introduce additional uses of helpers
- Introduce new djangolib directory and move js_utils
Collectstatic failed in production when comprehensive theme contained custom css files.
This patch fixes that problem by removing ComprehensiveThemeFinder from STATICFILES_FINDERS
and ComprehensiveThemingAware mixin from STATICFILES_STORAGE.
Comprehensive theme static dirs are added to the top of the STATICFILES_DIRS entry,
which means that the default django FilesystemFinder will find theme static files,
and since the theme folder is at the top of STATICFILES_DIRS, theme files will take
precedence over default LMS/CMS static files.
This change means that theme static file URLs are no longer prefixed with themes/<theme-name>/,
but since we currently only support one comprehensive theme at a time, that shouldn't be a problem.
If/when we want to make the choice of a theme dynamic per-request (microsites?), we will have to
bring custom theme finders and storage mixins back, but for now, we don't need them.
When creating profile images from an uploaded file, ensure that EXIF
orientation information is preserved, so profile images appear
right-side-up.
https://openedx.atlassian.net/browse/MA-1559
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.
