CMS 6 REGRESSION: Button toolbar wrapping - "Batch actions" button drops to second line

[purplespider]

Module version(s) affected

6.0.0 including 6.1.0-rc1

Description

The toolbar above the page sitetree is wrapping onto two lines because the "Add new" button now says "Add new page", making it wider than before. This pushes the "Batch actions" button onto a second line.

Silverstripe 5 (correct layout)

Silverstripe 6 (buttons wrapping)

Reproduced in both Chrome and Safari.

What Changed

Commit 5336a999 updated the button text to include the record type name, changing "Add new" → "Add new page".

File: templates/SilverStripe/CMS/Controllers/Includes/CMSMain_ContentToolActions.ss:5

<%t SilverStripe\Admin\\LeftAndMain.AddNew 'Add new {name}' name=$getRecord('singleton').i18n_singular_name().lowercase %>

Possible Solutions

Option 1: Would changing it back to use AddNewButton instead of AddNew to restore the shorter "Add new" button label be an acceptable fix? I'm not sure if adding "page" here was explicitly intended.

<%t SilverStripe\Admin\\LeftAndMain.AddNewButton 'Add new' %>

Option 2: Alternatively, does the "Batch actions" button really need it's text label? Could the text be removed from this button so that it is just the icon, like the site tree view button? e.g.:

Happy to provide a PR for the agreed upon solution.

Validations

• Check that there isn't already an issue that reports the same bug
• Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)

[GuySartorelli]

Would changing it back to use AddNewButton instead of AddNew to restore the shorter "Add new" button label be an acceptable fix? I'm not sure if adding "page" here was explicitly intended.

Adding "page" was intended - CMSMain is now configurable and doesn't necessarily have to hold pages. Right now that's effectively useless but it's paving the way for reusing this logic for other hierarchical structures such as taxonomies. We won't revert the button back to "Add new".

Alternatively, does the "Batch actions" button really need it's text label? Could the text be removed from this button so that it is just the icon, like the site tree view button?

I think it probably does - I wouldn't know what it does without the text. Batch actions are probably relatively infrequently used which makes it harder to remember the function of the button without the text being displayed.

[purplespider]

Ok, so sounds like the cms-content-tools just needs to handle wrapping better, which it should have really done previously to accommodate different-length button labels in other languages.

For the time being, I suggest changing the button spacing from margin to gap, which at least keeps in alignment, and looks less broken:

But I do feel a larger revamp of the layout of these buttons is needed in the long-term to better accommodate different labels.

---

Could we also remove the "new", so the button becomes "Add page"? This would keep it consistent with other similar buttons in the CMS, like "Add block", "Add member" etc, and reduce the chance of the buttons wrapping in the first place:

(Although we would still need to find another 8px to stop the view icon wrapping (in English).)

---

For my own projects, I'm going to tighten up the cms-content-toolbar padding a little, to make everything fit nicely (like in SS5):

---

Let me know if any of the above would be acceptable in core, and I'll be happy to create a PR.

[GuySartorelli]

Could we also remove the "new", so the button becomes "Add page"? This would keep it consistent with other similar buttons in the CMS, like "Add block", "Add member" etc

