Multiple Site Customisations at once

spec
rfc

(Sam Saffron) #1

Problem

At the moment you can not enable multiple site customizations at once, even though the UI misleads you to think you can.

Spec

  1. Add a “position” field to the site_customization table

  2. Allow people to order the customizations (highlight selected)

  3. Amend the internals to include multiple customizations in the correct order (one file only for css)

  4. Add a new hidden site setting “suppress_default_style_sheet” default false. Allow people to toggle it from this screen. Rip it out of the site customization model.


Site Customizations: Only One Enabled at Once?
Custom CSS changes not taking effect
CSS/header customizations randomly failing to apply
What about an easier styling/theming system?
(Vikhyat Korrapati) #2

This would mean the “Do not include standard style sheet” / override_default option would have to be moved to a site setting, right?


(Sam Saffron) #3

A hidden one, will amend the spec … hold tight a sec and behold live edit do its magic.


(Sebastien Miquerolle) #4

Sounds good ! I’d like to split my 900+ lines of my custom css ^^


(TheLoneCuber) #5

This just costs me 3 hours of troubleshooting: is it still the case that only one customisation can be enabled at a time? If so, can a simple notice be added on the existing customisation page to point out this bug, because I’m surely not the first or last who’ll fall victim to it?

And as @Sam points out, the UI does mislead you into thinking that multiple customisations work. So I was modulating my CSS, which, as it turns out, Discourse punishes you for [the good practice of].

As a new Discourse user I’ve been very impressed by the platform. But, I’ve spent ten times longer troubleshooting on meta.discourse.org than I’ve spent tweaking my own instance of it. And when you’re setting up a new Discourse and making many changes, it’s not always obvious what has caused a problem. So you search on Meta, find a topic that might be the cause, reply to it (which bumps it up to top of Meta, making others more likely to find it), only to later discover that that topic is totally unrelated to your problem and had the known problem been made known to everyone in the UI then we’d all be having a much better experience.

Why not tell all users what is already known — that only one customisation can be enabled at a time — instead of forcing them to fall into the trap and then find their own way out?


(Jeff Atwood) #6

I have said for a long time that this multiple customization crap needs to be pulled. Way too complex for no real benefit. Cc: @sam


(Sam Saffron) #7

I gives zero option to work on a new design, I am happy to change it so there are 2 options though.

“work in progress” and “live”

I still think long term this spec is best because it allows users create more modular customisations. It is often easier to work with 10 css files than 1 css file that has everything.


(TheLoneCuber) #8

I’m all for modularity, especially in Discourse customisations, and I would hate to see it disappear. Multiple customisations allow you to easily trial and/or troubleshoot mods with great[er] ease. I just think users should know that they can’t run more than one mod at once.


#9

Another +1, would be nice to be able to split CSS into different files so that features/themes could be easily activated/deactivated while keeping a central base/foundation theme active.


(Sam Saffron) #10

Already implemented now


(Franz) #11

Does the latest version (beta5) support multiple simultaneous customizations? I seem to have problems with this…


(Franz) #12

My bad, it appears to work properly. I simply had to adapt some of our CSS code.


(Jeff Atwood) #13