rewriting them.
In PERF-341, we adjusted the static_replace middleware to try and
exclude static XBlock resource URLs from being interpreted as the marker
URLs used to signify course assets in course content. Since they both
started with /static, this could, and did, cause issues where linking
directly to the assets of an XBlock within, say, one of its templates,
would lead to that link being rewritten and ultimately being incorrect.
The fix attempted to see if the link started with the prefix that all
static XBlock resource URLs start, and if so, it returned them
unmodified.
We incorrectly assumed that our testing captured all cases, and since
we're here, we know that this was wrong. We weren't accounting for cases
when the URLs being generated had the STATIC_URL configuration value
prefixed -- https://example.com/static/xblock/.... -- and so our direct
check of seeing if such a URL started with "/static/xblock" would always
fail, leading to the erroneous rewriting and nonsensical output.
This fix checks if the link either starts with the prefix OR if it
starts with the STATIC_URL value and contains the prefix overall. There
is a small overlap between the STATIC_URL and the prefix we check for,
so an inconsistency could arise down the line if we changed our
STATIC_URL to use a difference base directory, but our tests will at
least catch the issue now.
This version component reflects the "version" of the StaticContent
objects which we cache server-side. If the layout of those objects
changes between releases, errors occur when loading them from cache.
By using a separate version value, which can be incremented on its own
after a change has been made to the StaticContent class, we can avoid
loading older cached content and in turn take advantage of these changes
faster, without needing to intervene operationally.
When releasing the versioned assets work, we stumbled on a problem with old pickled
versions of the StaticContent objects residing in cache, which triggered a bug in the
code. Not wanting to blow away all cached items, we ended up having to revert and add
in some backwards-compatible helper code to ease the transition.
With this, we'll now utilize the version argument that Django's caching interface
allows, in conjunction with a constant value that can be modified when breaking changes
are being made, to let us gracefully ignore older cached course assets.
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
