By the way, we can see that the server returns in this case a 403 error instead of 404, probably because of the .htaccess file inside the misc directory, which denies access to all files by default.

Are you using Apache? The .htaccess should specifically allow these files in misc/user.

Also the files should exist by default unless they were deleted.

Yes I'm using Apache. I have an .htaccess file under the misc folder with the following content, which cause the 403 error :

<Files "*">
<IfModule mod_access.c>
Deny from all
</IfModule>
<IfModule !mod_access_compat>
<IfModule mod_authz_host.c>
Deny from all
</IfModule>
</IfModule>
<IfModule mod_access_compat>
Deny from all
</IfModule>
</Files>

It seems that the current code does not generate this file in this folder (Should it?), but I don't remember having created it manually. Maybe it's a relic of an older version, as the initial installation on my server goes back to December 2012 and was updated regularly until the current version.

Anyway, this isn't the main subject for which I opened this issue :) If I remove this .htaccess file, I still get a 404 error because Piwik tries to load the images even if they don't exist.

You say that they should exist by default, but from where should they come from ? I don't see them either on the repository nor in the downloadable archive. Are they generated or copied at setup time ?
AFAIK they are created only the first time the user configures a custom logo or favicon, isn't it ?

True, they actually don't exist. I forgot that I had custom logo uploaded.

I presume the problem is, when not showing the <img> and then uploading an image, the instant preview would not work. So we also need to update JavaScript to create this image element in case it is not there or solve it differently.

You're right, I forgot the JS. The instant preview is broken with the commit mentioned above.
The image source is fetched from the srcattribute, so it's not so easy indeed.

Maybe we could always create the <img>tag with a data-src attribute giving the image path (without the cache buster), and generate the srcattribute on server-side if the images exists or on client-side after an upload (based on the path given by the data-src attribute) ?

Thus we avoid depend on another element to generate and position the images.

This would give a template line like this :

<img data-src="{{ pathUserFavicon }}" {% if hasUserFavicon %}src="{{ pathUserFavicon }}?r={{ random() }}"{% endif %} id="currentFavicon" width="16" height="16"/>

Hi @ksubileau if you can test it, and create a Pull request, we would be glad to investigate and merge it!

@ksubileau sounds like a good idea 👍

How about the 403 error. I actually have uploaded the images but it doesn't show them because it's showing the 403. Has one of the htaccess files been kept from a previous version but it no longer needed? There's one in /misc/user/ but also one in /misc/ which dates back to 07/08/2013 in my installation. Should this be modified or deleted?

I've answered my own question. On the current repository, neither of these .htaccess files exist so I'll remove both for now.

It's possible that some files were not writable in that directory and then it couldn't update or remove an .htaccess file. The updater does - I think - not show an error in this case.

@trusteddigital The .htaccess file under /misc/user is generated at setup and upgrade times by the ServerFilesGenerator class
But as I said earlier, it seems that the .htaccess file of the misc folder is a relic of an older version. The fact that you also have this file causing the same 403 errors seems to confirm this hypothesis.