Customizing the Solidus Admin Styles


Over the holiday season I spent some time (okay, mostly company time) working on Solidus. As a frontendy person, a lot of my efforts have been UI/UX related, with a focus on the admin area. It's one thing to maintain a reliable ecommerce platform, it's another thing entirely to make that application pleasing to manage.

The out-of-the-box Solidus admin area looks a little dated (it's something we're working on) but there are a number of things you can do to customize it. Replacing the logo, changing the colors and overriding styles are easy ways to make it feel like your own.

Changing the Logo

By default, the Solidus frontend and backend both use the same logo. You can either replace this logo directly or point one or both of them to other image assets in the spree initializer.

sweet new solidus logo

Changing Colors

Many Solidus styles are controlled by variables. Most of these variables are color related, and although they don't always give us the control we would like, small changes to these values can have drastic impacts on the backend experience.

Solidus provides a hook into the variables in the form of variablesoverride.scss, which is Sass imported before globals/_variables.scss. This file makes extensive use of Sass !default. If we add our own _variables_override.scss then any variables we define will take precedence.

Solidus has some (unfortunately named) global colours, which are re-used extensively throughout the admin styles. I favour a two-step process to organizing a colour palette in a sass project. First I give each colour a self descriptive name.

// app/assest/stylesheets/spree/backend/globals/_variables_override.scss

$black:                          #0C141F;
$cyan:                           #6FC3DF;
$orange:                         #DF740C;
$yellow:                         #FFE64D;

$color-1:                        $black;
$color-2:                        $orange;
$color-3:                        $cyan;
$color-6:                        $yellow;

That way, when I'm overriding semantically named variables I find it easier to picture the output.

$color-tbl-even:                 $black;
$color-tbl-thead:                $black;

Although most variables in this file control colours, the font-family is included, and I'll be doing my best in the future to expand this list with controls for any component you might want to tweak.

@import url(https://fonts.googleapis.com/css?family=Orbitron);
$base-font-family: "Orbitron", sans-serif;

Overriding Styles

At the end of the day, the most powerful tool at our disposal is just writing more css to enhance or modify existing styles. The admin layout includes an all.css which is generated upon Solidus install and uses *= require_tree . to pull in everything from vendor/assets/stylesheets/spree/backend/.

So if we were to add our own stylesheets there (or put a placeholder there and do our actual work in app the same way _variables_override.scss works) we can include any arbitrary styles without having to override any layouts.

We'll get started by @importing the same constants. When using Sprockets directives, Sass files exist within their own scope, making variables or mixins only available within the document they were defined.

// vendor/assets/stylesheets/spree/backend/custom.scss

@import 'spree/backend/globals/variables_override';
@import 'spree/backend/globals/variables';

On a real project, I would probably organize my styles into separate partials and simply @import them all in a single manifest. Also, I would prefer establishing semantic variable names in my _variables_override.scss, but for expediency let's just make a couple quick changes.

.button {
  background: $color-2;
}

table thead th,
table td,
table th:first-child,
table td:first-child,
table tbody tr:first-child td {
  border-color: $color-1;
}

#content-header {
  background: $color-1;
}

These selectors were chosen carefully, by inspecting the current styles and tracing them back to their origins in Solidus so that I could use the smallest possible specificity, a practice which avoids escalating problems in the future (and the inevitable !important battles).

We'll add one really fancy selector too, with the help of a Bourbon mixin. I imagine Solidus will always use Bourbon, but before using any gems in your application code you'll want to add them to your own gemfile.

@import 'bourbon';

#{$all-text-inputs} {
  background: $color-6;
  border-color: $color-6;
}

And we're done. Changing 1 logo, 1 font, 6 colours, and 5 styles is all we need to implement SolidTron!

totally legit rebrand

Disclaimer: This theme represents the warped humour of the author only, and does not reflect the design goals of Stembolt or Solidus.














Sneak Peak: Solidus Rebrand!

As part of the plan for revamping the Solidus admin area, starting with Solidus 1.2 we've begun adding hidden styles to the project. Right now it's just some new colors for the sidebar, but if you want to include them and follow the development of our new theme, just add the following line to your variables_override.scss.

// spree/backend/globals/variables_override
@import 'spree/backend/themes/blue_steel/globals/variables_override';

admin sidebar