function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
paul-lmipaul-lmi 

Sites favicon implementation does not work unless using custom domain configuration

Modern browsers are expecting the favicon to be in the root of the website.  In sites, it's implemented in the root of the "site" app folder, rather than the root of the <company>.force.com folder, which is the stock Salesforce favicon.  I'm presuming this was either an oversight, or based on the assumption that no one would want both favicon support and be required to use the *.force.com hostname. 

 

The only way favicon support will work in this implementation is if:

  1. You are using a custom domain
  2. Due to 1, you are also not using SSL

 

Please allow for the favicon support to be set at a company level instead of on a per-site level.  The use case for having separate favicons in the same business/company must be much smaller than the use case for needing it on separate sites for the same company (ie,SF org).

 

Examples

https://logmein.secure.force.com/favicon.ico = SF icon

https://logmein.secure.force.com/support/favicon.ico = our configured icon

 

I didn't bother posting this to the ideas site because apparently the use case for requiring SSL on all sites traffic is so small.  I figured posting to Ideas would be a waste of time.

 

Either way, it's a pretty large hole in the feature, and in the short term, it definitely needs to be documented.  Troubleshooting this was a pain due to the "it will take 24 hours to see your change due to caching" comment, which is also not completely accurate.  Instructions for implementing this and verifying it as successful merely involve visiting the URL for the favicon directly, so I don't see why that couldn't be added to the documentation as well.

Best Answer chosen by Admin (Salesforce Developers) 
BulentBulent
For this case you need to create a site with no path (root / level) and use the favorite icon at the root level.

All Answers

BulentBulent
For this case you need to create a site with no path (root / level) and use the favorite icon at the root level.
This was selected as the best answer
paul-lmipaul-lmi
hmm, i think that'd work for one of our use cases.  i have one site at /support which allows for general support things like web2case, and was planning to roll out our custom customer portal in another to segregate the security.  if we use all custom controllers, do you see any risk in loosening record security on a single site to fit multiple use cases?  obviously record sharing rules always win, and it would be up to us to ensure anything we want to be protected would be on an authentication-required page.
paul-lmipaul-lmi
oh wait, you're just saying create a stub site to simply clue the browser in on the favicon, aren't you?  that's /facepalm kind of simple.  i thought the path was required.  i wouldn't have used /support in our original design if i new it wasn't needed.  :)
RyanGuestRyanGuest
As a best practice, I always create a default site without a path.
ArtabusArtabus

You don't need your icon in the root path if you add an additional html tag to your VF Page :

<link rel="icon" type="image/png" href="{!$Resource.Favicon}" />
paul-lmipaul-lmi
i avoid manual/extra non-VF tags wherever possible to ensure SF doesn't break anything on me when they do upgrades.  that said, i do use this tag on another non-Sites website I run because the web application seems to prefer forcing it's own favicon.  thanks.