Browser Can't Find Icon Specified in the Manifest
ttbek opened this issue · 7 comments
The Chromium console states: "Error while trying to use the following icon from the Manifest: http://localhost/icons/192.png (Download error or resource isn't a valid image)"
How do I specify the icons for the manifest file in the config (toml in my case)? I find that one is being generated:
{
"name": "Binario",
"short_name": "Binario",
"display": "browser",
"background_color": "#2a2a2a",
"theme_color": "#1b1b1b","description": "Responsive card-based & code-light Hugo theme","orientation": "portrait","start_url": "/","scope": "/",
"icons": [
{
"src": "icons/192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "icons/512.png",
"sizes": "512x512",
"type": "image/png"
}
]
}
I'm not sure where the 192 and 512 versions are specified and for some reason Chromium says it can't find the one in icons/192.png... though it appears to be there.
Acually, on the live version of the site (https://kunji.entrydns.org/) I see a few other icon related errors.
Failed to load resource: the server responded with a status of 404 (Not Found)
/icons/16.png:1 Failed to load resource: the server responded with a status of 404 (Not Found)
/icons/192.png:1 Failed to load resource: the server responded with a status of 404 (Not Found)
(index):1 Error while trying to use the following icon from the Manifest: https://kunji.entrydns.org/icons/192.png (Download error or resource isn't a valid image)
The files do seem to be in those locations (theme/binario/static, which gets copied to /public/ during gneration, and which I move to my Apache web root), but yeah, the browser doesn't seem to recognize that.
I'm probably missing something obvious, but I'm not sure what. File permissions are the same as for my avatar.png in /static that the browsers see just fine, but that is specified as the avatar file in my config.toml. So maybe that is why.
I've added isso for comments, fuse client side search, and got the MathJax loading on the summary blocks as well now, but I haven't pushed that version to the server yet. Also added Nanogallery2. Now I'm just tying up loose ends and I think this icon issue is all that's left in terms of actual errors. Then I need to figure out how to apply the MathJax to the search results, I've seen a working example with Katex, but Mathjax seems less straightforward though I'm probably making some silly mistake there as well.
It seems to load properly on some pages, it seems like they are maybe the ones that don't use the layouts/_default/baseof.html template. E.g. https://kunji.entrydns.org/avatar.png loads the icon just fine.
Hello.
File permissions are the same as for my avatar.png in /static that the browsers see just fine, but that is specified as the avatar file in my config.toml. So maybe that is why.
I don't think so.
https://binario.netlify.com/icons/192.png - Netlify demo, 192.png file exist.
https://themes.gohugo.io/theme/Binario/icons/192.png - official demo, 192.png file exist.
https://kunji.entrydns.org/icons/192.png - Your site, file 192.png doesn't exist (Apache "Not Found (404)" error).
It looks like something going wrong on the server side because I can't get 192.png icon through the direct link (https://kunji.entrydns.org/icons/192.png). The same for other icon files. Check your site files (icons folder exists?) on the production server and server setup again.
Additionally, I can access to some server folders like this: https://kunji.entrydns.org/css/ or this https://kunji.entrydns.org/img/. So, in theory, the folder https://kunji.entrydns.org/icons/ should also be available, but no (403). You need to check your server setup again.
@Vimux Thanks for checking this out. My Apache config is almost bog standard, only change being for isso:
<VirtualHost *:80>
ServerName localhost
DocumentRoot /var/www/html
<Location "/isso">
ProxyPass "http://localhost:8001"
ProxyPassReverse "http://localhost:8001"
</Location>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Your assessment makes sense though, I've been a bit puzzled as to why I cannot reach the icon png directly.
The file is definitely there:
ls -la /var/www/html/icons/
total 28K
drwxr-xr-x 2 root root 4.0K May 25 02:14 .
drwxr-xr-x 17 root root 4.0K May 25 02:14 ..
-rw-r--r-- 1 root root 86 May 25 02:14 16.png
-rw-r--r-- 1 root root 126 May 25 02:14 192.png
-rw-r--r-- 1 root root 94 May 25 02:14 32.png
-rw-r--r-- 1 root root 97 May 25 02:14 48.png
-rw-r--r-- 1 root root 201 May 25 02:14 512.png
Found the Problem
In summary, by default Apache2 aliases /icons/ On a Debian based system this configuration is found in /etc/apache2/mods-enabled/alias.conf
On CentOS systems in /etc/httpd/conf.d/autoindex.conf
Should this be changed in the theme since in conflicts with default settings of a popular webserver? Otherwise, could it be noted in the documentation?
For anyone that prefers to change the folder location rather than changing their Apache config, they can do the following:
move themes/binario/static/icons to some other name:
mv themes/binario/static/icons themes/binario/static/newname
Then the following two files need to be modified:
themes/binario/layouts/index.manifest.json
themes/binario/layouts/_default/baseof.html
Change the references to icons in these files to newname, e.g.:
"src": "icons/192.png", -> "src": "newname/192.png",
and:
<link rel="icon" href="{{ "icons/16.png" | relURL }}" sizes="16x16" type="image/png"> -> <link rel="icon" href="{{ "newname/16.png" | relURL }}" sizes="16x16" type="image/png">
All the stuff about the social icons are in other files, so a simple find + replace all will sort this out.
I'll close the issue when @Vimux decides which way to go with this (any decision is fine, even to do nothing, just as a conclusion to the topic). Or @Vimux can of course, it's Vimux's project, it is close-able at this point as far as I'm concerned.
As for me, it's like Internet Explorer 6 (or 7 or 8, or your "favorite" IE version). Maybe such default settings in the popular product seem logical for someone, but for me, it's not. Sometimes it is better not to support it.
My current decision is simple: no changes in the theme folders structure (definitely not now). Add a comment about the situation with the Apache default config in the README file? Probably. In any case, @ttbek thanks for your opinion and the link.
P.S. I will close the issue on Monday when I add a comment about this in README.
Sounds good to me, thanks for your time on this issue and for all your time and effort in making the theme!