hi everyone
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?
I stored a binary file only once in the Plone registry, but not using NamedBlobImage (see my old question there: http://stackoverflow.com/questions/11637814/store-a-file-content-binary-data-inside-plone-app-registry).
Probably I also tried NamedBlobImage first but I got errors I don't remember.
So: I simply used a schema.Bytes field but this approach has some drawbacks:
That solution is not clean but I also needed Plone 3 compatibility at that time. My code is there: https://github.com/RedTurtle/collective.fbshare/blob/master/collective/fbshare/interfaces.py
If you find a better way, please share it!
It is very probably a terrible idea to store binary data in the registry.
Is there no alternative to it?
Plone is succesfully storing binary data in the registry for the site logo.
Check:
You may find additional references here:
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.
I just followed one of the links to stackoverflow. There Martin Aspelli, the creator of the registry agrees with me, with nicer words: http://stackoverflow.com/a/11638385
The site logo in Plone 5 is stored as a base64 encoded string in the registry. You need plone.formwidget.namedfile >= 1.0.12 for that (already part of Plone 4). There is also a Plone 4 backport of the site logo feature, where all necessary things are packed into one package: https://github.com/collective/collective.sitelogo
You have to use an ASCII field for your image: https://github.com/collective/collective.sitelogo/blob/master/src/collective/sitelogo/interfaces.py#L14
and change the widget to the NamedImageFieldWidget: https://github.com/collective/collective.sitelogo/blob/master/src/collective/sitelogo/controlpanel.py#L19
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.
I agree with @thet: we are talking about a couple of images not the whole blob storage; encoding and storing them on the registry seems fair.
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.
Is there a kind of best-practice example theme around doing so? Would it be a good idea to have this way in bobtemplates.plone as a base?
Update: In Themeeditor, instead of copying a whole theme, creating a theme based on Barcelonetta using the include-mechanism would be superior.
I wasn't pretty sure a logo is part of a theme or is just content; that's why I took a look at how WordPress handles it.
wel... surprise: a logo in WordPress is handled the same way we're are doing it here:
and that makes a lot of sense: I can download any theme I want, upload my logo and problem solved.
if I have to create a new theme just to change the logo, something is really broken, because I would want to change the theme without changing the logo.
now we can continue discussing if the registry is the place to store it or not.
That is wordess.com, their cloud service. Its not the same as wordpress in
general. They have a subset of specially selected themes you can choose for
the basic free service.
This looks like how you would really have to change a WordPress theme logo.
https://wordpress.org/support/topic/need-help-changing-logo-for-theme
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?