While working on #3157, I happened to face some challenges. Researching for a possible solution, I came across an API change/addition that was made in D8 that could possibly help, so I have filed #3440 (didn't want to derail #3157).
So here's how I can best explain why I filed this issue here:
The logic in
form_process_actions()is to be adding thebutton-primaryclass to whichever submit button comes first in a form. This is a good thing DX-wise, because the developers/themers need not worry about setting classes; they only need to set the button order (using the#weightattribute). But this works as expected only when the form submit buttons are "static". Soon as you start using#statesto show/hide submit buttons, all sorts of weird things start to happen.I found that the problems/WTFs start happening when you want to conditionally set which button should be the primary one. In the save_draft module, how this was addressed was to add the
button-primaryCSS class to the submit button by using the#attributesattribute in Form API. This would result in the button having bothbutton-primaryandbutton-secondaryCSS classes though. Thebutton-secondaryclass is then removed via javascript. This is just silly, but I see no other workaround .Although an improvement, #3440 would not help with this, because a
#button_typeattribute would still be set via php (before rendering the submit buttons), while#statesworks by adding js that shows/hides or enables/disables elements etc. We currently have the following states available:- enabled
- disabled
- required
- optional
- visible
- invisible
- checked
- unchecked
- expanded
- collapsed
This issue here is to propose the addition of a new set of primary/secondary states, to be used with '#type' => 'submit', which will be adding/removing the respective CSS classes.
Recent comments
Hi Kevin I am interested assisting you developing a theme by cloning feature from existing WordPress website. Please let me know your suitable time to discuss further...
Create a theme from existing website
I've updated the Zulip link in both places I found it. No need to post again, unless you have something new to say. We'll pull together feedback from all the sources.
Backdrop CMS Core Priorities
Should we post here again, what we posted over there? Or would that unnecessarily duplicate things? The link to a Zulip thread in this initial post leads to an internal one, but there's...
Backdrop CMS Core Priorities