Troubleshoot apple touch icons nginx webserver
In working with Nginx webserver and a client who wanted to have customized apple touch icons display when an end user bookmarked their page or used the “send to desktop” button within Safari to show their customized icon, we discovered an issue that seemed to creep up out of the blue with apple touch icons. I wanted to detail a few things I went went through to troubleshoot apple touch icons nginx webserver.
Of course I started out thinking there was something essentially wrong with the icons themselves. In the beginning of spinning up the website for the client, the icons worked. The client was running Genesis wordpress framework, and we had the custom icons in the images root folder of the theme and being called in the wp head loop context to link to the images. All was fine, until we decided to modify these or so I thought. I say it that was as this turned out to be a case of coincidences (don’t you just love those that send you down one road of troubleshooting just because of timing?).
Coincidentally, of course I decided to test the icons after they were changed. Well, AFTER they were changed is when I discovered they were not working. Apple devices were simply showing the ugly default screenshot of the webpage icon. I assumed logically that these were not working after I changed them. Well after several hours of drudging through recreating the icons and trying multiple versions of implementing the apple touch icon code in the webpage header, I started looking elsewhere.
Absolutely nothing I changed in regards to the icons themselves or the code that implemented them improved the situation. They simply did not work. However, in doing some googling, I read a blurb about websites that were password protected and apple touch icons not working. Well, our client’s site was indeed a password protected site. This got me to thinking that the issue could be related to nginx basic_auth permissions causing the issue. The funny thing is, we had implemented the basic authentication on the website months back. However, no one had thought or needed to check the icons as shortcuts for most of those involved with the site were already copied to the devices. A quick check of taking off the basic authentication for the site and testing the icons and BOOM they were working! So we definitely knew it was coming from the authentication.
Resolution
The resolution to the issue came in simply copying the apple touch icon images to a folder on the webserver that was not locked down and pointing the link in the website header to this new location and this resolved the issue. There may be a good way in Nginx in the sites configuration file to allow traffic only to the icon images, however, for the sake of time and getting them up and running, we simply opted to copy them to the open location and be done with them for now. Hopefully this will help someone who may be running into this issue now with a password protected site running on Nginx.
