wp_editor() with quicktags enabled does not force-print buttons.css on the frontend, unlike editor.css

[vnoben]

Summary

When wp_editor() is used on the frontend with quicktags explicitly enabled, editor.css is correctly force-printed inline (even after wp_head() has fired), but buttons.css — which styles the QuickTags toolbar buttons — is only enqueued and therefore never reaches the page. The result is that QuickTags buttons render completely unstyled on the frontend.

Steps to Reproduce

Call wp_editor() inside a frontend page template with quicktags explicitly set:

wp_editor(
    '',
    'my-editor',
    array(
        'tinymce'   => true,
        'quicktags' => array(
            'buttons' => 'strong,em,link,ul,ol,li,close',
        ),
    )
);

Open the page in a browser and switch to the "Text" or "Code" tab of the editor.

Expected Behaviour

QuickTags buttons are styled, consistent with how they appear in wp-admin. Since quicktags was explicitly passed to wp_editor(), all styles required to render those buttons should be loaded.

Actual Behaviour

QuickTags buttons render without styling. Inspecting the page source shows editor.css is present (force-printed inline), but buttons.css is absent.

Root Cause

In wp-includes/class-wp-editor.php, the editor() method force-prints editor-buttons regardless of when it is called relative to wp_head():

// ~line 212
wp_print_styles( 'editor-buttons' );

However, buttons is only enqueued inside enqueue_scripts():

// ~line 867
if ( $default_scripts || self::$has_quicktags ) {
    wp_enqueue_script( 'quicktags' );
    wp_enqueue_style( 'buttons' ); // has no effect after wp_head() has fired
}

On the frontend, wp_editor() is typically called inside the page template body, after wp_head() has already run. wp_enqueue_style() at that point is a no-op for stylesheet output. The editor-buttons style avoids this problem because it is force-printed via wp_print_styles(). buttons has no equivalent accommodation.

Note: if quicktags is not passed to wp_editor() it would be reasonable that buttons.css is not loaded. The inconsistency is specifically that even when quicktags is explicitly configured by the developer, the required styles are not force-printed the same way editor.css is.

Proposed Fix

In the editor() method, alongside the existing wp_print_styles( 'editor-buttons' ) call, also force-print buttons when QuickTags is enabled:

wp_print_styles( 'editor-buttons' );

if ( ! empty( $set['quicktags'] ) ) {
    wp_print_styles( 'buttons' );
}

Additional Context

This became a visible regression in WordPress 6.7, when QuickTags buttons were migrated from the custom .ed_button class (whose styles live in editor.css) to the standard .button class (whose styles live in buttons.css). Prior to 6.7, editor.css alone was sufficient to style the buttons, which masked this inconsistency entirely. Any site using wp_editor() with QuickTags on the frontend and running WordPress 6.7 or later is affected.

This ticket was created with the help of a Claude code LLM agent after I discovered the broken quicktag buttons and the missing buttons.css styles on the front-end. Above mentioned line numbers, root cause and proposed fix are unchecked/untested by said developer, but seems to make sense. Tested in latest 6.9.3 version.