phbernard

Hi,

Oh, ok. I didn’t realize the redirections were gone in your initial copy of htaccess.

TL; DR

There is nothing wrong here. You can safely ignore this issue. DON’T edit the htaccess file, this is error prone.

In details

The plugin adds redirections to htaccess in order to satisfy two conventions:

• /favicon.ico

This is what most browsers look for when no favicon is declared in the HTML.

• /apple-touch-icon.png

(and friends) iOS Safari is looking for this when none is declared.

However, the plugin makes sure your icons are declared in your site pages. Therefore, these conventions are enforced only to make your favicon bulletproof, and also to save you from annoying (and harmless) 404 errors in your logs. But they still work: your visitors will see your favicon, whatever the browser or device. You might imagine some super-remote scenario, such as a visitor using an old version of Internet Explorer, stuff like this… Even in that case, the favicon should still work.

Plus, some settings prevent htaccess from being updated. It depends of the hosting provider, etc. So the plugin is designed to handle this scenario gracefully. What you get here is not considered as an error by the plugin, only a fallback which occurs very often.

Why this fails after a WP update is a mystery, but this issue is definitely too minor to be seriously investigated.

I hope this clears your doubts.

Regards,
Philippe

Hi Starsis,

First, I want to apologize for this very late reaction. Not only you reported the issue, but you also investigated it, proposed a full solution and replied to other users. You clearly deserved more feedback from me.

I just wanted to perform a routine “version bump” today on the plugin regarding WP 5.6. Discovered an issue that was easy to fix. Released it. Now I investigate the issue you reported and this is definitely less straightforward 🙂

I review the solution you proposed. Thank you for it!! Although I didn’t tested it, it looks good and should do the trick. However, something bothers me: for non-32-or-512 size, it performs some disk I/O. This is not a big deal: after all, get_site_icon_url itself calls get_option and wp_get_attachment_image_url. Yet, a promise the plugin has to keep is to be super-lightweight. Nobody wants to waste unnecessary milliseconds for just a favicon. Given the variety of WordPress hosting environments, I’m not sure disk I/O can be guaranteed to be 100% effective.

My first thought was to only keep the 32 and 512 cases of your solution, ignoring other cases. Then I looked to the WordPress source code to find out which sizes where actually requested. The list, for reference:

– embed.php / the_embed_site_title: 32 and 64, PNG format (the icon is for HTML content, not favicon).
– feed.php / atom_site_icon: 32, PNG format
– functions.php / do_favicon: 32, should probably be ICO format but actually returns PNG. When accessing /favicon.ico, the client is redirected to a PNG image. All clients (browsers, search engines…) can deal with that I suppose.
– general-template.php / has_site_icon: 512
– general-template.php / wp_site_icon: 32, 192, 180 and 270, PNG format.

When the plugin is active, the site icon should be disabled:

– Either has_site_icon is supposed to return false, so wp_site_icon does not return anything.
– Or the wp_site_icon action in wp_head is disabled in default-filter.php.

The second choice sounds good to me, whereas the first one is fragile: internally has_site_icon relies on the presence of a 512 icon, an implementation that might change without notice.

the_embed_site_title must be taken into account. It is using the 32 and 64 icons as different resolutions in a single img. The returned icons must be similar, or the user might observe really strange things, like a WordPress icon when he is using a high resolution screen, and the favicon on low resolution screen. Definitely something to address. But RFG does not generate a 64×64 icon, and the plugin should not rely on it. Hum… that’s not simple…

A solution could be for the plugin to somehow implement a “shadow site icon”: in addition to calling RealFavicon to create the favicon, it also takes the master image, computes a site icon using WP code, and stores it. Then, when the get_site_icon_url hook is triggered, it returns one of those “shadow icons”.

It’s a bit late, and this is what I have in mind at the moment. I would be glad to get your thoughts on this!

Regards,
Philippe

Hi,

Thank you for reporting this issue.

It was fixed a few minutes ago.

Regards,
Philippe

Hi Toby,

Thank you for reporting this issue.

It’s under investigation.

Regards,
Philippe

Thank you!!

Thank you!!

Perfect review 😉

I love you too! ;-D