#53693 closed defect (bug) (reported-upstream)
Block icons too big on 5.8 widgets page
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | 5.8 |
| Component: | Widgets | Keywords: | |
| Focuses: | ui | Cc: |
Description
Our plugin adds a block using an SVG image which still looks fine on the blocks page. But on the widgets page introduced in WP 5.8, our block's icon is way too big and spills into the surrounding areas.
See 
On the post editing page, where the icon still looks fine, I see this critical CSS:
.block-editor__container img {
max-width: 100%;
height: auto;
}
It seems on the widgets page there is no block-editor__container so the styles don't apply, and icons like ours are unstyled.
Change History (13)
#4
@
5 years ago
- Keywords needs-patch added; reporter-feedback removed
- Milestone changed from Awaiting Review to 5.8.1
#5
@
5 years ago
A quickfix I made was adding the following CSS to our plugin on the widgets page:
.blocks-widgets-container img{
max-width:100%;
height:auto;
}
But we were concerned that might affect other plugins' block icons, so we checked we were registering the icons in the recommended way.
This is how we were registering the icon in our Javascript code:
const iconEl = el('img', {
src: 'data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0 ...,
});
registerBlockType('yarpp/yarpp-block', {
title: __('YARPP Block', 'yarpp'),
description: __('Display related posts by YARPP', 'yarpp'),
category: 'yarpp',
icon: iconEl,
...
});
Using an img element didn't seem very standard, so we've switched it for an svg element like so...
const iconEl = el(
'svg',
{ width: '24px', height: '24px', viewBox: '0 0 145 191' },
el(
'g',
{ stroke: 'none', strokeWidth: '1', fill: 'none', fillRule: 'evenodd' },
el( ...
);
registerBlockType('yarpp/yarpp-block', {
title: __('YARPP Block', 'yarpp'),
escription: __('Display related posts by YARPP', 'yarpp'),
category: 'yarpp',
icon: iconEl,
...
)
which has also fixed the issue.
This ticket was mentioned in Slack in #core-test by boniu91. View the logs.
5 years ago
#7
@
4 years ago
- Milestone changed from 5.8.1 to 5.8.2
WordPress 5.8.1 RC is due out in less than 24 hours. Because no fix has been created for this, I'm going to punt to the next minor release.
#8
@
4 years ago
- Milestone changed from 5.8.2 to Future Release
There's no working fix yet and 5.8.2 RC is due out in less than 24 hours. I'm going to punt this to a future release.
#10
@
7 months ago
- Keywords needs-testing removed
Reproduction Report
Description
This report validates whether the issue can be reproduced.
Environment
- WordPress: 6.9-alpha-60093-src
- PHP: 8.2.28
- Server: nginx/1.27.5
- Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
- Browser: Firefox 140.0
- OS: macOS
- Theme: Twenty Twenty-One 2.6
- MU Plugins: None activated
- Plugins:
- Test Block 1.0.0 [Custom plugin for adding testing block]
- Test Reports 1.2.0
Actual Results
- ✅ The block icon appears unusually big - Issue reproduced
Supplemental Artifacts
Patch in progress for solving this...
#11
@
7 months ago
Hi!
I felt this issue might be better solved on Gutenberg as the components shouldn't be dependent on page's classes for proper icon size
I've created corresponding issue on Gutenberg repository & a subsequent patch that adds restricting rules at component level
Feel free to let me know if I'm missing something...
Thanks!
Issue: https://github.com/WordPress/gutenberg/issues/70762
PR: https://github.com/WordPress/gutenberg/pull/70763
#12
@
7 months ago
- Milestone Future Release deleted
- Resolution set to reported-upstream
- Status changed from new to closed
Block API only supports Dashicons and SVG values for the icon argument. Using base64-encoded images isn't supported. Ref: https://developer.wordpress.org/block-editor/reference-guides/block-api/block-registration/#icon-optional
Also replied on the Gutenberg issue: https://github.com/WordPress/gutenberg/issues/70762#issuecomment-3084174671.

Wondering if this is because of [51388] and the editor package not being loaded on the widget screen.
@mnelson4 Could you test this within the Customizer as well? Curious if there are differences in the behavior.