Question own favicons

I'm a little annoyed that webtrees overwrites my own favicons with each update and I have to put them back manually. 

That's why I wanted to try to write a module that automates this. But now I had a different idea, hopefully someone will know if that can work. Otherwise, I will have to wait until the next update of webtrees.

My idea was to make my own favicons with "chmod -w" write protected. Would that work or will the update be in the soup?

Please your appreciated response.

Maybe update your webserver configuration to match the URL /favicon.ico, and serve a different file instead?

Hi @fisharebest

Thank you for your reaction. Probably I'm stupid or my knowledge of English is to little, but I don't understand how your solution should work. 

The problem is, that after every update my favicons are overwritten by the standard favicons of webtrees. I thougt, if I make the favicon files writeprotected, they cannot be overwritten. But doesn't crash the update if some files are writeprotected?

Other solutions are also welcome. Please explain some more clear how I should change my webserverconfiguration.

Instructions will be very different depending on which webserver you use. Apache and nginx are most popular.

Me thinks an alias would work.

This piece of config should be somewhat at the top, before it decides to let anything else be processed by index.php

I have not tested any of this. Beware that browsers can be stubborn in serving favicons from old cached data, even if you order them to purge the cache.

I liked your proposal to put the icons in a separate view, outside of default.phtml, to make it possible for a module to change it in a simple way.

Perhaps solving it with server config is more elegant, but also more troublesome and error prone for not so tech savvy users.

bertkoor wrote:

I liked your proposal to put the icons in a separate view, outside of default.phtml, to make it possible for a module to change it in a simple way.

I think for "normal", non-tech users is the solution with a module the nicest and the most elegant.

Is there a chance that my proposal will be accepted if I can make a working module for it? Who is deciding it?

Before I m trying to write a module, I like to know if a seperate view is acceptable for the webtrees developers.

I would be very happy with a module for favicon. Years ago ( www.webtrees.net/index.php/forum/2-open-...22568-favicon-change www.webtrees.net/index.php/forum/9-reque...avicons-customizable ) I have requested this, there was a time, when the favicons were in every theme, so after the update it was a lot of work.

Now I just copy the png favicons to the folder "public" and the favicon.ico to the root.

> Who is deciding it?

The ultimate decision to accept a PR is solely with the owner of the repository: fisharebest.

There are currently another 42 open pull requests. About half of them solve known bugs. In my experience it gets very hard for a PR to get accepted when 24 hours have passed since it was created.

This PR clearly makes it easier for custom favicons to be supplied by a module. I could make such a module in no time. But other (custom) themes should not override the default.phtml, otherwise it does not work. I don't know whether they do or not. And the same change can be created with exactly that: override the default.phtml. So in balance it does not bring much improvement, although I see its value.

hi Bert,

Thanks for your reaction. Yes, I could overwrite the whole default.pthlm. But then I have to check after every update of webtrees the whole default.phtml for possible changes. It is even anoying as restoring every time my favicons.

If @fisharebest has the opinion that it has to be not possible to change the default favicons for own, it should be nice that that will be claryfied. But if the intention is to make webtrees more customer-friendly for this request, it shoukd be nice to find a good solution for update 2.2.7.

In my opinion there should be a workaround that it is not needed to check after every update your customisations.

jopla wrote:

In my opinion there should be a workaround that it is not needed to check after every update your customisations.

Yes, well... that work-around then would be the apache/nginx config with an alias.

Thanks for your reaction @bertkoor, but that solution is not very "klantvriendelijk" (client friendly?), as you mentioned also earlier.