I guess, ordering and grouping is a challenge. But some stuff can wait for a v2.
I think that having “composable” themes is likely going to cause more headaches than it will solve – unless themes are forced to be really really simple. I foresee themes that use JavaScript to achieve certain effects, and we all know that there’s an awful lot of JS code out there that doesn’t play nicely with others. 
By “github” do you mean Git? Or will this be hitching Discourse’s theme support irrevocably to a specific Git provider? This could have ramifications for companies using Discourse who prefer to not host their theme publicly, or pay for private repositories on GitHub.
I’m not sure how it works under the hood at present in Discourse, but is it worth thinking about “full themes”, in which no out-of-the-box CSS/templates are loaded at all – only that of the theme? That would facilitate light-weight, super-fast themes…
4 Likes
Yeah that it a good point, v1 will not be composable, except that site customization will be able to apply to “all themes” or a “single theme”
Yeah any git source is fine.
1 Like
What do you think about allowing normal users to preview a theme by passing the theme URL as a query parameter?
That would allow sharing ideas before they are enabled by admin as the default.
Along the same lines, I’m wondering what other things could be done to allow non-admin designers to iterate more quickly to develop new themes.
I do want to get to allowing users to select themes and coupling a user account with a theme… But the ability to inject an external theme into a site by an end user is going to have to be a plugin to start off.
2 Likes
Great idea.
I’ve been working on an update to my material design theme and learning the front end API as I’m going along.
From this, thinking If all CSS classes within widgets were undateable at runtime, perhaps using the API widget settings mechanism added by @eviltrout below, it would open up extensive conditional formatting options.
2 Likes
I’d love to see that!
I’d consider this a disadvantage… 
2 Likes
True that
A major disadvantage
I think proper versioning is just as important for themes as it would be for plugins.
Had any site been using a custom theme when we launched our new vertical sidebar, that update would have almost certainly broken their site. It was already a challenge for sites with basic HTML & CSS customisations. We also have to assume that some forums will be using themes that they themselves did not make, but rather a 3rd party did, as is the case for 99% of WordPress sites. Which means they’re at the mercy of a 3rd party should an update unexpectedly break their site.
6 Likes
Do we also want to support theme use cases like this one?
https://meta.discourse.org/t/using-discourse-to-host-a-knowledge-base/34036/9?u=erlend_sh
4 Likes
Great initiative! Here are a couple of areas I believe are important to make it easy to develop themes.
- Use a documented naming convention for CSS classes
- Fast development workflow to update themes
- Control and customization over Discourse features
Whether you go for SUIT CSS naming conventions or something else is a topic for another day, but with a documented naming convention people would find it easier to recognise classes, which to use and which to avoid. Avoiding ids in the default Discourse CSS would be nice as well as removing unused classes in the markup.
If it is possible to poll, pull themes via git and update themes automatically (or something smarter?) it would be really great. Also, is overwriting or extending handlebars templates something that is encouraged? If so, themes should have an easy way to do so.
If it’s possible to decide which Discourse features you want and not, it would be even easier to theme. For instance, some won’t want the new (and very useful) sidebar on topics or the sticky header . Instead of hacking these features away it would be nice with a checkbox to simply disable those features. We should also make sure that all colours in use actually have a corresponding setting in the color-section of the admin panel.
3 Likes
I am also interested in ways to have pre populated data. My example would be a shell for online courses, but a module of other guidance to get started is another.
How about a plugin that would pull in code to add to the current customize interface? It could pull from github.com and add in themes that way. How hard would that be?
And then, how hard would it be to have a plugin that pulled in a set of topics that it would create, or update when a new version was available?
An ode to the Discourse 2013 theme
It’s been 3 years since Discourse went flat, and I still haven’t forgotten about the good old days when boxes and buttons had some meat on them:
.
See “A first look at Discourse” for a quick trip down memory lane.
I’m not saying it was objectively better, but I do miss it. Our current theme is ruthlessly functional - which makes perfect sense for a default, baseline theme - but it lacks personality.
These applications have personality:
I’m very excitedly looking forward to the day when we can reintroduce “Discourse 2013” as an alternative stock theme, alongside many others 
8 Likes
Any update on this ?
Trying to migrate a community from phpbb to Discourse, all I can hear is “I want my dark theme” or “I want my light theme”
Haven’t found a plugin allowing to switch between two css/color 
1 Like
We will get there, but probably not for the upcoming release, hoping for some time in first quarter of 2017, no promises.
5 Likes
In the meantime there are browser plugins that will shift any site from light to dark as needed.
Some things I’m still not seeing answered in the basic spec:
-
Could a theme bring its own custom plugin outlets?
-
Reiterating what @Oskar asked:
Do we want to support custom templates in the v1 of themes? I certainly think it makes sense to bundle that in there. For example, if you style your theme around a custom desktop_category_page_style that you’ve added, the template and theme are basically codependent.
1 Like
Yes, absolutely
Well, this is already supported in site customizations, no reason not to support it in themes.
3 Likes
First iteration of native themes is now merged per this giant commit.
Following up with specific #howto topics to explain the new system
14 Likes