Design File - Colour Theme variables

(Emily) #1

Matrix Version: 5.5.0.0

Hi there Squizers & Squizees (pretty sure they should be terms to describe staff & users!),

I can’t believe it has taken me so long to actually need to do this; and I’m pretty sure someone here will have done it a million times & figured out the most robust & user-friendly way to do it. If you have, would love to hear your thoughts…

I want backend/admin users (non-coders) to be able to switch colour-themes of components of the Design file, to mix & match as they want. These would then be applied to the whole site – so a design customisation makes sense for storing these variables.

The colour-themes require different (or extra) classes to be applied to specific elements, depending on the one selected.

What is the best way to achieve this?
… Declared variables? Show-If areas?

I know JS is an option, but wondering if there is an easier matrix-way, so it is easy for HTML/CSS-only coders to update in the future (i.e. those who don’t know much JS).

I’ve actually never used the Declared Variables, as most of my dynamic content has been modified by metadata as variables instead (on a page basis), or by switching areas on/off. I am wondering if it is going to get messy, when I have (for example) 5 different component areas, each which have a “light” or “dark” theme option, that can be selected. And then for each of those component areas, an additional class would have to be added to about 3-4 parts of the code (but each section of the code requires a different class, depending on the element).

I don’t want the editors to need to know the class they need to put into each component’s elements. I just want them to be able to select “Component ABC: Light theme” and “Component XYZ: Dark theme.”

Not sure I have managed to explain it adequately, but hoping the context helps explain.

Let me know if you have done this, & what your preferred method is/was :slight_smile:

Thanks in advance,
Emily

#2

You can create a metadata schema with fields determining the component options, applied to the site asset. Use these to conditionally output class names to the body tag. Rename site styles appropriately EG .dark_theme .my_widget { … }

In your body class:

<mysource_area id_name='body_classes' design_area='nest_content' />

Customise this nested content area to an asset with the site metadata values printed in Raw HTML:

%globals_site_metadata_theme_field1% %globals_site_metadata_theme_field2% ...

Depending on how many components you want to customise, whatever your approach you’ll probably have a better time creating theme options that impact all components, rather than 1 theme option per component.

If you must do it at a component level, you’d probably be better off implementing them as container templates.

(Emily) #3

Hi bkelly,

Yes, metadata schema was one of my thoughts. Just that it would be a lot of fields. But perhaps metadata fields are the best/easiest/editor-friendly ‘variables’ method, using a select dropdown! :slight_smile:

I guess the metadata schema for the site-wide Design only needs to be on the Site asset, or the Homepage asset (e.g.) and then use the specific ID in the keyword modifier to read from only that asset. Then an editor can’t “accidentally” change it for the single page. (This would be for header background & text colours, footers, etc etc)

I do plan to use Content Container Templates for the page-content variations. This question was about the parts that are in (or linked to) to the Design File – which we don’t want editors to have to do any code-fiddling.

I believe the reason I have been asked to set it up with individual components able to switch colours/shade is so it can be reused by many different sites and changed as wanted. That way they can mix & match for form a combination they like.