One of the changes being made in CMS 6.2 is to add "new" to other buttons in the CMS (see silverstripe/silverstripe-framework#9980) so removing it here isn't something we'd want to do.

Let me know if any of the above would be acceptable in core, and I'll be happy to create a PR.

Either of the two CSS changes sounds like it would be suitable at a glance. Feel free to open a PR for either of those.

[lerni]

<%t SilverStripe\Admin\\LeftAndMain.AddNew 'Add new {name}' name=$getRecord('singleton').i18n_singular_name().lowercase %>

Besides the spacing issues, .lowercase is incorrect for German (and Luxembourgish), which capitalizes all nouns. It's not just about word order - "Seite" must remain capitalized as a noun.

[GuySartorelli]

That's a separate issue, can you please raise that separately? That I have no qualms about fixing quickly - assuming the lower case is coming from CSS or PHP and not in the localisation itself.

[lerni]

Sorry for hitchhiking the issue. Created separate one for the .lowercase capitalization problem: #3132

[purplespider]

Revisiting this. CSS tweaks alone won't really resolve it. I now strongly feel that the list view button is the weakest candidate to remain in this toolbar for a few reasons:

1. It's the only button here that exits editing view: "Batch actions" stays in editing view, and "Add new Page" returns to the editing view after creating the new page, so clicking this unlabelled button and suddenly disappearing out of editing mode feels jarring and unexpected. If this button toggled the list view to appear in the narrow mode, it wouldn't be an issue, but this isn't the case.
2. It's rarely used in the editing context: When a user has navigated into a page and is actively editing content, switching between tree and list view is an unlikely action. The sidebar is serving as navigation at that point, not as a view chooser. Anyone who uses List view as their primary view can already access it with a single click of the main Pages tab on the left. So the list view button is largely redundant here.
3. The full-width Pages view remains the natural home for view switching: we can now add a label to the list view button here. Where it behaves, as expected, like a toggle button, unlike how it currently works on the narrower view.
4. When the batch actions button does wrap, e.g. for different locales with longer labels, not needing to find a place for the list view button allows the wrapped layout to remain much neater.

So, can I propose we remove the list view icon from the narrower sidebar, and add a proper label to it on the full-width view?

---

i.e. we go from this:

To this:

---

And then we have a label on the view button when in full width:

Happy for me to proceed with a PR for this?

---

IMHO this is a better solution than:

1. Removing the label from batch actions button - as now all buttons have will labels, an improvement over the current situation.
2. CSS alignment (grid) tweaks to the existing toolbar - it will still take up too much vertical space and just looks cluttered.
3. Removing "new" from the Add page button - as you say, it keeps things consistent.

---

If you're really against removing the list view button from this view for some reason, the other option could be to move it up next to the search button, e.g.:

But this doesn't resolve the issue of this button jarringly existing editing mode without warning.

---

We need to do something about this, as a key pane in the current version of the CMS just looks broken at the moment.

[GuySartorelli]

can I propose we remove the list view icon from the narrower sidebar, and add a proper label to it on the full-width view?

I definitely support adding a label to it when there's enough space to do so.

I would be hesitant to remove functionality based on screen width (or for that matter text width, because don't forget that all of the text is localisable and may be longer in some languages, which could present as the same problem you have with the current layout even if we remove an element).

If you're really against removing the list view button from this view for some reason, the other option could be to move it up next to the search button

We do try to avoid moving elements around in templates, but we are allowed to do that.

I've brought this up with the design team at Silverstripe to see if they have opinions about how to resolve this.

[GuySartorelli]

The design team agree with me that so far none of the solutions proposed will solve the problem for all languages while retaining all the existing functionality, accessibility, and familiarity that currently exists. We kicked around a few other ideas but nothing struck as being an obviously good solution to the problem.

If there is a good solution to this, it probably does lie with CSS - it's just a matter of figuring out what the layout should be when there's not enough room for all elements to fit horizontally (which probably was always a problem at lower widths in some languages anyway)

[purplespider]

Given that the design team hasn’t identified a better alternative, doesn’t this make it the most practical interim solution?

My original point was that the list view icon never really made sense in that position to begin with. It does not actually toggle the list display within that view, so its placement is misleading.

Short of a full rethink of the entire panel, which would sacrifice familiarity anyway, I do not see a credible alternative.

---

For those wanting a workable interim solution, this is what I’m planning to add to my SS6 projects in the absence of a better alternative:

SilverStripe\Admin\LeftAndMain:
  extra_requirements_css:
    - "[...]/cms-fix.css"

.btn-toolbar {
	gap: 5px;
}

.btn-toolbar>.btn:not(:first-child) {
	margin-left: 0;
}

.cms-content-toolbar {
	padding-top: 12px;
}

.cms-content-header,
.cms-content-toolbar {
	padding-left: 15px;
	padding-right: 10px;
}

.cms-content-header .cms-content-header-info .view-controls .btn {
	margin-right: 0px;
}

en_GB:
  SilverStripe\Admin\LeftAndMain:
    AddNew: "Add {name}"

As this removes the wrapping for the English locale:

And at least makes this align nicer in other locales: