So there is a priority order starting with one in document root which would be the case for both frontend, backend (all templates). then the one in a templates media folder. finally one in the template root (this is the default which will likely get overridden on updates if we're not careful)

There is an addFavicon method in the document object but i think that will add in addition and not override existing ones

The problem @wilsonge is because the cassiopeia template ignores all of that and does its own thing. And that's why its so dam hard.

Thanks @wilsonge, that will help when I take a look at this.

The problem @wilsonge is because the cassiopeia template ignores all of that and does its own thing. And that's why its so dam hard.

joomla-cms/templates/cassiopeia/index.php

Lines 23 to 26 in a9676e3

	// Browsers support SVG favicons
	$this->addHeadLink(HTMLHelper::_('image', 'joomla-favicon.svg', '', [], true, 1), 'icon', 'rel', ['type' => 'image/svg+xml']);
	$this->addHeadLink(HTMLHelper::_('image', 'favicon.ico', '', [], true, 1), 'alternate icon', 'rel', ['type' => 'image/vnd.microsoft.icon']);
	$this->addHeadLink(HTMLHelper::_('image', 'joomla-favicon-pinned.svg', '', [], true, 1), 'mask-icon', 'rel', ['color' => '#000']);

It's not just that. I don't use Cassiopeia at all and I also attempt to do my own thing, with limited success.

The problem @wilsonge is because the cassiopeia template ignores all of that and does its own thing. And that's why its so dam hard.

I'd imagine it's a bodge around us not having put child template support into that MetasRenderer class method I linked to (which we did in the HtmlHelper method) - I think dropping child template support in there would be pretty reasonable as a PR and then re-removing that stuff from index.php

I had no problem with replacing the favicon - including the dark mode thing - for my website, using a child template of Cassiopeia. If it was user friendly is another question, but it works.

Thanks Richard. I did say it's possible. The problem is that it's not user friendly, and for a CMS, it's a relatively basic task that should be simple for anyone to do.

The thing which is not really user friendly with child templates is that we do not have a UI to make overrides of the parent template, so we have to manually copy the index.php. We need a new column for that on the override creation tab so people can chose the files from the parent template, and the template manager copies them to the right place.

... and for the favicon it could indeed make sense to provide a template configuration parameter.

... and for the favicon it could indeed make sense to provide a template configuration parameter.

I feel it's almost a global config thing, no? The template is about styles and stuff, but the favicon is as integral to the site as the site name in my opinion. You may change templates, but unless you're rebranding, the favicon is likely to stay the same regardless of template.

I feel it's almost a global config thing, no?

Yes, thinking about that it seems to make sense to me.

I should have read the complete description before posting .. sorry for that. You clearly wrote what it is about.

Besides that, George's idea sounds good to me.

@obuisard would this be a 4.3 feature maybe? New favicon setting in global config? Default empty so as to not break b/c, but if set would override Cassiopeia favicons?

I should have read the complete description before posting .. sorry for that. You clearly wrote what it is about.

Besides that, George's idea sounds good to me.

No worries. :) happens to the best of us!

I am not caffeinated enough/technical enough to fully understand George's idea so am not qualified to comment right now 😂

I feel it's almost a global config thing, no? The template is about styles and stuff, but the favicon is as integral to the site as the site name in my opinion. You may change templates, but unless you're rebranding, the favicon is likely to stay the same regardless of template.

Yes but no. With template styles the idea was you can have different colour schemes for the same template and I could imagine worlds where the colour scheme of the icon should change with that active template style. But at the same time that probably should still persist across template swap outs. It’s always tricky :D

isn’t that why everyone’s desperate for full browser support for the svg favicons (css for the win)

but if you do want that putting it in the root cms directory and not explicitly doing anything in your template should be good enough

@obuisard would this be a 4.3 feature maybe? New favicon setting in global config? Default empty so as to not break b/c, but if set would override Cassiopeia favicons?

