The Future of Stacks Discussion

Hey All,

How are you doing? Let’s talk about Stacks. We’ve had our eye on a Blank Stack for sometime, and we know many of you have as well. Originally, we thought just one new Stack would be sufficient, but on further review, we actually think there could/should be two. We’ll outline our thinking below, then we’d love to hear your Stack feedback, specifically on how you see Theme Options functioning in this world.

Starter Stack
Vision: This is the Stack we think most people are after when they request a Stack that doesn’t include styles. We do envision this having some style options (will explain why that’s needed with the Blank Stack idea below), but it leaves out things most people don’t need. Think simple buttons, sidebar looks nearly identical to WP, WooCommerce defaults are more basic, default templates are not used so Headers section is gone (and similar ones as well). There is a base level of styling and options and would be inspired from our Starter Template. The Starter Stack would most likely be our new default Stack for Pro.

Blank Stack
Vision: The Blank Stack would be reserved for advanced users as you potentially wouldn’t need Theme Options at all. This would give you the cleanest base from which to build your own styles but would require more administration on the setup side since it’s truly blank.

10 Likes

Hi Charlie,

You’ve just made my day. This is something I’ve been requesting for years in the forum. Thanks THEMECO for listening to us.

I’ll go for the Blank Stack for most of my projects but I think that the Starter Stack will be a fantastic asset to have at hand.

I’m wondering if, perhaps, you are thinking of merging the new “Components and Parameters” paradigm with the old “Theme Options” one?

Is there any ETA for this, at least for the Blank Stack –which seem to be the easier one to implement–?

Thank you! Thank you! Thank you!

2 Likes

Having two options sounds perfect for me!

2 Likes

+1 for having two options.

1 Like

That would be great, especially since I almost never touch that setting at all!
To be honest, I’m not sure how the stack affects the design when using Pro with custom headers/footers.

3 Likes

+1 for two options (+ the old ones for compatibility)

2 Likes

+1 - good thoughts

1 Like

For clarification the older stacks are not going away.

We would probably start this in a month or two and run it through a beta build.

3 Likes

One additional thought I’d like to see implemented is the ability to have a JSON configuration file that would allow me to start from the same place from build to build. A place I could configure all my colors, fonts and other settings in one file and import into a blank stack so I am starting with my starter that I like.

I would edit the colors and font choices for the needs I have for each one but it would allow for a quicker setup to get started.

11 Likes

Since the invention of the header / footer editor, I don’t tuch the stack settings. And Im always affraid of the effect these settings have on my designs. So for me working without any stack (or a blank one) would be great.
Having stacks for beginners is of cours also a good option.
In any case the theme options should be merged with the cornerstone settings, so there is only one place for i.e. font-settings (font-manager, default fonts for body and headings, sizes, scaling etc.).

1 Like

What would be really nice would be the ability to save out our stack to import into another site. similar to @simeoned 's idea but more like a template that could be imported.

even better again if there was a way to include our own components in a saved stack.

All probably beyond the scope of this work, but ideas for the future?

3 Likes

I’m all in for both options!

Adding Parameters to the Theme options page might be cool. Maybe we could wire up our own styles and even have an alternative to the ACF options page: create a global parameter and then call it through something like {{dc:global:sitewide-notice}}.

5 Likes

Brain Dump Incoming

So the color manager information is stored like this in the wp_options table in a record called cornerstone_color_items. It’s just an array of objects which is simple enough to edit and then place in the DB manually if you’re comfortable in phpMyAdmin or editing the DB otherwise. Works perfectly well. But there’s no reason we couldn’t have a more friendly way of doing this in an importer that accepts a JSON file so I don’t have to worry about the escaped quotes and the ID field could be generated instead of named manually and incremented like I’ve done below… I could also imaging that hex values could be automatically converted into rgb() automatically upon import (optional?):

