Appsembler Tahoe Theming

[Matjaz Gregoric]

I learned about the new Tahoe SASS offering from Appsembler in a recent blog post on the Open edX blog (https://open.edx.org/blog/spotlight-appsembler-keystone-sponsor-openedx2017). The videos look very impressive, especially the theming part!

Since we've been looking into ways to simplify creating and maintaining simple edX LMS themes at OpenCraft, I'm wondering whether any part of the Tahoe theming system has been upstreamed or is open sourced?

If not, does edX have any plans to implement something similar or at least make it easier to modify certain parts of the layout without having to override a bunch of mako templates?

--
Matjaz
@OpenCraft

[Nate Aune]

Hi Matjaz,

Thanks for your feedback on Tahoe, our new SaaS offering of Open edX. We built Tahoe to eliminate the 3 pain points that we've seen with organizations trying to adopt Open edX:

1) Difficulties with hosting and getting Open edX running in a production environment

2) Difficulties with theming Open edX to match your organization's brand

3) Difficulties keeping up-to-date with the latest security patches and Open edX upgrades

With Tahoe, we've eliminated these 3 pain points by providing a turnkey service that makes it point-n-click easy to theme an Open edX site in minutes, backed by scalable and reliable hosting, ongoing maintenance and professional support. https://appsembler.com/tahoe

I think Open edX in its current form is still too immature for the mainstream markets and it's only the innovators and early adopters who are willing to take a risk and have the financial resources to do so.​

Our hope is that Tahoe will attract newcomers to the Open edX community who wouldn't otherwise be able to adopt it due to its technical complexity and the cost associated with that complexity. 

As a more mainstream audience starts using Open edX and influencing the product's direction, this will in turn make the software more mature and therefore attract even more organizations to use and adopt Open edX.

To answer your question about open sourcing the core technologies, the answer is that we intend to open source the theming engine, once we've cleaned it up and made it suitable for public consumption. Right now, it's very Appsembler-specific, but you can see the basic architecture of how it works for customer themes in our edx-customer-themes repo. https://github.com/appsembler/edx-theme-customers/blob/ficus/amc/lms/templates/theme-variables.html

You can also read more about the reasons we built this theming engine rather than using the default way of theming in this blog post: http://appsembler.com/blog/open-edx-theming/

Tahoe makes heavy use of the Django sites and site configuration capabilities (formerly known as microsites) and we've extended these APIs with some of our own to support the theming and site configuration tools. You can see all of the changes we made in our forked edx-platform repo. https://github.com/appsembler/edx-platform/tree/appsembler/amc/master

If these are useful to the rest of the community, we'd be happy to work with edX maintainers to get these pushed upstream and merged with the core. We'd certainly welcome more contributors to these APIs!

Appsembler has been a long-time contributor to Open edX and is committed to contributing bug fixes and features back to the platform. Most recently we've contributed a lot of fixes for the iOS mobile app. 

We've been less active contributing edx-platform fixes, but our engineering team has a goal of making a more concerted effort to push improvements upstream, so that others in the community can benefit from them.

Happy to answer any other questions about Tahoe and the underlying technologies that are used to provide the service! And eager to continue the conversation at the conference too!

Nate

[Matjaz Gregoric]

Hi Nate,

Thank you very much for your reply.

I talked to some of your developers at the conference and they explained to me that your custom theme is built on two levels - the common level and the customer specific level. I believe https://github.com/appsembler/edx-theme-customers is the customer-specific level. Is this the base theme: https://github.com/appsembler/edx-theme/tree/appsembler/amc ?

The idea of multi-level themes seems very similar to the idea of "stacked" themes that I proposed in https://groups.google.com/forum/#!msg/edx-code/OW9r6W-FnJg/D_1DUNY6DgAJ, but was unfortunately never implemented. The basic idea is that instead of only having the base edx-platform theme and a custom theme which overrides templates/sass/images above it, we would extend that to multiple levels, where each level/theme would override the level that sits below it.

If that is something that would work for your system, would you be willing to develop/contribute it upstream? OpenCraft might be able to offer help in terms of code reviews, testing, and communication with upstream.

Final question: do you plan to open source the theming UI React app or will that part remain proprietary?

Thanks!

--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/1c0414bc-21ee-4bab-bea3-956c3c269e2a%40googlegroups.com.

--

Matjaz Gregoric

@OpenCraft

[Matej Grozdanović]

Hi Matjaz,

yes, we basically use two levels:

- theme codebase - holds all the templates we override that are common for all our themes. Also holds the mechanics of how we load template parts, common static assets such as some logos and JS, our custom SASS and default theme variables for rendering the theme. That repo is actually private at this point as it also contains certain proprietary parts very much connected to how Tahoe works.

- customer specific stuff - customer-specific template overrides, additional SASS to be included and compiled into our main one, static assets... You linked that one correctly.

So how it works (as we discussed on the conference in Madrid) is that we extended the static asset pipeline, so now the behaviour is:

- Template lookup: index page needs to be loaded. First the server tries to find the index.html template under customer specific theme folder, if not found then under theme codebase, if not found there then load the default one.

- Underscore template lookup: registration page needs to be loaded. Lookup goes: look under customer specific, if not found look under theme codebase, if not use default.

- Same for images.

Basically *anything* can be overridden (yes - that includes underscore templates!).

It doesn't exactly work indefinitely - basically there are these three levels and that's it (customer-specific, theme codebase, edx default). If I got your proposal right, you were looking into allowing even more levels? While I can see some benefits from that in very specific situations, I would be opposed to that to be honest, as I think it would bring in complication and isn't truly needed.

This three-level system on the other hand I believe works well, actually it has proven itself for us (and our customers) since we did at least 2 successful and quick batch updates between Open edX releases on a number of customers (I mean, we updated Tahoe to Ficus, and for the next update we could easily be having over a 100 sites up there, all updated in batch!). Personally, I think this extension of static asset pipeline would be useful to a lot of people in the community (just the other day we had a situation where someone simply wanted to change some stuff around the registration underscore template and was unable to do it simply).

The theme codebase itself we plan to make open-source (I'm actually currently working on that). We believe it could be a good framework for people to create responsive themes, and we believe that with the help of the community it can only become even better. What we need to do before that is a cleanup + modifications so it works with an official Open edX release, meaning without the changes to the pipeline. Of course, if we could push that upstream and include in Open edX, even better.

The React app itself and everything around it is proprietary, so we won't be open sourcing that.

Best,

Matej

P.S.: it was nice to meet you in Madrid :)

[Felipe Montoya]

Hello Matjaz and Matej,

To complement this discussion, we have been using this for a long time already using the MICROSITE_TEMPLATE_BACKEND extension that we contributed to the platform a while ago. We also extend it to have our particular implementation of the backend (2 levels only using a custom structure), but this as well is public, you can take a look at: https://github.com/eduNEXT/edunext-openedx-extensions/blob/master/edunext_openedx_extensions/ednx_microsites/backends/filebased.py#L23. For the css we have an external pre-processor that compiles the files, so we skip the pipeline completely.

Cheers

Felipe Montoya

https://edunext.co