Retrieving and updating all available palettes on an instance?

From a theme's perspective, a palette is no different than its defined configuration like a CSS file, in that it's just script the theme consumes. A palette is a pre-defined grouping of configuration options of any types for the user to select through theme options. So, you can customize the Social theme's out-of-the-box palettes or add entirely new palette types to the theme to support selecting other types of configuration groupings.

However, like other components of a theme's definition like its script files, there isn't currently a public API for editing these - just for consuming them within the theme itself.

What are you trying to achieve? There may be a better approach.

I am considering possible approaches for changing the palette color settings (background and text color) through UI. How is it done for other settings in the theme (for example, general background color) for community managers without advanced experience (editing XML files).

Michael Monteleone said:

However, like other components of a theme's definition like its script files, there isn't currently a public API for editing these - just for consuming them within the theme itself.

Thank you so much. It was helpful!

Dmitry Mandrichenko said:

for community managers without advanced experience

This is precisely the goal of the newer theming system introduced with Theme Studio in version 10.2 and later. Before Theme Studio, if you wanted to change a theme's styling, it would have required adding/editing CSS. With Theme Studio, a theme can define configurable options which are exposed to non-developer administrators through Theme Options and consumed by the theme's own style sheets.

So, if you had the following:

<div id="myDiv">My Content</div>

And it was styled with a red background but an administrator wanted to change that:

#myDiv {
  background-color: #FF0000;
}

Previously, an administrator would have needed to add a custom stylesheet to override that. With a Theme Studio theme, the theme's definition can instead have the following option defined in its configuration XML:

<property id="myDivColor" labelText="My Div Background Color" defaultValue="#FF0000" dataType="Color" />

And then consume that property within the stylesheet:

#myDiv {
  background-color: -evo-themeconfig-color('myDivColor', #FF0000);
}

This tells the sheet to use whatever color is configured for myDivColor, defaulting to #FF0000.

Then, in Theme Options, a non-developer can adjust the div's background color:

That brings us to palettes.

A challenge posed with exposing all possible options through configuration is that not only are administrators often non-developers, but they're also often non-designers. For cases in which a designer has specifically chosen combinations of colors, fonts, and other styling options (say, for branding) but still wants to afford some level of customization, palettes enable this. A designer and developer can define palette types within a theme, and within each type, can define any number of preset palettes containing values for all the config options that palette type defines. A theme's definition consumes a palette option in much the same way it consumes a normal theme config option. But an administrator then sees a list of selectable palettes for the palette type within Theme Options instead of editable raw values for all of the palette's options.

So, for your case, it may be a matter of exposing options you want to be editable to theme configuration.

For more more info:

Dmitry Mandrichenko said:

for community managers without advanced experience

This is precisely the goal of the newer theming system introduced with Theme Studio in version 10.2 and later. Before Theme Studio, if you wanted to change a theme's styling, it would have required adding/editing CSS. With Theme Studio, a theme can define configurable options which are exposed to non-developer administrators through Theme Options and consumed by the theme's own style sheets.

So, if you had the following:

<div id="myDiv">My Content</div>

And it was styled with a red background but an administrator wanted to change that:

#myDiv {
  background-color: #FF0000;
}

Previously, an administrator would have needed to add a custom stylesheet to override that. With a Theme Studio theme, the theme's definition can instead have the following option defined in its configuration XML:

<property id="myDivColor" labelText="My Div Background Color" defaultValue="#FF0000" dataType="Color" />

And then consume that property within the stylesheet:

#myDiv {
  background-color: -evo-themeconfig-color('myDivColor', #FF0000);
}

This tells the sheet to use whatever color is configured for myDivColor, defaulting to #FF0000.

Then, in Theme Options, a non-developer can adjust the div's background color:

That brings us to palettes.

A challenge posed with exposing all possible options through configuration is that not only are administrators often non-developers, but they're also often non-designers. For cases in which a designer has specifically chosen combinations of colors, fonts, and other styling options (say, for branding) but still wants to afford some level of customization, palettes enable this. A designer and developer can define palette types within a theme, and within each type, can define any number of preset palettes containing values for all the config options that palette type defines. A theme's definition consumes a palette option in much the same way it consumes a normal theme config option. But an administrator then sees a list of selectable palettes for the palette type within Theme Options instead of editable raw values for all of the palette's options.

So, for your case, it may be a matter of exposing options you want to be editable to theme configuration.

For more more info: