Logo Customization on control panel

[bloodbare]

No description provided.

[agitator]

+100

[djay]

Whats wrong with a logo in the default diazo theme that can be replaced?

[agitator]

a basic plone installation should be able to allow that, with or without diazo

[davisagli]

A setting that says 'logo' is easier to find and use than realizing you can copy and edit the diazo theme. This is the first and most common customization that people want to do; it makes sense to go out of our way to make it easy.

[djay]

plone 5 should ship with a diazo theme you should be able to edit immediately.

Clicking

"Theming" > "modify theme" > "logo.png" > "upload file"  

is pretty intuitive. Not much less than having a control panel to change the logo. If it's not intuitive enough lets fix it.

Diazo is our theming story so there is no "without diazo". We should be introducing users to it as soon as possible to smooth the learning curve, not replacing it with another kind of theming which does just a few things. Plus it's yet another thing to maintain and translate. And of course, if the theme uses a different logo filename? Then you have a control panel that doesn't do anything so is confusing.

Whats the next thing users ask for after the logo? Editing the css. Are we going to create a new way for them to edit that too?

[davisagli]

It has bugged me for years that we don't have a one-step way to do this. It's not "another kind of theming;" it's making something that should be easy very easy.

I totally disagree that forcing people to use Diazo immediately smooths the learning curve. It adds a bump to the learning curve. We should identify the 5 most common things people want to change and make sure they can do it without learning Diazo.

[davisagli]

Also if someone only wants to change the logo, we should not force them to create a custom theme, which would then not automatically update if fixes are made to plonetheme.barceloneta upstream.

[djay]

They don't have to learn diazo just the theme editor. The theme editor lets someone change css and images and js without knowing the first thing about diazo rules. I've given many users access to update css files who don't know diazo and it's been very empowering for them.

We don't have to create a copy of barceloneta. We can do what I call an identity theme. One that gives you places to change certain things but looks exactly the same as the base theme. Alternatively we could copy barceloneta since, as soon as you start altering a theme it becomes a mess to handle upgrades in theme underlying theme changes. barceloneta should be a starter theme not a very complex theme for which you want to get updates to.

[bloodbare]

I would just add a option on the settings to change the logo and a silly scripts that stores somewhere. We can always edit the theme on diazo , but the site/logo.png should be something we can change in a easy way.

[agitator]

changing the logo should be as simple as changing the site name

[djay]

I would argue that currently

"Theming" > "modify theme" > "logo.png" > "upload file"  

Is much more intuitive than how you currently change the title. Changing the title is under Site setup > Site > Site title. I have found a lot of clients have never noticed the the "Site" control panel and many never update their site title. Since the site title is mainly seen in the html head I wouldn't be surprised if most users would be looking for a "theme" or "templates" control panel to adjust that. In fact title and description should probably be moved to the theming control panel.

[agitator]

btw. there are so many plone sites that do their job without any theming - people just want there logo there. don't make it more complicated than needed.
site settings > logo

please!

[davisagli]

We should include site title and logo on the form for creating a new plone site.

[bloodbare]

And also the favicon ?

[davisagli]

I'd say don't include the favicon on the form for creating a Plone site. Every site needs its own title and logo; not every site needs a custom favicon

[ebrehault]

Hi @giacomos
I have marked this issue as a blocker for Plone 5 beta (but that's probably discussable).
You have self-assigned this issue, could you tell me what is the current status?

[agnogueira]

This package add some fields to site config to allow the user to change or hide logo, and also let you show/hide portal title in header: https://github.com/collective/collective.themecustomizer

[ebrehault]

I guess we might re-use some code from collective.themecustomizer. The idea here is to have this feature in core.

[djay]

Why not just have the logo and title in the theme which they can customise TTW via plone.app.theming?=

[djay]

Here is my 2c for whats it's worth.

I think the logo is fundamentally different from the site title as is much more related to theming.
Some sites don't have a logo. Some have 2 or 3 logos. Some have logos built into banners and using backgrounds. What if they want a large logo and theme doesn't support it well? Where do we draw the line in supporting customisations without requiring them to know the basics of html and css? I think people aren't idiots. There is a flood of tutorials out there on how to add an image to html or and adjust it using css. If we create a short cut making it very obvious how to copy and customise the out of the box theme, make it very obvious where the logo.jpg is, where the .css is and where the .html is then we are putting people in both an environment that matches up to all the tutorials on the web (not one they have to learn special rules or limitations for) and one that is empowering because it shows them where they can do more. Insert a twitter widget or add a 2nd logo or a background.
Someone also mentioned that this would prevent upgrades to the theme. Thats a good thing. The last thing someone needs is to upgrade the CMS and find their public facing website has changed. We should be providing them tools to diff and integrate their changes to the theme from the base rather than encouraging them to not customising their theme. @asoko has already started on git integration which could make this possible.
As much as possible I think we should not be adding extra layers of of half powerful customisation to the UI. No more ways to do the same thing please. Less ways, just lets guide people and make them obvious!

BTW, with our clients, if they ask how to change a logo or adjust the css, we give them a 3 hour diazo training course. Some of our customers have not just changed their logo but completely replaced their themes largely on their own. We have a killer feature which is relatively clean and safe TTW theming. We should not be hiding this.=

[thet]

i'm taking this one.

i see two ways of implementing it:

• storing a base64 encoded string in the registry, if a custom logo was defined. the responsible viewlet would call some @@image/@@sitelogo browser view to decode and deliver it to the browser with a cacheable url. the fallback, if no logo was defined, would be some ++plone++logo.png resource
• storing the image somewhere in the content hierachy as real image.

altough option 2 has advantages regarding caching (i suppose), i think it raises too many questions: where to store, what to do on id conflicts, how to handle AT vs DX images, etc.

suggestions welcome - /cc @bloodbare @davisagli @tisto

[gforcada]

@thet I would go for the second: create an image named logo and that's it. We could handle that indirectly from the control panel itself, to find it easier.

The AT vs DX can be solved with a try/except right?

Also for documentation that's just simple, clear and to the point: do you want to change the logo? Just use the control panel or directly create/modify what's in mysite.com/logo

[thet]

i already startet implementing the logo stored encoded in the registry. prerequisite is this branch, which allows the NamedImageWidget to be used on a zope.schema.Dict field, which can be stored in the registry: https://github.com/plone/plone.formwidget.namedfile/tree/thet-dictfieldconverter

i have the feeling that it's a bit hairy to depend on specific content structures. my solution is also easy. you just have the plone.formwidget.namedfile image widget in the site control panel to set the logo. unless there is a strong disagreement with that, i'll continue what i started.

[djay]

Why wouldn't you store it in the current diazo theme?
The caching rules are such that in most cases content images don't have strong caching. A logo really has to have strong caching since it's used on every page and is unlikely to change. =

[thet]

do you mean, storing a fileupload from the site controlpanel in the current diazo theme? hmhm... but that would be removed when installing an updated version of the theme, no?

i'd rather make sure, that the logo is strongly cached.

sidenote about one of my usecases: conent editors are creating lineage subsites. i want them to be able to customize the logo for the subsite without much hassle. with lineage.registry in place and a site controlpanel, wich isn't only bound to the plone site root, one can just do it via the upload widget in the controlpanel.

[djay]

I think you are optimizing for a case that doesn't or shouldn't happen.
Sites don't want updated themes. They want to update plone and have it look
exactly the same. A theme is not like a plugin that unknown third parties
improve. Its you own site look and feel and you should control that.
It doesn't feel right taking something which is the very essence of your
site theme and brand and taking out of the theming control.
If you are worried about theme upgrades perhaps its better to tackle that
problem directly instead?

[davisagli]

It's an entirely reasonable use case to want to give a user control over the logo but not over the entire theme. Maybe it's a user who is new to Plone and you want to reassure them that it will give them control without diving into the deep end of teaching Diazo theming immediately. Maybe it's someone responsible for a subsite in an organization that only wants a few people to have full control over the theme.

Also, storing it this way in the registry doesn't prevent someone with theming privileges from putting their logo in the theme if they want, so it seems noninvasive. +1

[djay]

If they are new to plone them a control panel or documentation that
modified a logo.jpg in the theme seems reasonable. No need to learn diazo.
Single image, no rules.
Then there is no later question of "now I've learnt theming, where the
heck is my logo I uploaded? Why isn't it in my theme??"

Lineage themes where users control logo and not the theme is a very special
case. If you are making a theme like that then there is likely other
aspects you want certain users to control too. There are plenty of ways to
support this like special portlets. Doesn't seem like a good reason to make
a special new exception to how we do theming. CSS is in the theme. Js is in
the theme. Logo is in the theme... Except if it isn't.
On 9 Jan 2015 00:54, "David Glick" [email protected] wrote:

It's an entirely reasonable use case to want to give a user control over
the logo but not over the entire theme. Maybe it's a user who is new to
Plone and you want to reassure them that it will give them control without
diving into the deep end of teaching Diazo theming immediately. Maybe it's
someone responsible for a subsite in an organization that only wants a few
people to have full control over the theme.

Also, storing it this way in the registry doesn't prevent someone with
theming privileges from putting their logo in the theme if they want, so it
seems noninvasive. +1

—
Reply to this email directly or view it on GitHub
#165 (comment)
.

[thet]

related pull request on plone.formwidget.namedfile:
plone/plone.formwidget.namedfile#15

[thet]

all done and merged, and works like a charm:

• Base64Converter for file/image widgets on ASCII fields plone.formwidget.namedfile#15
• site_logo in controlpanel + @@sitelogo view #355
• support for site_logo from registry plone.app.layout#38

[pbauer]

🍺

[gforcada]

👍