Support

Admin Tools

#41499 Favicon instead of homepage in certain Browsers

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
5.2.3
PHP version
8.3.15
Admin Tools version
7.6.2

Latest post by nicholas on Monday, 20 January 2025 03:06 CST

Thursday, 16 January 2025 19:19 CST

Internetty66

Please look at the bottom of this page (under Support Policy Summary) for our support policy summary, containing important information regarding our working hours and our support policy. Thank you!

Hello,

we are quite desperate since we are experiencing a strange issue with our Joomla site.

While the homepage is working perfectly fine with Browsers Brave and Chrome on a MacBook, the same page/URL does not work on Browser Safari, Firefox and Edge and there is only the favicon logo being displayed

On tablets like iPAd the site is properly working with Safari, Brave ,Chrome and Firefox it is working fine
And when we use Opera, Edge we only see the site logo in Browser window.

With smart phone like iPhone or Android we have same issue with Edge and Opera.

Even clearing the cache on Browsers or / and on Joomla backend itself does not help.

We have obviously defined the logo image reference in our template style section in Joomla backend.
And we have proper favicon reference.

From where is this issue coming from ?
Why those Browsers are behaving that way ?
Our user base is complaining that they cannot access the site which is very severe.

We also doublechecked the underlying .htaccess file generated by Admin Tools and did not find the reason for this.

We have hopefully good paramters:

RewriteCond %{REQUEST_URI} !^/favicon\.(ico|png|svg)$ [NC]
RewriteCond %{REQUEST_URI} !^/apple-touch-icon\.png$ [NC]
RewriteCond %{REQUEST_URI} !^/android-chrome-[0-9]+x[0-9]+\.png$ [NC]
RewriteCond %{REQUEST_URI} !^/site\.webmanifest$ [NC]
RewriteCond %{REQUEST_URI} !^/browserconfig\.xml$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]

 

But it is not working.

Do you have an idea and can support us on this strange issue.

 

Thanks and regards
Markus

Friday, 17 January 2025 02:20 CST

nicholas

This appears to be your host's configuration of the web server. They appear to somehow be using the favicon as the default document for the site instead of index.php, which is really weird?

The default document is what the server will send to the browser when you access a directory without specifying a document. When you visit https://www.example.com or https://www.example.com/, i.e. the domain without any path or with an empty path, the web server is supposed to serve the default document. Typically, this is set to index.php, or index.html. If auto-index is enabled, the server will list the files under your site's root.

It appears that your host was trying to disable auto-index (which can be a security concern) but they ended up somehow changing the default document from index.php index.html to favicon.ico.

There's a simple fix. Go to the .htaccess Maker and set “Force index.php parsing before index.html” to Yes. Then, click on Save & Create .htaccess. This puts DirectoryIndex index.php index.html in the .htaccess file which instructs the web server to use index.php as the default document to display when none is specified, or index.html if the PHP file is not present.

Please note that your host may be preventing you from using this feature, in which case you will get a 500 Internal Server Error response. In this case, delete the .htaccess file, rename .htaccess.admintools back to to .htaccess and contact your host with a link to this public ticket so they can take care of the issue.

As for why it happens only on some browsers: the way I understand it (without being 100% certain) is that some browsers will try to access various default documents in your site's root, returning the one that looks more appropriate i.e. the HTML page instead of the image. FWIW, once you visit the /index.php page on your site in Safari, it will default to it whenever you type just the domain name. So, at the very least, it looks like Safari can “remember” that you meant to load index.php, not an image.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Friday, 17 January 2025 16:53 CST

Internetty66
Hi Nicholas,   thanks so much for the fast response and your great help ….very much  appreciated.   Since we have our dedicated server with Ubuntu Linux and Plesk administration, we have basically full control on everything. Interestingly there is no option in Plesk to set directory listing.   I therefore changed it on Plesk panel.ini

directoryListing = on

 

I have also checked on Admin Tools  and went to the .htaccess Maker and checked but  “Force index.php parsing before index.html” was already set to Yes.    Since we do not experience this kind of issue on any of our other twenty domains on the server, I checked on the Hosting preferences for this domain and Apache & Nginx Settings and found    Smart static files processing
If turned off, Apache will process all requests for static files. nginx will only pass requests and responses without modification. Turn off this option only for troubleshooting.   This was disabled and I have enabled it and then also cleared the nginx caching.       Now I cleared the cache on problematic Browsers Safari, Edge and Firefox and tested again. Now I can access the homepage on my MacBook, iPad and the iPhone.   On Firefox MacBook I however still do get an error …I do not get the favicon anymore but new error:     But otherwise the situation is much better than before and I asked other users to test on Android smartphones and browsers.   I keep you updated about the progress.   Thanks again and regards   Markus

Monday, 20 January 2025 03:06 CST

nicholas

This does look like a server configuration issue. This is beyond the scope of our support, though.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!