I know there's a huge amount of discussion currently about the whole render API and actual output of themes, but I think this is also another topic at hand that should be discussed.
Problem:
Modules or themes that wish to add theme enhancements in the appearance admin area currently have to hook_form_alter the theme_settings_form to inject their Form APIs and tack on submit handlers to save their custom settings. This has been apparent in even the Color module since D6. Granted for themes, you can use the theme-settings.php file, but that seems like a rather half-@**ed way to attempt to incorporate configurable settings in your theme.
Solution:
Create a Theme UI API that allows modules and themes (natively, no weird hook_form_alters and submit handlers) the ability to specify additional settings to be shown for that theme. This would be extremely helpful in implementing: #445990: [META] Refactor color module.
Possible contrib modules/themes that could also benefit from this new API:
@font-your-face
Skinr
Style Guide
CSS3PIE
Nice Menus
Omega
Fusion
AdaptiveTheme
Food for thought:
Sweaver is an interesting module that provides a theme GUI overlay, so to speak, on every page. I really haven't used it at all, but it seems rather quite interesting and a great proof of concept. I would like to see maybe incorporating something like this into core, giving the user the ability to "select" the element they'd like to style and allowing the contrib modules/themes to provide the available configurable options they can choose from (ie: Skinr, @font-your-face, Color, rounded corners). In a way, it would almost be like providing a type of ThemeRoller from jQuery UI.
Comments
Comment #1
markhalliwellComment #2
markhalliwellComment #3
andypostSuppose UI is a wished target, but a real is theme settings API. D8 will have plugins for content and for layout but OTOH it make sense to have a kind of ctools stylizer for core and a settings for styles
Comment #4
johnalbinDrupal's native way of creating form settings is with Form API. In order to add form widgets to an existing form, you use hook_form_alter().
Let me try to interpret this quote:
You want to re-create Form API but only for theme settings. And so that it doesn't use form alters or submit handlers (which are the native way to implement Form API.)
That goal doesn't make any sense to me. Why make people learn a separate API for one form then the API we use for all other forms?
However, if you can come up with a simpler Form API, we should use it for all forms, not just the theme settings forms.
Comment #4.0
johnalbinAdded link for Sweaver module.
Comment #5
lauriiiComment #8
joelpittetunpostponing
Comment #22
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #24
smustgrave commentedIs this still a valid task? With recipes, SDC, do we need a separate UI?
Comment #25
andypostI think it needs LLM to brainstorm as even colors.yaml and palette API went to contrib
Comment #26
nicxvan commentedRecipes and sdcs don't solve this.
But as John Albin said form alters are the war to do it.
The new style api being worked on will help too.
I think this can be closed.
Comment #27
joelpittetYes let’s close this, we don’t have any code to discuss and it’s been a while. If the idea resurfaces again, as a *need* then we can discuss in a modern context.