I'm sorry, but I don't consider that usefull. I would want to have a different file for the logo in my website than in my mails and yet another file than in my generated PDFs. You also might have sites that have subsections which have completely different logos than their main page. Last but not least, the global configuration is the place to set settings which are stored in configuration.php and the logo of a website has no business there. That file is for settings that have to be available even without a database connection.

@Hackwar great, that's exactly the sort of thing I wouldn't have thought of. Is there a better place for it than global configuration?

That's not to say I am ignoring your other comments because they are all valid and I had thought of exactly the same issues myself. But those problems are possibly something that could be overcome to an extent, and in any case, at the moment the option is nothing, so you write custom code, so with this option, you are no worse off.

A lot of templates define the logo as a configuration parameters and that the place it should be

A place for that option would be the media manager, if you really, REALLY need it.

Well I use a logo in every single project. So I guess I do really need it. I mean, imagine if the template devs automated that part of Joomla! that would be one less step for the user. I don't REALLY need a lot of the other options in Joomla! core, but I definitely use a logo every single time.

@ylahav yes, but they would not have to if it was defined globally. It would mean we could change templates without having to tell it a new location for the logo. It would also mean components have access to it, which is one less step to set up new components - if they use a logo. I consider it one asset that could be shared globally as it is used in many places. I'd even consider there should be a front end logo and an admin logo, which would mean integrators could brand backend components as their own if they wanted, and make a more holistic approach to the way they brand their service to their clients.

To me this is an abuse of the global config (something we do too much of)

@uglyeoin Any template uses different place / size of the logo - and it is recommended to adjust its size to the template...
If i want to use the logo in several places - i will put it in the 'images' directory...
... and I agree with @brianteeman

@brianteeman because of the reasons @Hackwar mentions? I'm not against moving it, my goal was a central location, but the point in this is to hear everyone's opinion as I'm sure I won't have thought of every angle.

Without having some tools in core to dynamically regenerate images at proper sizes, I don't think this works well. Even the "if I change template I need to respecify logo" argument doesn't hold a lot of value unless you incidentally have two templates where the logo space is the exact same (or you're putting a 2000 pixel image in a 200 pixel space). I know this is about to go over the heads of a lot of people here, but if we had something like this config snippet then maybe I could buy into "one field for all the logos" in global config, but right now I think it's best left to be handled at the extension level.

Maybe something that can be useful is the ability to have a 'configuration' override... I saw something like this in suiteCrm BUT I am not sure how we can do something like 'custom field' for configuration. In one of our Joomla project we wrote a "management" component that deals (with some other functionalities) extra configuration BUT it is not limited to logo...

As I see it the 2 options are...

Template Config

• Allows different logos to be assigned to different menu items
• Easy to set up a 'default' logo with the template if no logo is set

Module Position

• Allows different logos to be assigned to different menu items
• Open to access levels
• Not restricted to an image

I personally never considered adding to the global config. Seems a little restrictive considering what is available to the above options. There is some fridge advantages as you have pointed out but not sure if they are reason enough to change.

So as far as i know marketing and ux team decided last year to implement more the integrator and the company into the backend template to increase the identification with the site (correct me if I am wrong) In this case the Logo(s) could be setup in something like an "environment" setup.

For me as a marketer and designer the logo is something general for a site and indeed useful to have it setup generally. The best option would be to have it as an svg and so automatic versions in negative and positive colors. But yes, I know we have the security risks here.

Additionally to the logo it would be good to have the whole set of favicons and appicons somewhere generated from it just like the realfavicongenerator.net is doing... that would be a great feature.

@ylahav I'm not sure what the benefits are, but it's another thought. I think that's a lot bigger than my original suggestion and it seems global config is the wrong place for this idea anyway.

From a UX perspective I imagine an advantage to having a global location to set a logo. Module position may not seem that obvious to a novice user. The template configuration is somewhat hidden away and varies from template to template. There is merit to what you suggest just not sure how best we can achieve this without compensating in other ways.

@ciar4n I agree, it's an idea that needs thought, not just a quick and dirty implementation. We should be moving towards srcset anyway, so that's another thing to consider (in my opinion at least)

Having srcset support baked into core requires a mentality shift. There
are things needed in core for that to work we’ve always called extension
territory.

On Tue, Jun 12, 2018 at 8:03 AM uglyeoin notifications@github.com wrote:

@ciar4n https://github.com/ciar4n I agree, it's an idea that needs
thought, not just a quick and dirty implementation. We should be moving
towards srcset anyway, so that's another thing to consider (in my opinion
at least)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#20727 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfofGuXgy_inv6piTcLKghxdlaq1ueks5t77wzgaJpZM4UkUX1
.

--

• Michael Please pardon any errors, this message was sent from my iPhone.

@mbabker well of course, introtextimage and fulltextimage both would require a bit of work. So would any editor buttons for images. I'd say being against mentality shifts is a poor place to be in a technology market. Being a disruptor used to have such negative connotations ha. But understand, this is not a minor job. I think it's probably a necessary one. Again, open to comments as I'm not the leading authority.

If joomla was like Twitter, Facebook, YouTube etc which have a fixed template then having the logo would make sense. But it's not and the chances of two template having the same dimensions for the logo and using the option are not very likely I don't see the benefit. In fact following the social media examples the correct place is where it usually is now - in the template

Adding srcset to the core is not an impossible job.

Adding srcset to the core is not an impossible job.

No, it's not. But there are capabilities lacking in core's media handling (many of which might be fixed with the 4.0 rewrite, that's one project I honestly haven't looked deep into) which makes handling of srcset left entirely to the end user working in a combined offline mode handling image resizing and an HTML entry mode without support of the WYSIWYG editor or any of our core tools.

You're out of touch as there are quite a few plugins that will do all of this for you :)

I know extensions handle it. But core doesn't. That's kind of my point, and where my comment about the mentality shift comes from. We've pretty much left key parts of "true" srcset support to the ecosystem to fill, for better or worse. Personally, I can't help but to feel maybe that shouldn't be the case.

It absolutely should be in core. I think people expected the new media manager to have it and remember it was originally to be launched over a year ago.

As discussed with @uglyeoin this is being closed