Opened 4 years ago
Last modified 4 years ago
#53822 new defect (bug)
Inconsistent handling of block equivalents of legacy widgets
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Awaiting Review | Priority: | normal |
| Severity: | normal | Version: | 5.8 |
| Component: | Widgets | Keywords: | |
| Focuses: | Cc: |
Description
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:
- WordPress should be consistent about adding the backwards compatibility classes. This means that both the frontend and the backend preview need them.
- 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