Per Dave Ormsbee:
> That was from way back when, when we actually had Django server pools,
> proxied differently by nginx; one was the courseware, and the other
> was askbot, a discussion forum.
>
> They shared all the same code, but different parts were live. It was
> about as good an idea as it sounds.
>
> There is no reason that I can think of in the current day and age where
> you would ever want to run the LMS and *turn off courseware*.
Turns out if the string literal starts on the next line after the
translation function, then the translator comment is lost. So, either
close up short strings, or add a dummy empty string on the first line to
concatenate with the real string.
Ugh.
There's a lot of useful things in PR #8271 that provide a framework
for the comprehensive theming system. If we need to remove the edx.org
theme from the codebase, we can leave most of PR #8271 in, to make it
easier to build on top of and get this feature back in.
Serve branded footer JSON/HTML/CSS/JS from an API endpoint
in the branding app. Refactor OpenEdX and EdX.org footer templates
to use the Python version of the API, ensuring that the API
values are consistent with the footer included in main.html.
Detailed changes:
* Added footer API end-point to the branding app.
* Footer API allows the language to be set with querystring parameters.
* Footer API allows showing/hiding of the OpenEdX logo using querystring parameters.
* Deprecate ENABLE_FOOTER_V3 in favor of the branding API configuration flag.
* Move no referrer script into main.html from the edx footer template.
* Rename rwd_header_footer.js to rwd_header.js
* Cache API responses.
Authors:
Awais Qureshi, Aamir Khan, Will Daly
Update edx-lint to the version that checks if tearDown uses super.
Convert a number of tearDown methods into addCleanup.
Remove some unneeded tearDown methods: no need to call patch.stopall if
none of them were started with patch.start.
The existing pattern of using `override_settings(MODULESTORE=...)` prevented
us from having more than one layer of subclassing in modulestore tests.
In a structure like:
@override_settings(MODULESTORE=store_a)
class BaseTestCase(ModuleStoreTestCase):
def setUp(self):
# use store
@override_settings(MODULESTORE=store_b)
class ChildTestCase(BaseTestCase):
def setUp(self):
# use store
In this case, the store actions performed in `BaseTestCase` on behalf of
`ChildTestCase` would still use `store_a`, even though the `ChildTestCase`
had specified to use `store_b`. This is because the `override_settings`
decorator would be the innermost wrapper around the `BaseTestCase.setUp` method,
no matter what `ChildTestCase` does.
To remedy this, we move the call to `override_settings` into the
`ModuleStoreTestCase.setUp` method, and use a cleanup to remove the override.
Subclasses can just defined the `MODULESTORE` class attribute to specify which
modulestore to use _for the entire `setUp` chain_.
[PLAT-419]
