[FEATURE] Theme Support

[kenspy]

Considering the bright future a head of the Houdini project, I was wondering if Theme support was planned in the next release. It would open the door for more developers to get involve, allowing them to develop custom themes for the Houdini Platform.

Describe the solution you'd like I image the structure would go something like this:

houdini root -- / 
    -- app/  
        -- themes/  
            -- [theme_name_1]/  
                -- views/  
            -- [theme_name_2]/  
                -- views/  

I found a package called themes_on_rails, perhaps it can be used as an example for reference. https://github.com/chamnap/themes_on_rails

[wwahammy]

Thanks @kenspy and welcome to Houdini!

Limited theme support is planned for for the next release. This gives me an opportunity to discuss some of the constraints on theming and how we might address them.

There's a few things about Houdini theming that need to be consider. Houdini has multiple levels of configuration, including theming, for different entities involved. Those levels aren't always super well separated right now but they do exist. The levels include:

• The hoster - the hoster is the entity that runs an Houdini instance. As an example, CommitChange is a hoster. As it relates to theming, the hoster might configure the default colors, the colors, icons and logos of non-nonprofit branded pages (like say, the dashboard). In a more advanced theming system, the hoster could actually reorganize the way pages are structured and displayed. Currently, most of this is hardcoded into the system so there isn't one single place to change it.
• The nonprofit - a nonprofit is an organization (usually charitable but doesn't have to be) that wants to receive some sort of financial contributions from supporters. The nonprofit may want to change the default theme for their donation pages, widgets, campaign pages, event pages and receipts for donors. As an example, the hoster might have the default color for UI elements to be blue while the nonprofit may want it to be green. A limited form of this is currently possible from Nonprofit settings
• Campaign and event - Campaigns and events belong to a nonprofit and by default reuse the nonprofit's theme. While not currently possible, it would make sense for campaign and event creators to be able to override those themes.
• Widgets - widgets are the embedded buttons and iframes which allow a nonprofit to place a donation button or form onto their website. Currently, these widgets all inherit the themes from the nonprofit. In the future, it would make sense for these to inherit from campaigns and events if the widget is related to a campaign or event AND it should be possible to override the theme at the widget level.

Given all this, I think we should start in a pretty limited fashion. A good place to start may be to document what it is that we want customizable. I think the obvious ones to consider and what levels they should be configurable at:

• UI highlight color (Hoster, Nonprofit, Campaign/Event, Widget) - We currently do this in Houdini for nonprofits.
• Hoster logo (Hoster)- Only really makes sense at the hoster level. But you need it in different parts of the website.
• Logo (Nonprofit, Campaign/Event?, Widget?) - traditionally not considered part of the theme but it is sort of related. This would include logos for a set of different sizes
• Font color (Hoster, Nonprofit?, Campaign/Event?, Widget?) - By default, if the font color isn't set, we use font colors that contrast appropriately with the UI highlight color. I worry that if we allow BOTH UI and font color to be set by Nonprofits and lower, people will create non-accessible font and color combinations which don't have enough contrast. If we do allow it, we should have warnings in appropriate places to discourage bad color combinations.
• Font (Hoster, Nonprofit?, Campaign/Event?, Widget?) - We do this in Houdini for Nonprofit but I'm not sure how useful it is. There are issues related to accessibility here as well for allowing it at the nonprofit level and lower
• Font size (Hoster, Nonprofit?, Campaign/Event?, Widget?) - If we allow fonts to be modified by Nonprofits and lower, then we probably should allow font sizes to be changed. This gets into some difficult areas though because font size changes may require allowing changing of spacing.

Other items to consider:

• Everything in the default theme of Material-UI since we're going to be using Material-UI going forward. One worry about this is if we allow too much flexibility right now, it will makes Houdini harder to develop. The reason is you need to be prepared for Houdini users to modify things in ways that would be hard to predict. But we should see if there's anything here we should include from there.

Did all of that make sense @kenspy? What are your thoughts?

[kenspy]

@wwahammy, I completely understand your approach and it will indeed be more flexible for the users to customize they front-end.

Originally, I was thinking of creating custom templates for the Hoster, the Hoster theme would include different layout for the Nonprofits. However, with Houdini's current file format it might be difficult to maintain.

Unless, Houdini manages to separate the Core files from the Theme files (I am not sure if it will be possible), it would be beneficial in the future if you decide to implement plugins/modules. Since you mentioned "widgets" I can safely assume implementing plugins is not far behind.

Example:

root/  
  -- admin/  
  -- core/  
  -- app/
         -- themes
             -- houdini/  
             -- commitchange/  
         -- plugins  
             -- quickbook/  
     

The approach you mentioned above are end-user oriented, I was leaning toward a developer standpoint.