Form actions

The row every form ends with, in the five shapes it comes in. First the one core puts at the foot of an entity form: a primary button, a second submit, and a delete link wearing the classes of a button, so the row already has an anchor and two inputs to line up with each other. Then one of everything that turns up in such a row -- primary, danger, small, disabled, a button that runs no submit handler, a submit styled as a link, a link styled as a button, an image button and a plain link -- which is also the test of what happens when the row wraps. Then the dropbutton several buttons are folded into when they are given a #dropbutton, whose list items hold submit inputs rather than the anchors a dropbutton of operations holds. Then the actions of a confirmation form, the one page where the primary button is the destructive one and the way out is a link. Last, an actions element that is not at the end of anything, on a line with the field it filters. Nothing is saved: each button that submits says which one was pressed, and the one that runs nothing says nothing.

The row a form ends with

What core puts at the foot of an entity form: the action being encouraged as the primary button, a second submit beside it, and a delete link at the end wearing the classes of a button. Three controls, two elements and one of them an anchor -- so the row is already asking a theme to make an inline element and two replaced ones sit on a shared baseline, at a shared height, with a shared idea of what their padding is. The element is a container, not a list, so nothing about the gap between the controls comes for free.

Everything that turns up in that row

The same element with one of each in it, which is also the width test: an actions row is a wrapping row, and the line it wraps onto has to keep the spacing of the first. Two of these are worth pressing. The plain button runs no submit handler at all, so the page comes back without a message and with the form rebuilt -- it is #type button rather than #type submit, and the markup is identical, which is the point. The disabled one cannot be pressed, and is the only control here a theme has to style for a state rather than for a role.

Link styled as a button An ordinary link

Several buttons folded into one

Give a button a #dropbutton and the actions element collects every button that names the same one into a dropbutton: the first is the button, the rest are the list behind the toggle. It is how a form offers one obvious action and a handful of variants of it without a row of five buttons. The markup is not what a dropbutton looks like elsewhere on a site, because core renders each button to markup first and then hands it to a list of links -- so these list items hold submit inputs where a dropbutton of operations holds anchors, and a theme that styled the anchors has styled half of it. A button without the property stays where it is, beside the dropbutton rather than in it.

The actions of a confirmation form

Are you sure you want to delete the page An example page to theme content edit forms? This action cannot be undone.

Cancel

Actions that are not at the end

The other place the element turns up: on a line with the field it acts on, the way a filter above a listing is built. Two things about it are easy to miss. The element carries a weight of 100, so it sinks to the end of whatever it is put in and a form wanting its buttons at the top has to say so; and the space it takes at the foot of a form is wrong on a line, so the container of an inline row is expected to take it back. The row also has to keep the buttons on the baseline of a field that is taller than they are.