[wp-trac] [WordPress Trac] #53822: Inconsistent handling of block equivalents of legacy widgets

[WordPress Trac]

#53822: Inconsistent handling of block equivalents of legacy widgets
--------------------------+-----------------------------
 Reporter:  Frank Klein   |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Widgets       |    Version:  5.8
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 Assuming a site with a theme that supports block-based widget areas.

 When using a widget block that maps to a legacy widget, WordPress will add
 additional classes on the frontend. This is handled through
 `WP_Widget_Block::get_dynamic_classname()`.

 As an example when using the Latest Posts widget, this is the markup on
 the frontend:
 {{{
 <div class="widget widget_block widget_recent_entries">
   <div class="widget-content">
     <ul class="wp-block-latest-posts__list wp-block-latest-posts">
       [...]
     </ul>
   </div>
 </div>
 }}}

 The important part here is the `widget_recent_entries`.

 However the same does not apply to the admin preview. Therefore the
 preview in the admin and on the frontend will always be different.

 Two things need to happen here:
 1. WordPress should be consistent about adding the backwards compatibility
 classes. This means that both the frontend and the backend preview need
 them.
 2. There should be a filter to disable this backwards compatibility layer.
 Because not every theme developer will want this.


 hen a theme uses block-based widget areas, then

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