Add a way to force top toolbar

[swissspidy]

Is your feature request related to a problem? Please describe.

In one of our projects we heavily change the writing flow in Gutenberg. Blocks can be dragged around, rotated, resized, etc.

With such a UI, the block toolbar creates unnecessary noise and activating the top toolbar (aka fixed toolbar) makes more sense for us.

However, there's no way to programmatically force the top toolbar to be active.

Describe the solution you'd like

Similar to #14647, there could be an option/filter to force the top toolbar to always be active. If that is used, there would be no option for the user to switch between fixed toolbar and regular toolbar in the options menu.

Describe alternatives you've considered

An alternative would be to hide the toolbar options via CSS and change the toolbar mode upon script loading using dispatch( 'core/edit-post' ).toggleFeature( 'fixedToolbar' ).

However, this does not prevent some other scripts from also running dispatch( 'core/edit-post' ).toggleFeature( 'fixedToolbar' ), so we'd have to monitor any changes, which is not ideal.

[oalexdoda]

+1

[ninetyninew]

This would be very useful - we've had occasions where forcing some styles mean the inline block toolbar is off screen in some scenarios unless you hide the right settings panel. This option would work solve this. +1

[ninetyninew]

Any updates on this? It's made more difficult currently by having to hide the option with CSS and as there are no unique identifiers on the toolbar, spotlight and full screen options and so you need to do the hiding based off the first option, which might not always be top toolbar in future. If anyone is look for the JavaScript part of this see: https://stackoverflow.com/a/63157946/1951359

[ninetyninew]

Does anyone know where the data is stored if a user has selected an option like top toolbar, spotlight or fullscreen mode, I can't find this in sessions, user meta, cookies, etc yet on refresh WordPress remembers the previously set setting? @swissspidy @altechzilla

[oalexdoda]

Sorry @ninetyninew , it's been a while since I used Gutenberg/WP.

[ninetyninew]

@altechzilla It's okay I found it, if anyone else is looking for this all the Gutenberg option data is set in WP_DATA_USER[user id] in local storage.

[CelestinaDragoni]

Here is a way I ended up doing this. To note, I don't like it. It's hacky, but until they come up with a way to force top toolbar this is the best solution I've got. The solution comprises of two steps:

• On domReady enforce top toolbar by checking the preferences first and then toggling if fixedToolbar is set to false.
• The second step is a CSS selector that is fairly specific, but could be fragile with future updates. This will prevent the user from being able to toggle back and forth the fixedToolbar toolbar state from the options menu.
  • Note: Mind you this can still be done via the console, but step 1 prevents this from being persistent on the user end. As I can find no other way to toggle toolbar state on the UI end or through a keyboard accelerator/shortcut, it should suffice for most usages.

Modern Javascript (Webpack/Babel)

import domReady from '@wordpress/dom-ready';
import { select, dispatch } from '@wordpress/data';

function forceFixedToolbar() {
  const preferences = select('core/edit-post').getPreferences();
  if (!preferences.features.fixedToolbar) {
    dispatch('core/edit-post').toggleFeature('fixedToolbar');
  }
}

domReady(() => {
    forceFixedToolbar();
});

Regular Javascript

function forceFixedToolbar() {
  var preferences = wp.data.select('core/edit-post').getPreferences();
  if (!preferences.features.fixedToolbar) {
    wp.data.dispatch('core/edit-post').toggleFeature('fixedToolbar');
  }
}

wp.domReady(() => {
    forceFixedToolbar();
});

CSS (Use admin_enqueue_scripts to add a CSS override file, I won't write a tutorial on this, google it)

/** Removes The Option To Toggle Top Toolbar **/
.components-dropdown-menu__menu[aria-label="More tools & options"] > .components-menu-group:first-child > div:nth-child(2) > button:first-child {
  display:none;
}

If this solution is incomplete let me know, but it is working for my use case.

[ninetyninew]

@KernelZechs Yes, this is pretty much what I was getting at and i've done similar myself - it's really hacky without identifiers to hide the option. A good old fashioned filter would be good for this :D

[andrea-calligaris]

I was about to open a bug report about this, because to me this is a bug / missing obvious feature.
The editor memorizes if you're using the code view or the block view, so it should also memorize the fixed toolbar.
This would be especially useful since the non-fixed toolbar behavior is currently far from ideal, it very frequently hides what you're working on.