wordpress 7.1 broke site icon

[donniam]

I updated wp 7.1 and it blew my site icon up. Please find a fix. i would do a roll back but having problems with my back up co. logging in

[desrosj]

Ticket retargeted after milestone closed

[desrosj]

Hi @donniam!

Apologies, but this is not enough information to investigate this issue. Are you able to share any messages in the site's error log?

[jorbin]

In addition to checking your error logs, are you able to share what your site icon was set to before, how you had set it, and what happened after you upgraded

[donniam]

Hi thanks for replying. how do i find the error logs. i have been having severe cognative issues for a couple of years and have a hard time remembering things. I only updated a few sites and was able to remove the site icon. it has happened on divi and gem theme. those are the only ones i updated. no i cannot figure it out on the backend. i wanted to send a phtot screenshot but i do not see an area. I can't imagine i am the only one. I am not going to update anymore sites. i want to add image and it does not allow me to. )]])]])]]

[donniam]

my site icons have always been uploaded through the appeaance identity area and have always been fine until 7.1. i will drop my backup company after this because the one time i needed them they would not let me login. going with muy hosting company. i can ask them tomorrow. hopefully you will have other complaints and have a update for this. they were all fine before update. i removed the site icons

[kgagne]

Site icon in admin toolbar 7.1

[kgagne]

This happened on my Pressable site; a screenshot is attached above.

It might be a caching issue, but in the meantime, I fixed it with this CSS in the theme customizer:

#wpadminbar .site-icon {
    width: 20px !important;
    height: 20px !important;
    max-width: 20px !important;
    max-height: 20px !important;
}

[khokansardar]

Diagnosis

The oversized icon appears when a site is served a pre-7.1 copy of admin-bar.css alongside 7.1's markup — an asset-cache skew. Core makes that skew catastrophic rather than cosmetic, for two reasons.

1. The width/height attributes on the new image cannot constrain its rendered size.

[62625] renders:

<img class="site-icon" src="..." alt="" width="20" height="20" />

Those attributes are presentational hints. They still supply the intrinsic aspect ratio, but they cannot set the rendered size, because admin-bar.css has long overridden both properties for every admin bar descendant:

#wpadminbar * {
      height: auto;
      width: auto;
      ...
}

So the image is sized only by the rule [62625] added. If that single rule doesn't reach the browser, there is no fallback and the image renders at its intrinsic size.

Verified on trunk (Twenty Twenty-One, front end): deleting just the .site-icon rules from the loaded stylesheet via CSSOM changes the render from 20x20 to 150x150 — overflowing 118px below the 32px bar — and brings the \f226 dashicon back. The screenshot in this ticket shows both the dashicon and the oversized icon, which is only possible when the .has-site-icon rules are not applied.

2. get_site_icon_url( 32 ) does not necessarily return a 32px file.

When the site_icon-32 crop is missing, it falls back to the smallest available intermediate, or to the full-size file. In testing that returned a 150x150 thumbnail in one case and the original upload in another. The ~280px icon in the screenshot is consistent with site_icon-270.

Suggested next step for reporters

@donniam, @kgagne — in the page source, could you check the ver query argument on the admin-bar.css/admin-bar.min.css link? If it reads lower than 7.1, the stylesheet is being served from cache and a cache purge should resolve the display. That would also confirm the mechanism above.

[kgagne]

I had the plugin ​WP Remove Query Strings From Static Resources activated, which meant there was no ver query argument. However, I can confirm that the 7.1 version of the stylesheet is now loading (with or without the plugin), and the custom CSS I previously provided is no longer needed.

[khokansardar]

Replying to kgagne:

I had the plugin ​WP Remove Query Strings From Static Resources activated, which meant there was no ver query argument. However, I can confirm that the 7.1 version of the stylesheet is now loading (with or without the plugin), and the custom CSS I previously provided is no longer needed.

Thanks @kgagne — that confirms it. Removing the ver query argument defeats core's cache busting, so the browser kept serving the pre-7.1 admin-bar.css against 7.1's markup, which is the skew described in comment:8. The released 7.1 stylesheets (both LTR and RTL) do contain the .site-icon rules, so there is nothing broken in core here.

@desrosj — I'd suggest closing this as worksforme, unless @donniam is able to reproduce it with a current copy of admin-bar.css loading.

[donniam]

Replying to kgagne: that css worked. I am sure this may need adjustment later but thank you.

This happened on my Pressable site; a screenshot is attached above.

It might be a caching issue, but in the meantime, I fixed it with this CSS in the theme customizer:

#wpadminbar .site-icon {
    width: 20px !important;
    height: 20px !important;
    max-width: 20px !important;
    max-height: 20px !important;
}

[donniam]

