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 On Tuesday, July 4, 2017 at 12:19:15 AM UTC+2, Matej Grozdanović wrote: > > 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 :) > > > > > On Thursday, June 1, 2017 at 12:43:39 PM UTC+2, Matjaz Gregoric wrote: >> >> 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! >> >> >> On Mon, May 22, 2017 at 1:19 AM, Nate Aune <[email protected]> wrote: >> >>> 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 <http://readwrite.com/2007/08/06/rethinking_crossing_the_chasm/> >>> 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 >>> >>> On Friday, May 19, 2017 at 6:06:19 PM UTC+2, Matjaz Gregoric wrote: >>>> >>>> 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 >>>> >>> -- >>> 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 >>> >>> <https://groups.google.com/d/msgid/edx-code/1c0414bc-21ee-4bab-bea3-956c3c269e2a%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> >> -- >> Matjaz Gregoric >> @OpenCraft >> > -- 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/4e16ab3f-e308-4842-ba10-1d7ac57bf64e%40googlegroups.com.
