Stop displaying the template in CMS.
This has no effect on already-existing components; it merely prevents
new components from being created with this template.
All functionality has been replaced by the XBlock version [1][2].
Backstory:
This was written by Stanford, circa 2013; it was always a bit of
a hack. While it masquerades as if it were an XBlock/XModule, it's
really a YAML template for the HTML module. It depends on JS/CSS
that is embedded as a first-class citizen of the platform. This has
all caused confusion. Worse, it's a pain to edit/configure/update,
since it uses none of the XBlock infrastructure.
Nearly two years ago, we XBlock-ified the component and have
been running it ever since [1][2]. As such, we no longer support
this "component" and would suggest edX follow suite. Consider this
a request-for-comments on the path forward.
Process:
Deprecation of this module would follow a few steps:
1. Prevent new components from being added in Studio with this template.
- This PR represents step 1.
- This is backward compatible; it will have no effect on
existing components.
2. (optional) Install the XBlock version.
- This allows new ImageModal components to be added, now via the
XBlock.
3. (optional) Identify and convert existing HTML modules to XBlocks [3].
- We have enough of the legacy components in use that we can't
just break support by removing this feature; we need a
conversion process.
- Because these are really just HTML modules with special
contents, we have to query based on file contents (see, I told
you this thing was hacky!):
- All such components must contain an HTML anchor tag with
the class `modal-content`.
- Beyond the query, we don't intend to automate the actual
conversion. Our use of the original component is limited
enough that it's probably not worth converting from one module
type to the other. Exacerbating the situation, because it's
HTML, other changes could have been made to the module that
would prevent automatic parity. As such, we'll work with our
CoureOperations team to convert these manually at Stanford.
4. Remove all references.
- At this point, we can safely remove all supporting static
assets like CSS, JS, etc.
5. Enjoy less technical debt.
[1] https://github.com/Stanford-Online/xblock-image-modal
[2] https://pypi.python.org/pypi/xblock-image-modal/
[3] The one saving grace of the legacy component is that it was designed
to degrade gracefully. Specifically, the HTML itself is just an
image inside a link. The extra platform JavaScript progressively
enhances the display, if the relevant CSS classes are found. As
such, even if you removed all supporting CSS/JS from the platform
tomorrow, existing legacy components would simply render as an image
that links to a larger copy of itself. This is deemed an acceptable
failure mode; graceful degradation FTW!
- New exported courses include course run information in:
- `url_name` of root course node
- file name of root node in course folder
- root key name in policy.json
- directory name inside policies folder
- when imported via management command, the OLX will overwrite an
available existing course with the same course key (i.e. same org,
course number and course run)
- if there is no matching course, one will be created
- when imported via the studio web ui (or import API), the OLX will
replace the current course (no change in behavior)
- courses exported with this commit have been tested to import via
management command and studio web UI in hawthorn and ginkgo releases.
They should also work in prior releases, but have not been tested.
