This allows us to deploy much faster: all we have to do is to copy the
assets from the container to the shared volume.
We also changed the way themes are managed: similarly to static assets,
they are now packaged inside the docker image.
By default, open response assessment files are sent to S3. Here, we
store uploaded files with the "filesystem" backend instead. To do so, we
must install a forked version of ora2 that fixes a couple issues.
Note that the "django" backend is not very usable, as file extensions
are lost on upload.
Close #97
Theme assets generation relies on a cache stored in memcache. We were
observing incorrect urls generated for theme/xblock assets whenever
assets had been generated for another platform. For instance, when
viewing an XBlock in the LMS right after running "paver update_assets"
in the cms.
To solve this problem, we cache staticfiles assets in entries with
different prefix.
Close #95
When the ENABLE_EDXNOTES feature is added to the CMS, it is not
necessary to modify the advanced module list to activate notes for each
course.
Close #79.
Template files are now directly loaded in the configurator container, so
that it is possible to run the configurator container directly, outside
of this project.
HTTPS is now fully supported. The ACTIVATE_HTTPS feature flag needs to
be set. Required domain names are LMS_HOST, preview.LMS_HOST and
CMS_HOST.
Close #46.
We no longer run the `configure` script on the host. Instead, we run a
container that generates the configuration files. This opens the way for
more complex configuration templates that would be written in jinja2.
More complex templates are required for feature flags, such as SSL,
XQUEUE, etc.
