WordPress default icon under /favicon.ico

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Author phbernard

    (@phbernard)

    4 years, 2 months ago

    Hi,

    I’m sorry for the inconvenience. Against all odds, that might be due to another plugin. Maybe you installed a new one recently?

    Could you give me the URL of your site for review?

    Regards,
    Philippe

    Thread Starter strarsis

    (@strarsis)

    4 years, 2 months ago

    @phbernard: This happened on many sites I maintain, after an update of WordPress core.

    The responsible filter is get_site_icon_url
    (https://github.com/WordPress/WordPress/blob/856e1a27b8dfa9208c36b8b474afcb5acc90322b/wp-includes/general-template.php#L888).

    That filter is used when determining the URL for redirecting from /favicon:
    https://github.com/WordPress/WordPress/blob/38676936bac7963a62e23e0d2ec260a1ae9731ea/wp-includes/functions.php#L1671

    I searched through the code of your plugin but I cannot find any use of that get_site_icon_url filter. On the other hand, that filter had been introduced releases ago, but for some strange reason, this issue became apparent now. Maybe Chrome has a different favicon priority now, so that it is using the /favicon.ico over ones in the HTML markup?

    I could try to set up some minimal example site if you need that.
    Thanks in advance.

    Thread Starter strarsis

    (@strarsis)

    4 years, 2 months ago

    @phbernard:
    So I use a workaround now that parses the favicon.ico URL from the OPTION_HTML_CODE response and uses it for the WordPress core get_site_icon_url filter.
    Requests to /favicon.ico (with size === 32) will now redirect to the favicon file generated by RealFaviconGenerator:

    // Redirect /favicon.ico to generated favicon (for Favicon by RealFaviconGenerator plugin)
add_filter('init', function() {
    if(!class_exists('Favicon_By_RealFaviconGenerator_Common')) return; // skip

    add_filter( 'get_site_icon_url', function($url, $size) {
        if($size !== 32) return $url; // skip
        
        $html = get_option( Favicon_By_RealFaviconGenerator_Common::OPTION_HTML_CODE );
        if(empty($html)) return $url; // skip

        $doc  = new DOMDocument();
        $doc->loadHTML($html);
        $xpath    = new DOMXpath($doc);
        $elements = $xpath->query('//link[@rel="shortcut icon"]');
        if($elements->length === 0) return $url; // skip

        $link_favicon = $elements->item(0);
        $favicon_url  = $link_favicon->getAttribute('href');
        if(empty($favicon_url)) return $url; // skip
        return $favicon_url;
    }, 10, 2);
});
    • This reply was modified 4 years, 2 months ago by strarsis.
    • This reply was modified 4 years, 2 months ago by strarsis.
    panchorigail

    (@panchorigail)

    4 years, 1 month ago

    Hi @strarsis. Where exactly do I put this workaround? Im having the same issue, with ‘Favicon file unavailable in robots.txt’. By now I know that WordPress is pointing to specific 32 and 114px favicons, instead of the plugin.

    Thread Starter strarsis

    (@strarsis)

    4 years ago

    @panchorigail: You can put this workaround code into a separate plugin.
    Just create a plugin folder with index.php, add some metadata (plugin name, etc) and then add this piece of code. Activate that plugin and done.
    It should also work in the theme, e.g. functions.php-

    Julie

    (@juliejubilee)

    4 years ago

    Chiming in to add I’m having the same issue on all my sites too. Thanks for the workaround @strarsis, I’m going to give it a try until a patch comes out

    Thread Starter strarsis

    (@strarsis)

    3 years, 11 months ago

    @phbernard: It would be nice if this issue could be fixed in the plugin directly.

    • This reply was modified 3 years, 11 months ago by strarsis. Reason: highlight the plugin author
    Thread Starter strarsis

    (@strarsis)

    3 years, 11 months ago

    I forked the original plugin to a GitHub repository and added a simpler fix to it, you can download the master as plugin-ZIP/TAR file from GitHub, or use composer to install it directly from the GitHub repository:
    https://github.com/strarsis/favicon-by-realfavicongenerator-fork
    Fork patch release/tag v1.3.19 (forked as v1.3.18).

    • This reply was modified 3 years, 11 months ago by strarsis.
    Thread Starter strarsis

    (@strarsis)

    3 years, 11 months ago

    Addendum: Apparently this fix also introduces icons at additional places/fixes related issues:
    The Gutenberg editor shows the icon on the top left corner (nice) and apparently also the robots.txt favicon is correctly set by WordPress (see https://wordpress.org/support/topic/favicon-file-unavailable-in-robots-txt/#post-13196708).

    • This reply was modified 3 years, 11 months ago by strarsis.
    Thread Starter strarsis

    (@strarsis)

    3 years, 6 months ago

    @phbernard: I just noticed that the plugin was updated (though just formally, for WordPress version compatibility).

    Would it be possible to look into this issue (and fix), quite a number of users are affected by this.

    Plugin Author phbernard

    (@phbernard)

    3 years, 5 months ago

    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

    Thread Starter strarsis

    (@strarsis)

    3 years, 4 months ago

    @phbernard: Hi Phillipe,
    probably the email notifications weren’t enabled for this discussion, hence I just found out about your response.

    Following the chain of method calls from get_site_icon_url it becomes evident that the filter is always applied at the end of each method, so there is currently no way in core to skip (“short-circuit”) the unnecessary I/O.
    Applying the filter after the default computation is a consistent pattern in WordPress core, as the filter is passed the default result, too.

    However, this gives also one argument in favour of the performance-promise of this plugin: When the WordPress core does this I/O always, regardless of what plugins are used, this plugin wouldn’t be responsible for it. As this plugin looks up the necessary data in an optimized, cached way, its own performance impact would be negligible. This means that this plugin doesn’t _improve_ performance, but it also doesn’t _decrease_ it.

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘WordPress default icon under /favicon.ico’ is closed to new replies.