Native theme support

[sam]

Could you elaborate on this? I understand that different themes could target separate parts of the frontend, but does this imply the need for an ordering/cascading mechanism?

I guess, ordering and grouping is a challenge. But some stuff can wait for a v2.

[barryvan]

Themes are easily composable, you can enable 1 or many.

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.

Allow easily to add and remove themes (from github branch or filesystem) via the admin panel

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…

[sam]

I think that having “composable” themes is likely going to cause more headaches

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”

By “github” do you mean Git?

Yeah any git source is fine.

[mcwumbly]

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.

[sam]

What do you think about allowing normal users to preview a theme by passing the theme URL as a query parameter?

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.

[ccdw]

Easily distributable, safe, visual extensions to Discourse.

Great idea.

Themes have zero access to the backend code, can only amend frontend

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.

Avatar size handlebars script no longer working

This is a great idea so I implemented in in the latest master.

A widget can now have settings:

Avatar size handlebars script no longer working

And there is a new API call to update them:

[fefrei]

I’d love to see that!

Tricky to install as it requires a container rebuild

I’d consider this a disadvantage…

[sam]

True that

A major disadvantage

[erlend_sh]

I think proper versioning is just as important for themes as it would be for plugins.

Compatibility checks and stable versioning for plugins

This recently came up: There’s got to be a better way to do this. It seems very wrong to neglect users who’ve chosen to stay on the Stable updates branch. Some options: 1 - Plugins have “stable” and “beta” branches as well. Quite simply, once you begin working on a plugin against a beta-version of Discourse, you could do so in the plugin’s respective beta-branch. 2 - Plugins expose version-compatibility I don’t know how realistic this is, but I was thinking it might be possible to put this …

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.

[erlend_sh]

Do we also want to support theme use cases like this one?

Using Discourse to host a Knowledge Base

I now have a working(ish) sample http://community.quickfile.co.uk/c/knowledgebase Here’s a typical KB article: Sole Trader Bookkeeping - The Basics It’s desktop only and still very unrefined! The biggest problem for me at the moment is figuring out how to stop the menu disappearing when drilling down into the sub-category, I need to do a page reload to get it back again. Still looking at that one. EDIT 1: OK putting the markup in the header rather than the footer fixed the disappea…

[Oskar]

Great initiative! Here are a couple of areas I believe are important to make it easy to develop themes.

1. Use a documented naming convention for CSS classes
2. Fast development workflow to update themes
3. 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.

[pfaffman]

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?

[erlend_sh]

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

[Vernam]

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

[sam]

We will get there, but probably not for the upcoming release, hoping for some time in first quarter of 2017, no promises.

[codinghorror]

In the meantime there are browser plugins that will shift any site from light to dark as needed.

[erlend_sh]

Some things I’m still not seeing answered in the basic spec:

1. Could a theme bring its own custom plugin outlets?

2. Reiterating what @Oskar asked:

Also, is overwriting or extending handlebars templates something that is encouraged? If so, themes should have an easy way to do so.

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.

[sam]

Could a theme bring its own custom plugin outlets?

Yes, absolutely

Do we want to support custom templates in the v1 of themes?

Well, this is already supported in site customizations, no reason not to support it in themes.

[sam]

First iteration of native themes is now merged per this giant commit.

Following up with specific #howto topics to explain the new system

[sam]

How to develop custom themes

Discourse now supports native themes that can be sourced from a remote git repository. Recently we also added support for branches and private repositories. [image] Note that Import and Export from a dcstyle file still exists. [image] An example theme is at: https://github.com/SamSaffron/discourse-simple-theme [image] The theme will be synchronized to the git repository used (once a day), any changes made to the repository will be detected clicking the Check for Updates button. When change…