I'm trying without success to add a NamedBlobImage field into a controlpanel option.
In my use-case I need to upload into the controlpanel one image in certain conditions (specific size, file format, and check if image is transparent).
But I get this exception when import plone.app.registry profile.
Does anyone had the same problem or can guide me how to accomplish this use-case with another idea?
That was not my point. Look up the high level descripton from plone.registry:
A debconf-like (or about:config-like) registry for storing application settings
In this context it sounds like a terrible idea to store images in there.
Think about it some more. Registry settings are exported as genericsetup profiles.
If you do not store b64encoded images in there, you can easily read/understand and modify the registry through the xml file. If you do store images in there, you cannot easily read/understand and modify the registry through the xml file.
What is wrong with the idea of letting a user manage the logo in the content area and using the registry to select a path from to take the picture? b64encoding images in a configuration registry is a better solution?
I know get it why Zope people ranted about Plone
@do3cc when storing the picture as base64 encoded string in the registry, you can for example easily import it with Generic Setup and are not dependent on a specific content structure. Also, it's easy to have different logos in lineage subsites, when using lineage.registry.
I'm not sure, if the controlpanel should depend on a specific content structure. Content is subject to frequent changes, control panel settings are not.
But what's wrong with storing a base64 encoded string, which represents a picture? It's not binary data, only an encoded form. I don't get your point.
I have never before today been tasked with making the plone site logo changeable through the web without having the skin layer any more, or without using the ZMI, so I do not have the perfect answer for you. Linking to content structure maybe is not a good idea. Then again maybe it is, with the right constraints.
What I am complaining about is the abuse of the registry. It is meant for store configuration entries.
Storing binary data in there is very much beyond that. Just because the image is stored b64encoded doesn't change its nature, it is still binary. My complaint is not about potential parsing errors.
It really is about that, using the registry for the wrong things.
In addition, there are a few things that you loose:
From a diff of different versions of GS files, you cannot see anymore, what exactly changed. There is binary data in one version, a lot of different binary data in the other.
You cannot change that data in a meaningful way with an editor.
You cannot see the image from the file system or from github.
My quick suggestion has some of the same issues, but these three points are just a minor observation. The main point is that the registry was not made for storing binary data.
This is so wrong headed. I'm amazed the logo got stored in the registry.
Its a theme component. Its not configuratiin. Its not policy. Its not
content. Its theme. If you want to create a venere that hides theming then
fine. Bad idea but anyway. If you do then at least behind the scenes, copy
the theme and and store a new logo in portal resources and explain to the
user how they can make further changes.
We are making life so complicated for users
@djay yes, semantically its theme, but in reality people want to be able to change the logo with by simple upload. Theme copy just to change the logo does not make much sense, its too big for one little change.
@djay, regarding complexity: i have the opposite experience. one client of mine uses a lot of lineage subsites with one basic theme (where also the main portal logo is defined). in his subsites, the client just replaces the logo via the controlpanel and is quite happy about the fact, he is able to do that.
also, in practice, when using stock themes a logo isn't so much part of the theme anymore. only, there are not so much stock themes for plone available.
That breaks down as soon as thry want something else in the theme different
as well. Some CSS etc.
If we want to solve the problems of not overriding a whole theme to replace
a logo, or how to have subthemes for subsites then let's solve it. But
putting the theme in the registry just doesn't make sense.
BTW its possible now to create diazo themes that override without copying
by including. I personally think it's gets messy but you can do it. I think
a simpler model however is to copy the theme and provide tools to do diff's
and copy over changes. Much easier to understand since the theme is an
integration and very rarely robust enough to handle reuse well.
As I said, we can still have a control panel to help guide the user for
simple themes but it should modify the theme and tell them how its doing
that. We should be empowering the user to create great custom sites. The
idea of people not making changes to themes is not realistic and even less
so in the plone world.
What exactly is the objection to copying a theme to change a logo?
Extra disk pace?
The fact that someone might actually desire their website to change under
them in an upgrade?
The 5 min it takes to re upload another logo if they switch themes, which
is likely needed due to the theme having a different space?