Control+K does not show in the admin bar when logged in and viewing a page

[nampara17]

When you are logged in and viewing a page you can see the Admin bar.

The option to click the CTRL+K is missing from that bar and in Chrome CTRL+K takes you to the URL bar so cannot use.

1. Add the CTRL+K to the admin bar when viewing a page
2. Make the CTRL+K a customisable shortcut (perhaps)

[micahele]

Thanks for the report. Worth separating the two halves of this, because they have very different costs.

The palette is admin-only by design, not by accident. wp_admin_bar_command_palette_menu() in src/wp-includes/admin-bar.php returns early:

if ( ! is_admin() || ! wp_script_is( 'wp-core-commands', 'enqueued' ) ) {
	return;
}

and the assets are only ever hooked to the admin, in default-filters.php:

add_action( 'admin_enqueue_scripts', 'wp_enqueue_command_palette_assets' );

So nothing is broken — the node is absent on the front end because the script it depends on is never enqueued there.

The cost of changing that is the thing to weigh before this gets milestoned. wp-core-commands depends on wp-core-data, which pulls in wp-block-editor and wp-components. Resolving the full dependency closure from src/wp-includes/assets/script-loader-packages.php against the built js/dist/*.min.js files gives 43 handles totalling roughly 3.1 MB minified — the largest being block-editor (~1374 KB), components (~803 KB), blocks (~143 KB), date (~141 KB), sync (~129 KB) and core-data (~99 KB). That is before react, react-dom and moment, which are not in that count.

Loading ~3 MB of JavaScript on every front-end page view for every logged-in user in exchange for one admin-bar shortcut seems like a hard sell. Realistically this needs the commands bundle decoupled from core-data first, so I'd suggest this stays open as an enhancement pending that rather than being treated as a bug.

The second point is more tractable and separable. That Ctrl+K collides with Chrome's address-bar shortcut applies in wp-admin today, not just on the front end, and making the shortcut configurable would be a change in the @wordpress/commands package. That might be worth its own ticket so it isn't blocked behind the front-end question.

[nampara17]

1. Ok thanks for the reply. Ctrl+K on the front end when viewing the site logged in as Admin is fine but not showing the Ctrl+K as a button is a pain - I understand the logic but would be useful to managing sites.

2. Obviously many people use Chrome browsers in Admin back-end and the conflict with Ctrl+K is a pain! I understand that it is impossible from Chrome to change this shortcode - so it would have to be from the WP side of things....

[joedolson]

@nampara17 Can you open a new issue in the Gutenberg repository about the desire to customize or modify the keyboard shortcut? The conflict with Chrome is fairly significant, and could effect a lot of users, so it's well worth addressing, even though making the command palette available on the front-end is unlikely to happen.

But the shortcut issue has to be addressed in the Gutenberg repository, so it'll need to be reported upstream for that to happen:

​https://github.com/wordpress/gutenberg/issues/