@crystalenka I agree it could be easier to handle favicons. Some templates include functionality to make it easier to handle but most of the time you need extra meta tags and some copy and paste of files.
Having a default config for it would be a good start to make it more user friendly.
Would love to see a solution happening in 4.3.

I'd imagine it's a bodge around us not having put child template support into that MetasRenderer class method I linked to (which we did in the HtmlHelper method) - I think dropping child template support in there would be pretty reasonable as a PR and then re-removing that stuff from index.php

@wilsonge actually there's nothing that the MetasRenderer needs to be aware for the child template (I mean it's already aware)
Also the logic is quite obvious, if a user has already set a favicon (through $document->addHeadLink() the Metas or no other PHP code will override it, user then template then global...)

The $document->addFavicon() method is just a shortcut (should be removed, the favicons have nothing special to deserve their own method) for $document->addHeadLink()

To everyone else commenting here:

• the current implementation I guess was too modern and people still having problem understanding it although it's pretty straight forward (if you ignore the fact that you end up setting 3 icons instead of one): by default the icons exist in the media/system/images folder, if you want to have your own create overrides on the media/templates/site/cassiopeia/images. Unfortunately the template manager is awful and when it comes to creating overrides for static assets it won't help you at all (there's nothing in the UI for such tasks)
• Instead of monkey patching the templates go and create the logic and the UI in the template manager for creating overrides of static assets.

My 2c

For the curious, I started an informal, unofficial poll in the Joomla Facebook group: https://m.facebook.com/questions.php?question_id=10158590359435997

I'll be interested to see how it pans out in a day or two, even though it's not necessarily representative.

Perhaps a compromise would be to have a setting for default favicon in global config that would be front and backend as the default, and add params to Cassiopeia that would override the default (and document the best practices for commercial templates to do the same).

Instead of monkey patching the templates go and create the logic and the UI in the template manager for creating overrides of static assets.

@dgrammatiko can you expand on that?

the current implementation I guess was too modern and people still having problem understanding it although it's pretty straight forward

Again, I'm not arguing that it's impossible, I'm saying that it's harder than it needs to be. "Straightforward" is relative. Your experience is not universal. Neither is mine. :)

@dgrammatiko can you expand on that?

This is not exactly the part that you're asking here (static assets/images) but an interface like the one I was working on for the layouts should give you some clues: #32896 (comment)

BTW the new template manager was declined (rightly, I guess) as it was breaking B/C

While trying to change the favicon myself, I also stumpled across all those discussions.

I do see more difficulties:

1. For security reasons it is not a good idea to just override files like joomla-favicon.svg. Any hacker is able to use such names to directly identify the platform as Joomla! and therefore knows how to attack or at least which information to retrieve.

2. In modern world there is not only one favicon file needed (or three). https://realfavicongenerator.net/ generates favicons in different sizes and for Google, Apple, Microsoft and depending on the configuration much more. Adding this with light- and dark-mode of the browser and other enhancements I can think of, there are alot of different files to include. This is to much for a simple configuration option.

I would suggest to create html folder like the templates/cassiopeia/html/favicons in the html section of Cassiopeia template. This folder by default would be empty. The site administrator is able to lay down php snippets which, if they exist are included into the template as a replacement of the three code lines for Cassiopeia (marked as // Browsers support SVG favicons).

This way the site administrator would have full control over how, from where, what and how many favicons will be included into his web pages.

By the way: The security threat mentioned also is given by alot of other components like the name of Cassiopeia itself in the generated html. Not to mention the Atum template, all the information in the administrator login form ...

I do understand that today marketing is important, but it is to be done at the Joomla! sites and through the Joomla! quality and NOT in the sites of the Joomla! users.

@RichardZimmerEschborn there are a million ways to identify the tech behind a site. Security through obscurity is no replacement for real security

@brianteeman
Sure, but we don't have to shout it out either!