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 the button-primary class 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 #weight attribute). But this works as expected only when the form submit buttons are "static". Soon as you start using #states to 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-primary CSS class to the submit button by using the #attributes attribute in Form API. This would result in the button having both button-primary and button-secondary CSS classes though. The button-secondary class 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_type attribute would still be set via php (before rendering the submit buttons), while #states works 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.

GitHub Issue #: 
3441