[wp-trac] [WordPress Trac] #64841: wp_editor() with quicktags enabled does not force-print buttons.css on the frontend, unlike editor.css

[WordPress Trac]

#64841: wp_editor() with quicktags enabled does not force-print buttons.css on the
frontend, unlike editor.css
--------------------------+-----------------------------
 Reporter:  vnoben        |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Editor        |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 == 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64841>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform