Topic: GeneratePress Premium 2.5.6 interferes with WordPress Site Icon on frontend

GeorgBNM
July 24, 2026 at 2:11 am

Hello GeneratePress Support Team,

I have found an issue with GP Premium 2.5.6 affecting the WordPress Site Icon.

Environment:

* WordPress: 7.0.2
* GeneratePress theme
* GP Premium: 2.5.6
* GenerateBlocks: 2.3.0
* GenerateBlocks Pro: 2.6.1

Other active plugins:

* Code Snippets Pro 3.9.6
* CompressX 0.9.38
* Nginx Helper 2.3.5
* Redis Object Cache 2.8.0
* WP Cerber Security 9.9
* Yoast SEO 28.0
* Yoast Duplicate Post 4.7
* mosparo Integration 1.18.1

Issue:

With GP Premium 2.5.6, the WordPress Site Icon is no longer displayed correctly on frontend pages in Chrome (Chromium on Debian 13).

The generated frontend HTML contains only:

`html
<link rel=”icon” href=”…/bnm-fav-300×300.png” sizes=”192×192″ />
<link rel=”apple-touch-icon” href=”…/bnm-fav-300×300.png” />
<meta name=”msapplication-TileImage” content=”…/bnm-fav-300×300.png” />
`

However, the favicon behavior is inconsistent:

* Frontend pages: favicon is missing in Chrome
* WordPress backend (/wp-admin/): favicon is displayed correctly, even with GP Premium 2.5.6 enabled
* Firefox displays the favicon correctly on the frontend

Testing:

* GP Premium 2.5.6 enabled → frontend favicon issue occurs
* GP Premium 2.5.6 disabled → frontend favicon works again immediately
* No other plugin changes were made

This indicates that the issue is likely related to the frontend output generated by GeneratePress/GP Premium, possibly affecting the wp_site_icon() output or favicon-related markup in the page <head>.

Could you please investigate whether there was a change in GP Premium 2.5.6 that modifies, filters, or removes the standard WordPress Site Icon output on frontend pages?

I can provide further debug information or a staging environment if required.

Thank you.

Best regards,

Georg
Alvind
July 24, 2026 at 3:10 am

Hi Georg,

Could you share the site URL so we can take a look at the issue?
GeorgBNM
July 24, 2026 at 3:46 am

Hi Alvind,

I’ve shared the URL private.

Best,
Georg
George
July 24, 2026 at 4:43 am

Hi Georg,

Could you please clear all caches and check again?
GeorgBNM
July 24, 2026 at 4:55 am

Hi George,

cleared all caches, but no change.

Best,
Georg
George
July 24, 2026 at 5:09 am

Hi Georg

Can you please try reuploading a png that is at least 512 X 512px size?
GeorgBNM
July 24, 2026 at 5:24 am

Hi George,

I’ve done this several times in production and now also on staging.
No change, sadly.

The Image has exact 512 x 512 px, PNG.

Best,
Georg
George
July 24, 2026 at 5:39 am
Hi Georg,

The cause seems to be a mismatch in the icon markup. WordPress is declaring sizes="32x32" but pointing at a 150×150 file. Firefox scales it down without complaint; Chromium rejects the mismatch and falls back to a blank icon. I confirmed this by removing the mismatched tag in the console, at which point the icon rendered correctly in Chrome.

The 512×512 re-upload doesn’t appear to have taken effect — the page source still references the original files. With Redis Object Cache active, the site icon option may be cached. Could you try:
1. Flush the Redis object cache
2. Customizer → Site Identity → remove the current Site Icon, save
3. Re-upload the 512×512 image, complete the crop step, save
4. Check the page source for <link rel=”icon”> — it should now show a 32×32 file
Let me know what the markup looks like afterwards.
GeorgBNM
July 24, 2026 at 6:02 am

Hi George,

There is no prompt to crop the image. The cropped image is created automatically, but it is also generated at 512 x 512 px.

Dateiname: cropped-bnm-fav.png
Dateityp: image/png
Dateigröße: 90 KB
Maße: 512 × 512 Pixel
Verwendet als: Website-Icon

Deactivating GP Premium does not change this behavior. However, with GP Premium disabled, the Site Icon is displayed correctly as expected.

In the pagesource:

Mastodon<link rel=”icon” href=”https://staging.domain.de/wp-content/uploads/2026/07/cropped-bnm-fav-32×32.png” sizes=”32×32″ />
<link rel=”icon” href=”https://staging.domain.de/wp-content/uploads/2026/07/cropped-bnm-fav-192×192.png” sizes=”192×192″ />
<link rel=”apple-touch-icon” href=”https://staging.domain.de/wp-content/uploads/2026/07/cropped-bnm-fav-180×180.png” />
<meta name=”msapplication-TileImage” content=”https://staging.domain.de/wp-content/uploads/2026/07/cropped-bnm-fav-270×270.png” />
<style id=”wp-custom-css”>

Any idea?

Best,
Georg
Ying
July 24, 2026 at 8:55 am

Weirdly, the site icon HTML appears in the <body> instead of <head> on your site.

Can you disable all other plugins and enable GP Premium to test?
https://app.screencast.com/6RjsU8JgUyfgC
GeorgBNM
July 24, 2026 at 11:19 am

Hi Ying,

I found the cause of the favicon issue.

The problem was caused by an invalid HTML element being injected via Elements into the wp_head:

<a rel="me" href="https://mastodon.social/@domain">Mastodon</a>

This code had been working before without any visible problems. However, an <a> element is not valid inside the HTML <head>. Apparently, after a change in the environment (possibly browser parsing behaviour, WordPress, or another component affecting the generated markup), Chromium started handling the invalid structure differently.

As a result, the DOM structure was repaired in a way that affected the following favicon link elements.

I moved the existing Mastodon verification link unchanged to the beginning of the <body>:

<a rel="me" href="https://mastodon.social/@domain">Mastodon</a>

After this change, Chrome immediately recognized the favicon again.

So your observation that the favicon tags were effectively ending up in the body was correct. The trigger was invalid markup in the head, not WordPress or GeneratePress.

Thanks for the help with narrowing this down.

Best,
Georg
Ying
July 24, 2026 at 11:22 am

Glad you got it sorted 🙂

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.