To be able to more easily deal with same-origin issues, due to some course assets being loaded in an iframe, we're adding the ability to specify file extensions that should be excluded from URL canonicalization. The default value is simply 'html', which means we won't rewrite asset links that point to files ending in .html. Thus, they'll be loaded from the same origin as the parent page, and voila, no SOP issues.
CR comments
Whitespace
wip test refactoring
more test refactoring
Re-write download URL too.
Test fixes related to download change, and fix
wip, re-locating tests
update classname
Quality fixes
There's already a global $link-color variable defined in
lms/static/sass/base/_variables.scss. Mark the $link-color
variable in sequence scss file with !default, so that the
global $link-color variable gets used, if defined.
A base URL can now be configured which is, potentially, prepended to an
asset URL. This allows a CDN, or caching server, to front static asset
requests, taking load off of the contentstore and speeding up page load
times.
Asset URL generation respects locked vs unlocked assets, and will not
generate links to locked assets that would traverse a CDN (even though
the authorization component of the contentserver middleware wouldn't
allow those links to work anyways).
The goal of this is to capture more detailed usage and performance
information around the kind of course content we have out there.
Having this information will allow us to more easily query to see
how sequence size and specific block types affect front end
performance.
- Remove escaping in display_name_with_default
- Move escaped version to deprecated display_name_with_default_escaped
- Does not include any other changes to remove double-escaping
Thanks to agaylard who initiated this work:
https://github.com/edx/edx-platform/pull/10756
TNL-3425
Course teams occasionally upload very large files as their course
image. Before this commit, those images would be used directly in
the student's dashboard, sometimes leading to MBs worth of image
data on that page. With this commit, we now auto-generate small
and large thumbnails of configurable size. The Student Dashboard
and Course About pages will make use of this new functionality
(CourseOverview.image_urls), but the behavior of
CourseOverview.course_image_url will not change.
Note that the thumbnails are still created in the contentstore,
and sit alongside their originals.
What's included:
1. Multiple sizes, currently starting with "raw", "small", and
"large". This falls back to the current behavior automatically in
the case where thumbnails don't exist or this feature has been
disabled in configuration.
2. Django admin based configuration for image sizes and whether
to enable the functionality at all. Note that to regenerate
images, you'd need to wipe the CourseOverviewImageSet model
rows -- it doesn't do that automatically. This is partly because
it's a very rare operation, and partly because I'm not entirely
sure what the longer term invalidation strategy should be in a
world where we might potentially have multiple themes. The
flexible configuration was intended to allow better customization
and theming.
3. The Course About pages also use the new thumbnail functionality,
as an example of "large". This is in addition to the "small"
used on the student dashboard.
Things I'm punting on for now (followup PRs welcome!):
1. Bringing the thumbnails to course discovery. A quick attempt
to do so showed that it wasn't getting properly invalidated
and updated when publishes happen (so the old image still showed
up). It probably has something to do with when we do the
re-indexing because it stores this data in elasticsearch, but
I'm not going to chase it down right now.
2. Center-cropping. While this is a nice-to-have feature, the
behavior in this PR is no worse than what already exists in
master in terms of image distortion (letting the browser handle
it).
3. Automated invalidation of the images when a new config is
created.
