Color scheme names cannot be edited
I understand that color scheme names cannot be changed. But please, add an alias for display purposes in customizer so that we can add custom naming to color schemes.
Since this feature request got as lot of traction on Linkedin - i thought i should officially request it here.
Feature request
This definitely would be useful, I suppose we can do this on preset ones, but if adding a new one it generates it, being able to label a colour scheme like we can do for sections now etc would be great.
Obligatory meme. Personally, I find them too rigid and never managed to integrate them in my processes. Color metaobject references for the win !
I think they only work if you’re building from scratch, implementing them in an already built theme would be very cumbersome.
They are somehow rigid indeed and it’s a learning curve working with them every time as each theme has different patterns. But once the logic is cracked it’s straight forward.
What i would love to see in color schemes, is a Style 2 option or Inverse option so that when we define color schemes we can define the inverse variant of it as well. Then when nwe choose them we can choose which version to use.
In essence nesting multiple colour schemes in a group. This limitation atm, forces us to create many colour schemes in Shopify and hence we cannot change their names, it becomes super confusing sometimes
Hey folks - thanks for flagging! I agree that usually, for more flexible colour management with custom naming and organization etc, metaobjects are typically what we’d recommend since they give you basically complete control over the structure and labels, but that said, I can see how native color schemes would give you a standardized integration with apps. Might be useful for sure in terms of connecting different services.
Could you share a bit more about your specific use case, just curious about why metaobjects might not work for you specifically? Is it just the limitation causes a bit of difficulty when managing all of the schemes you create and nesting would make more easier with a hierarchy, etc? Happy to put through a feature request, but just wanted to reach out to see if I can pass along any details as well (helps us advocate better for new features). Hope to hear from you soon!
Metaobjects rely on being setup on a store level, native colour schemes are part of a themes code.
Ah, gotcha, thanks for clarifying @Luke - yeah, they’re I can see how they’re not really viable for distributable themes. Just want to make sure I’m understanding correctly: you’re basically looking for theme-portable, merchant-agnostic flexibility with better naming/organization?
Hi @Alan_G thanks for taking the time to reply. Metaobjects for color schemes are great but the way i see it, at the moment it only ads an extra layer of complexity. The only advantage i can see, is separation of concerns where color don;t have to be defined again after a theme switch. Which can work in some cases but since color scheme inputs are not standardised, each theme can have inputs for different things. For example some themes might have border color option on the scheme while other not.
Anyway, back to the topic. The real driver for this post/request is managing color schemes in themes more efficiently. Atm, the schemes have fixed names scheme-1 scheme-2 etc.
When having more than 4-5 schemes, it gets very confusing and messy. And i do get it, these schemes are baked in the theme and their name/id is used nomally in liquid and css so we can’t simply change their name.
But what we can do, and I believe would be a quick win, is to have an alias. Pretty much like we can rename sections now, that would be nice for color schemes. For example here i have color schemes that might look similar here but there are slight variations between them. without knowing which is which, it’s always a game of guess.
Was literally talking today about how painful it is to have to create multiple schemes and there not being some sort of alias for them. This would be fantastic and would make way more sense for merchants when trying to pick between all the different options available to them.
This is often necessary, to create so many schemes, because you might need to escape a single color in an instance or two for a button or something along these lines for a merchant. Not all themes sections, blocks and/or theme blocks will have the option to be able to go in and override a specific color on a secondary action button or something for instance - and merchants don’t have the ability to add this into their theme necessarily and so more often than not they’ll have to reach for creating a new scheme (and this process continues…).
I imagine when this started, the idea was only a couple schemes would be created, good design means using few predictable patterns yeah? But theme devs also (for theme store themes) aren’t supposed to create too many settings so there aren’t always override/escape options within a section, block, or theme block - and this means the merchants have to rely on creating more and more schemes.
This gets so confusing so fast and an alias or ability to rename these just in the customizer UI would be hugely helpful for sure. Color schemes are also cumbersome to set up so sometimes multiple of the same color schemes get set up even because merchant just assumes they need to create another one and “scheme x” isn’t relatable enough for most.
I sometimes add a textarea to help me manage this. It’s not ideal, proper customizable lablels would be better.
Hey folks - really appreciate all the feedback here and I totally agree this would be a valuable addition.
Can’t make any promises about timelines or guarantees that this will get built, but I’m definitely going to file a proper feature request on this for you all. In the meantime, I know it’s not ideal, but the textarea workaround that @suture mentioned is probably the best option available right now for keeping track of which scheme is which (thanks for sharing this!). Thanks again for taking the time to explain the use cases here, really appreciated.
Hey folks, going to mark this as solved for now since we have recorded this as a feature request, but let me know if I can help out further. 
