Theming Advisory Group meeting - Tuesday, March 26, 2019

In Attendance

  • Steven Burch
  • Giulio Gratta

  • John Baldwin

  • Braden MacDonald

  • Felipe Montoya

  • Nimisha Asthagiri
  • David Joy

User stories


  • Look and feel
  • Feature development
    • Hiding, replacing, adding features
    • Adding disclamers
    • Adding HTML to sidebar, header, footer
  • Have their own instances, each individually branded.
  • Three separate prod deployments:
    • On campus instance
    • MOOC offering
    • Med school instance
    • Always the same platform code
    • Customizations are feature flagged
    • Use theming to hide SSO accounts tab
  • Can't use the word "student" in some instances, for instance.
  • SSO exclusively, no unlinking accounts
  • Fork the platform
  • One repo for all themes
  • Fork of pattern libraries
  • Ginko


  • Customers: tech companies and education resellers
  • Multi-tenancy
  • Enterprise customers with standalone instances.
  • Look and feel
  • Need look and feel consistency with external environments
  • Fork of platform, different branches for different needs (multi-tenancy vs. Enterprise)
  • Enterprise share same branch and use feature flags
  • Upgrades are horrible pain.
  • Want plugin architecture, been thinking about their own.
  • Figures
    • Need customization on frontend
    • Need custom cards/UI elements
    • Brand new code
  • Email formatting is hard


  • Does not fork platform.
  • Customizations done as theming, plugins, or features which get contributed back.
    • Limits their ability to do detailed theming, have to say 'no' sometimes.
    • Template overrides
    • CSS
    • Use translation files to change phrases.
  • Dozens of instances, very easy to upgrade/maintain.
  • Want better theming, still without customization/forking.
  • Want plugin architecture
  • No multi-tenancy
  • Want real-time theming
    • Client uploads logo, sees it immediately for instance.
  • Email formatting is hard
    • Nimisha says: Maybe better in Ironwood?


  • Three types of instances
    • Customized instances for people in their own data centers/AWS accounts
      • Big customers, very opinionated
      • Code lives in fork.
      • Try to use theming if they can, otherwise change code.
    • - Multi-tenant instance with 3000 sites
      • Use theming to make them all look different
      • Microsites used to change feature flags per client, add custom CSS, etc.
      • Site configurations change themplate path and swap themes for each customer.
    • Consulting for large projects. Super customized. Example: replace ecommerce with something else.
  • Different types in different forks.
  • 60 features added.
  • Don't merge back.
  • Every few months, take what's on Hawthorn master and build their features on top of it.
    • Extensive doc on how to do this.

General comments

  • OEP process: be more communicative
  • Why react? Wide adoption, Facebook adopted React, not bleeding edge, but solid and meets business needs.
  • Need to communicate timelines for deprecation. Juniper? Later? Need to know far enough in advance that it's not a surprise and there's time to update/adopt it.
  • Feature flags for each of the micro-frontends is a good thing.
  • Don't want to rewrite themes with every named release.
  • Pattern library: just kill it! Put styling somewhere else.
  • Start getting down to brass tacks with practical proposals for customization - move on from requirements gathering.
  • If devstack looked different than, many upgrade problems would be fixed.
  • "Make the common case fast, make the uncommon case possible."
  • Page that is a particular theming pain point? Dashboard.