Replying to khokansardar:Thanks for the detailed message. This may be a bit deep for me. I am not sure how to do this. I am using suggested css for now that kgagne suggested. I have to look at this when i have more time. I have been dealing with a cognative issue for quite some time and focus is hard.

Diagnosis

The oversized icon appears when a site is served a pre-7.1 copy of admin-bar.css alongside 7.1's markup — an asset-cache skew. Core makes that skew catastrophic rather than cosmetic, for two reasons.

1. The width/height attributes on the new image cannot constrain its rendered size.

[62625] renders:

<img class="site-icon" src="..." alt="" width="20" height="20" />

Those attributes are presentational hints. They still supply the intrinsic aspect ratio, but they cannot set the rendered size, because admin-bar.css has long overridden both properties for every admin bar descendant:

#wpadminbar * {
      height: auto;
      width: auto;
      ...
}

So the image is sized only by the rule [62625] added. If that single rule doesn't reach the browser, there is no fallback and the image renders at its intrinsic size.

Verified on trunk (Twenty Twenty-One, front end): deleting just the .site-icon rules from the loaded stylesheet via CSSOM changes the render from 20x20 to 150x150 — overflowing 118px below the 32px bar — and brings the \f226 dashicon back. The screenshot in this ticket shows both the dashicon and the oversized icon, which is only possible when the .has-site-icon rules are not applied.

2. get_site_icon_url( 32 ) does not necessarily return a 32px file.

When the site_icon-32 crop is missing, it falls back to the smallest available intermediate, or to the full-size file. In testing that returned a 150x150 thumbnail in one case and the original upload in another. The ~280px icon in the screenshot is consistent with site_icon-270.

Suggested next step for reporters

@donniam, @kgagne — in the page source, could you check the ver query argument on the admin-bar.css/admin-bar.min.css link? If it reads lower than 7.1, the stylesheet is being served from cache and a cache purge should resolve the display. That would also confirm the mechanism above.

[wildworks]

The symptoms reported here appear to be similar to those reported in #65944.

[doblerre]

Hello.
I have the same problem: ​https://wordpress.org/support/topic/site-icon-error/
Victor

[dyin]

just wanted to say two things after testing it:
1) on mobile when signed it on the admin account the site logo isn't even contained in the box where it should be. It is floating to the rights and partly invisible
2) my logo has a white background in the admin dash. This is rather ugly as the admin bar is black. So I would guess the background should be transparant.

[jorbin]

#65944 was marked as a duplicate.

[jorbin]

For people that are seeing a larger than expected icon, can you please check:

1) When the admin bar is loaded on the front end, ​https://<your-site>/wp-includes/css/admin-bar.min.css?ver=7.1 is also loaded?
2) In that file, there is a #wpadminbar #wp-admin-bar-site-name>.ab-item .site-icon rule that includes a width and height instruction?
3) If you use the inspector, do you see any rules applying on the img.site-icon file from other sources such as those from a theme or plugin?

Additionally, do you see this issue with all of your plugins disabled and using a default theme?

[minosh]

Clearing both the WordPress cache and my browser cache solved this for me. After clearing both, the issue disappeared completely.

[webverts]

Replying to jorbin:

For people that are seeing a larger than expected icon, can you please check:

1) When the admin bar is loaded on the front end, ​https://<your-site>/wp-includes/css/admin-bar.min.css?ver=7.1 is also loaded?

Yes Loaded. Only 7.1 is loaded

2) In that file, there is a #wpadminbar #wp-admin-bar-site-name>.ab-item .site-icon rule that includes a width and height instruction?

Yes, 28x28

#wpadminbar #wp-admin-bar-site-name > .ab-item .site-icon {
		position: absolute;
		top: 9px;
		left: 12px;
		width: 28px;
		height: 28px;
		margin: 0;
		border-radius: 4px;
	}

3) If you use the inspector, do you see any rules applying on the img.site-icon file from other sources such as those from a theme or plugin?

The image now loads a 32px and 64px cropped image file

<a class="ab-item" role="menuitem" aria-expanded="false" href="https://domain.com/"><img class="site-icon" src="https://domain.com/wp-content/uploads/cropped-domain-32x32.png" srcset="https://domain.com/wp-content/uploads/cropped-domain-64x64.png 2x" alt="" width="20" height="20" style="
">domain</a>

I tried updating the logo from General Setting. Just selected the icon(512X512), but never saved it in the setting page. Now half of the setting page is now covered with the site logo from the admin bar. Image attached.

<a class="ab-item" role="menuitem" aria-expanded="false" href="https://domain.com/"><img class="site-icon" src="https://domain.com/wp-content/uploads/cropped-domain.png" alt="" width="20" height="20">domain</a>

