Actually, I checked this again and that assessment of the problem doesn’t seem to be accurate. It seems like any slugs that have some of the same words as another will not work despite not using partial.
It probably has been brought up before, but we can’t change a category color when the category style is none anymore, this notice is rendered instead:
You can’t select colors because you have a category style of none.
Currently, we need to change the style to something else, change the color, and reset the style to none.
On another subject, I assume we still need core changes to be able to replace categories and tag icons in the sidebar to follow what’s set in these theme components, right?
Simply upload the SVG or PNG in the category settings under Category settings > Images > Category Logo Image. No need to mess with a custom sprite sheet!
I second this, it would be extremely nice to have everything configurable from the respective category pages themselves. I think this feature may be the next closest thing, if you’re okay with using the category logo as the category icon.
Additionally, you’re now able to use 2 types of emojis!
Feature 2 — Native system emoji as category icon
Simply use the native emoji keyboard on your iOS, macOS, or other device to input a single Unicode emoji character.
Feature 3 — Discourse emoji as category icon (+ pro tip!)
Use Discourse’s hosted emoji set! Simply type the emoji shorthand such as :grinning: which will render →
Pro tip
If you want to upload a custom category icon without replacing the category logo, this is a great solution. Simply upload the icon as an emoji under Admin > Customize > Emoji. Then, use the emoji’s :shorthand:.
While developing this, I had some questions @pmusaraj —
Can we potentially remove the partial option altogether and replace the category slug with the category id to solve the issue of subcategories sharing the same slug? If I wanted different icons for subcategories that shared the same slug, this would also be a solution. Because ids are more unique they seem like the logical approach and less prone to breakage (unless they delete a category I assume, but does doing that reassign every category id?).
Also, is the svg-icons setting still necessary? (The Font Awesome icons will still render without specifying them there.)
Thanks for the suggestion! I checked it out and that’s actually pretty cool, I think there can be an option where a circular background can be enabled pulling from the category color. Reminds me of Apple’s profile picture options.
It seems like it would be a more streamlined solution to remove the existing color option for Font Awesome icons and just pull its color from the category color setting. As mentioned above there can also be an inverse solution where the Font Awesome icon is white over a circular background that is the category color. This would eliminate unnecessary complexity and allow for a cohesive design.
I believe there are people using the partial option because they want the same icon for subcategories. A switch to category ids would also require all existing users of this theme component to reconfigure it following their next update, and that would be quite disruptive.
This is also tricky. It still is useful if you pick an FA icon that is not included in the default Discourse set (i.e. an icon that isn’t visible in the styleguide of your site). There is a general site setting for that as well, but like with the partial configuration, I suspect there are existing consumers of that setting, so removing it would cause some icons to go missing on some Discourse sites.
To do this, you need to have the “inherit icon from parent category” setting by default.
Thus, the reconfiguration would be easy and would not take much time. Many things can be inherited by default.
Choose your own icon from ready-made ones or upload it manually (maybe even with the conversion to svg from an image on the online) give endless options for using icons to improve the usability of the community.
This update has not yet been merged, it only exists as a separate branch in the repository at the moment. I will submit a PR soon by next week to merge it without breaking any existing configurations. Thank you for your kind feedback!