[

{\"value\":\"rgb(0, 0, 0)\",\"title\":\"--primary-headlines\",\"_id\":\"common_use_001\"},
{\"value\":\"rgb(55, 55, 55)\",\"title\":\"--secondary-headlines\",\"_id\":\"common_use_002\"},
{\"value\":\"rgb(0, 0, 0)\",\"title\":\"--primary-body\",\"_id\":\"common_use_003/"},
{\"value\":\"rgb(55, 55, 55)\",\"title\":\"--secondary-body\",\"_id\":\"common_use_004\"},
{\"value\":\"rgb(255, 255, 255)\",\"title\":\"--very-light-text\",\"_id\":\"common_use_005\"},
{\"value\":\"rgb(0, 0, 0)\",\"title\":\"--very-dark-text\",\"_id\":\"common_use_006\"},
{\"value\":\"rgb(0, 0, 255)\",\"title\":\"--link\",\"_id\":\"common_use_007\"},
{\"value\":\"rgb(0, 255, 0)\",\"title\":\"--link-interaction\",\"_id\":\"common_use_008\"},

{\"value\":\"#50_HEX_CODE\",\"title\":\"--SHADE_GROUP_1_COLOR_NAME-50\",\"_id\":\"custom_color_001\"},
{\"value\":\"#100_HEX_CODE\",\"title\":\"--SHADE_GROUP_1_COLOR_NAME-100\",\"_id\":\"custom_color_002\"},
{\"value\":\"#200_HEX_CODE\",\"title\":\"--SHADE_GROUP_1_COLOR_NAME-200\",\"_id\":\"custom_color_003\"},
{\"value\":\"#300_HEX_CODE\",\"title\":\"--SHADE_GROUP_1_COLOR_NAME-300\",\"_id\":\"custom_color_004\"},
{\"value\":\"#400_HEX_CODE\",\"title\":\"--SHADE_GROUP_1_COLOR_NAME-400\",\"_id\":\"custom_color_005\"},
{\"value\":\"#500_HEX_CODE\",\"title\":\"--SHADE_GROUP_1_COLOR_NAME-500\",\"_id\":\"custom_color_006\"},
{\"value\":\"#600_HEX_CODE\",\"title\":\"--SHADE_GROUP_1_COLOR_NAME-600\",\"_id\":\"custom_color_007\"},
{\"value\":\"#700_HEX_CODE\",\"title\":\"--SHADE_GROUP_1_COLOR_NAME-700\",\"_id\":\"custom_color_008\"},
{\"value\":\"#800_HEX_CODE\",\"title\":\"--SHADE_GROUP_1_COLOR_NAME-800\",\"_id\":\"custom_color_009\"},
{\"value\":\"#900_HEX_CODE\",\"title\":\"--SHADE_GROUP_1_COLOR_NAME-900\",\"_id\":\"custom_color_010\"}
 
]

Then I add as many other groups of shades I need for the project. I then make CSS variables with the same names and use them in the project’s child stylesheet as needed. It requires some planning to set up but I have it pretty streamlined now.

Two additional thoughts occur to me as I was getting this together. Just brainstorming here:

  1. Have the ability to flag a color (or shade in this case) visually so it can me marked as “Primary” or “Default” in some way. Basically, the ability to place an extra custom label on a color. This would be particularly useful for this kind of Tailwind inspired shade setup.

  2. I’d love to map a color to another color. So that I could have all of these shades defined in there for general use and reference but maybe for example, the more semantically named --primary-headline might need to be the same color value as --SHADE_GROUP_1_COLOR_NAME-500, for example. This is just a way to keep things semantic for commonly used elements.

I can imagine the need to update the color of headlines in the future maybe. I’ll want to keep my shade pallet in tact as a whole but maybe I associate the headline with --SHADE_GROUP_1_COLOR_NAME-800 instead. Would just like a way to indicate that somehow visually (like, maybe there’s no actual technical mapping taking place. Changing one doesn’t change the other? Not sure about this… just brain dumping here like I said). Again, this might be largely just a UI element to enhance UX in a developer friendly way.

So those are my thoughts and a little bit about what I’m currently doing to help stand up a new site a little quicker than inputting all the colors I need in the Cornerstone UI.

What other base setup imports might be a good idea along side this one I wonder?

4 Likes

Nice, looking forward to a cleaner stack.

As for theme options, I’d love expanded options to control default styling for any element. Basically the ability to implement a design system that also affects elements and areas of the site that aren’t covered by Cornerstone. The WordPress comments section and blog post content for example.

I also imagine this would be a good place to allow us to create a list of CSS custom properties (variables) to be used anywhere on the site.

Also, an option to have a dark mode switch in the theme. In theme options we could make a dark mode palette and offer a light/dark mode switch on the front-end, with auto-detection of the users system preference for this. I think it’s about time for a dark mode option :sunglasses:

As others have mentioned, an import/export feature for the theme options config.

2 Likes

Will there be an option to delete unused stacks?

I started typing up something similar to this.

The dark mode option would also be a great feature.

2 Likes

This is very true. Anything that goes on inside the Content area is left for the global styles. A lot of custom CSS goes into getting the Post content behaving the way we want.

3 Likes

This is great stuff everybody. Ideas like using parameters, exports and imports, dark mode, and shades definitely weren’t on my mind. Using parameters being the big ticket idea I think. We’d like to talk flow in a week or two. Assuming your stack options can be accessed through {{dc:theme:YOUR_OPTION}} or cs_get_theme_option('YOUR_OPTION') how do you then see yourself using this? Global CSS seems like the most obvious and simplest, but curious your thoughts.

Keep the ideas coming even if out of the scope of the initial release, it can be easier to implement things for the future when you know where you are going.

No because they would just get reuploaded every update. We can give you an option to hide stacks you won’t use.

3 Likes

I’d also like to suggest that the Colors manager needs the ability to create different palettes that we can name for different purposes. Something to group colors together instead of there being just 1 generic title called “Palette” like there is.

3 Likes

I often set up an ACF options page to output some sitewide things. Sometimes it is a toggle to turn a sitewide-notice above the header, with fields for the content and button text/link.

I also like to have a global field for the Company SVG logo, so I can output it in various places where needed. Sometimes I create a dark/light version CSS so I change it depending on the background.

Another use case might be a simple text field for updating working hours, or outputting various JSON-LD schema that is not covered with the Snippet extension. All this could be done with global parameters.

I also set up repeater fields on options pages, for example if a company has more branches. Repeaters can be easily replaced by the List parameter.

Having parameters on the theme options page would mean that sometimes we don’t have to Install ACF at all. All that is assuming that the Theme options approach would perform better, and I think it would. :slight_smile:

While on the options topic, There is a page-level setting to allow comments. image
This is turned off by default and that is great, but I have noticed that the /wp-includes/js/comment-reply.min.js is still being requested and loaded. Perhaps that could be dequeued by default, unless Allow comments is turned on?

I’d also suggest to add the option to disable emojis on the page settings. /wp-includes/js/wp-emoji-release.min.js is often being requested for nothing, and it is a blocking script.

6 Likes