[adrianduffell]

A possible cause could be a plugin/theme having img rules with greater specificity in CSS. A PR is being explored here ​https://github.com/WordPress/wordpress-develop/pull/13243

[dyin]

@adrianduffell this could be possible and added by a pugin like imagify

## Ticket

Trac ticket: https://core.trac.wordpress.org/ticket/65912

## Description

The site icon in admin-bar.css is sized only via width/height, so a theme/plugin img rule using !important overrides it and the icon renders at intrinsic size instead of 20x20 (28x28 on mobile).

Adds max-width/max-height alongside the existing rules so the size holds even when width/height are overridden.

## Testing

Set a Site Icon, then add img { width: auto !important; height: auto !important; } via Additional CSS — the icon should stay 20x20 with this fix (blows up without it).

## Screenshots

Before	After

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Sonnet 5
Used for: reproducing the bug locally.

Please note the RC for 7.1.1 is September 10th if we want it included in that version. Otherwise it is fine to punt to 7.1.2.

I think that adding img.site-icon is helpful additional specificity, and the icon can only be an img element at this time, but adding !important creates a cascade effect where we need to add it everywhere. It would also make it harder for an extender to intentionally override the styles. I think that it's best to avoid adding !important unless it's absolutely necessary; it's only used in a handful of cases in core, and the majority of them are screen reader text classes, where the specific behavior is critical.

The specificity after adding img is 2, 2, 1, which is already a very high specificity.

I don't feel like adding min-height is super important, but also not harmful in that edge case.

While it is possible that this CSS won't capture every single case, I feel that the cases it *doesn't* catch are beyond what it makes sense for us to guard against.

Thanks for updating the branch.

However, I do not agree with the additional changes proposed above. People still should be able to override these dimensions intentionally.

• The ​CSS Coding Standards article encourages to "refrain from using over-qualified selectors."
  • #wpadminbar #wp-admin-bar-site-name > .ab-item .site-icon already has a high specificity of 2-2-0, and it is scoped to the Site Title link.
  • Increasing the selector specificity also affects anyone overriding properties related to position and border-radius.
• WordPress admin styles avoid !important (see Trac 47569 and Trac 26350).
• If some CSS enforces a width or height smaller than 28 pixels, for _any_ image, I would expect that to cause bigger problems in other places.

The difference between 2,2,1 and 2,2,0 is pretty nominal to me; either are about equally difficult to override, should a user wish to. So as far as that change goes, I'm fine either way.

[adamsilverstein]

7.1.1 RC is in a couple of hours - punting this to 7.1.2 for continued work.

[whyisjake]

In 64034:

Toolbar: Constrain the site icon's size.

The toolbar site icon added in 7.1 is sized only by width and height. A theme or plugin rule such as img { width: auto !important; height: auto !important; } overrides those, and the icon renders at the size of the image file. Add matching max-width, max-height, min-width, and min-height, and qualify the selector with img for added specificity, so the icon stays 20 pixels square, or 28 pixels on small screens.

Follow-up to r62625.

Props donniam, kgagne, khokansardar, jorbin, webverts, adrianduffell, iamchitti, joedolson, sabernhardt, adamsilverstein.
Fixes #65912.

[whyisjake]

In 64035:

Toolbar: Constrain the site icon's size.

The toolbar site icon added in 7.1 is sized only by width and height. A theme or plugin rule such as img { width: auto !important; height: auto !important; } overrides those, and the icon renders at the size of the image file. Add matching max-width, max-height, min-width, and min-height, and qualify the selector with img for added specificity, so the icon stays 20 pixels square, or 28 pixels on small screens.

Follow-up to r62625.

Reviewed by <second-committer>.
Merges r64034 to the 7.1 branch.

Props donniam, kgagne, khokansardar, jorbin, webverts, adrianduffell, iamchitti, joedolson, sabernhardt, adamsilverstein.
Fixes #65912.

[joedolson]

@whyisjake Can you add a comment to fill in the missing second committer review?

[whyisjake]

I can't seem to update that comment, so for the record, I was the second reviewer.

[jorbin]

Replying to whyisjake:

I can't seem to update that comment, so for the record, I was the second reviewer.

Then who was the first reviewer since you were the committer?

[afercia]

Just a note that [64034] introduces a few over-qualified CSS selectors like img.site-icon. Those are ​against the WordPress CSS Coding Standards and will be marked as violations once ​https://github.com/WordPress/wordpress-develop/pull/12934 lands in Core.
Not a problem because that PR will need to be rebased on top of latest trunk before it gets merged and the Stylelint suppressions list will need to be updated (so that it will mark the baseline at that moment).
Just wanted to note that we should avoid introducing new violations.