phbernard

Hi,

The affected Apple Touch icon URLs are “normal”, though frustrating. This is because Apple defined theses URLs by convention. In other words, any iOS device might try to access https://981kze.com/apple-touch-icon-120×120-precomposed.png and use this image if there is one.

Solutions:

• Recommended: Ignore the issue, really. Nearly all web sites live with this.
• To get rid of the issue, generate your favicon again. This time, while editing the icon for iOS, go to the Assets tab and check everything (all sizes and precomposed icons). For this solution to work, your site needs to support the WordPress Rewrite API (it apparently does not for the moment). This is overkill for such harmless issue, this is why I don’t recommend doing this.

I hope this helps!

Regards,
Philippe

Hi Sergi,

Thank you for your message!

There is no such feature for the moment. Yet, I understand your need to differentiate front-end and back-end for tab switching efficiency. It’s noted for a future release!

Warm Regards,
Philippe

Hi,

I’m sorry for the inconvenience.

I notice the URLs do not point to [your wordpress root]/wp-content/uploads/fbrfg/favicon-32x32.png but to [your wordpress root]/uploads/fbrfg/favicon-32x32.png. Is there anything special about your site in this regard? For example, did you move the media files to another directory? Or maybe you use a plugin that somehow hide the references to WordPress?

That would help me reproduce the issue.

Regards,
Philippe

Hi,

About the 404 error: do you know which URL was concerned? Some of them are harmless, although annoying. For example /favicon.ico is a classic and sometimes the plugin cannot fix this depending of your hosting environment.

About the checker error: this can happen for several reasons. Could you give me its address for review?

Regards,
Philippe

Спасибо! 🙂

Hi Rafael,

I have no idea how the plugin could cause this. “Autoload” (or “autoloud”) are not part of the plugin vocabulary. Plus its makes a very light usage of the database. It only has a fixed set of options, so this behavior should be unlikely.

What makes you think RFG plugin could be the cause of what you observe?

Regards,
Philippe

Hi,

This because you have a div in your head, which is a forbidden markup in the header. Chrome is not like the other browsers in this regards, thus the different behavior.

The code you should get rid of is:

<div class="dp_preloader"><div class="dp_loader_icon">&nbsp;</div></div>

It is probably from another plugin or your theme. Does “DP” ring any bell? It maybe the abbreviation of the plugin name for example.

Regards,
Philippe

Bitte sehr! (I don’t speak German, I really hope that means “you’re welcome” 🙂 )