Simple theme style customisations without CSS

[hughbris]

Default colours

It would be nice to brand a site with a primary and secondary colour. Those colours should be specifyable through the admin interface.

Font

It would be nice, if the user could upload his own font for the site.

[hughbris]

Changing main theme colours

Having spent some time actively investigating this, I am not so sure it's possible without some compromises that go against the goal of the theme being trivial to install and use.

There are three important theme goals that are difficult to align in a solution:

1. The theme itself must be easy to update when changes to the Quark theme or the Spectre framework's CSS is updated. This objective is for the theme maintainer to publish new versions when these change without a lot of manual work. Ideally, changes upstream in Quark or Spectre are so trivial (algorithmically) that they can be reflected automatically via script.
2. The theme must be configurable and operable without the Admin plugin. We can use the Admin plugin to run scripts in response to certain configuration changes, but this leaves open the possibility that changes will be made by editing the configuration files directly and those scripts won't run. Furthermore, it may be a security/operational preference to not install Admin on production servers.
3. The theme must not require dependencies unless they can be installed via Admin. This limits what we can do to simple unzipping and to PHP code without any extra library dependencies. It means we cannot rely on build scripting tools like NPM or PHP libraries from Composer that are not already available to Grav.

I know the last two there seem inconsistent. I don't know a way to explain that they are not.

Here is an imperfectly recalled account of what I have investigated and tried.

Reproducing the Admin plugin UI

I tried this by copying Admin's blueprints to Particles.

I was able to embed the UI into the theme's admin but looking further into what happens after saving, PHP is required to recompile the SCSS. I could use that code, but it would require Admin to be installed with the theme (refer Goal 2). If I copy and adapt the PHP to avoid that dependency, then the theme would require PHP/Composer libraries as dependencies to compile the SCSS (refer Goal 3).

Switching to standard CSS

So I looked for ways to implement the theme in a robust (repeatable) way without SCSS. CSS variables are well supported now and provide a single place where a colour could be overridden for the theme.

I could do a one-off search-and-replace on the compiled CSS bundled with the theme, but that would need to be performed every time the source SCSS changes (refer Goal 1). This approach is complicated further by requiring SCSS functions like darken() without stable CSS analogues to derive some colours.

I looked at whether SCSS has a compilation option that outputs CSS variables in place of its own variables where possible. So instead of producing CSS with (for example) colour values like '#3085EE', SCSS could be configured to declare --primary-color: #3085EE and then use var(--primary-color) to reference it. Then we could simply override that CSS variable declaration to change the primary theme colour. Sadly, I did not find such an option in the CLI documentation.

---

Conclusions: The rubber duck method is real. It may be that a hybrid approach is the best option. Changes made in Admin piggyback off its SCSS recompilation and changes made manually require that developers update run scripts to apply their changes. This is fine if we accept that site administrators working directly with configuration files have the technical expertise to do this.

[hughbris]

Changing theme fonts

Investigations into implementing this also bore no satisfying solutions. Happily the investigations revealed that with less time spent :laughing:

The first approach was based on the naive assumptions that:

• we could provide a list of fonts installed on the Admin user's machine;
• the fonts selected would be available to website end users.

I guess the second one is not new and why CSS supports fallbacks when specifying fonts and ultimately recommends specifying a generic font family.

We can compile and provide a dropdown list of font sets including fallbacks and font families. This would need to be updated occasionally. It would be nicer to retrieve common font option sets from a web service.

There are also the same issues discussed for theme colours above of integrating CSS overrides into CSS generated from SCSS. There are not as many rules to override and they seem more straightforward, but it's all a bit fragile for my taste.

Web loaded fonts are another option but there are GDPR compliance implications with requiring them.