Workflow for images

Experience Manager (PaaS/OnPrem)
1

Hi all,

In our implementation we would want to implement workflow (published, unpublished and draft) for images. Is there anyone who knows how to achieve this?

Thanks in advance,

Philippe.

2

I don’t see any possible for this because the images type built in Hippo is not a publishable one. Should you create a new image type , a wrapper type ?
This would explain that

3

Hi Philippe,

you can make images publishable by simply adding publishable mixin, but be aware that on every publish event the complete image set will be persisted in version history… again. This will eat up a lot of your disc space, and performance of caching on several levels will be impeded. I would by all means discourage you from that.

regards,
Ilja

4

Hi Ilja,

Thanks for your reply. I’m aware of those mixins and properties which you can add by subclassing the GalleryWorkflowImpl to achieve this.

Although the result is that the DocumentWorkflowImpl will then be applied to images, which has side effects. For example when you want to move an image to another image folder. Then you have to allow this in the hippostd:foldertype property of the particular folder, using a template query. Which results in these ‘new document’ template queries to appear in the context menu for adding an image and this is not the way to add images.

I haven’t thought about what you mentioned about the version history in this case. That seems to be another reason not to implement workflow for images in this way.

Regards, Philippe.

5

ilja https://community.bloomreach.com/u/ilja
April 9

Hi Philippe,

you can make images publishable by simply adding publishable mixin, but
be aware that on every publish event the complete image set will be
persisted in version history… again. This will eat up a lot of your disc
space,

No, binary data (beyond a configurable threshold size) will only get
stored once (immutably) and will get referenced instead.

6

Thanks for you additional remark Ate!

@ilja, simply adding the hippostd:publishable mixin and its corresponding mandatory property hippostd:state doesn’t seems to make the image publishable, as you would expect as with documents unfortunately…

7

Hi Ate, you are right, normally binaries are stored just once. But recently I was busy removing custom image workflow, which managed to create versionable images. Luckily this customization is history.

8

Hi Ilja,

Nodes with identical binary properties use the same blob entry in this separate database table in order to save space.
As long as the binary isn’t modified, then the same reference will be used. When a workflow creates a ‘new’ version, it will keep the same reference to the blob entry in the database table.

So only if you change the binary itself (for example for an image to make it smaller), than a new blob is stored in the database. This means database-size shouldn’t be a concern in this case.

Regards, Niels

9

So, what correct way to implement ImageSet Workflow, so I can identify when an imageset is being updated?

10

Hi bwg, what I’ve learned in de past years is that the correct way of implementing ImageSet Workflow is not to do it. A common question from editors to ask for workflow is to be able to store metadata in images and have workflow applied to it. Is that also the requirement you’re having? Then I would recommend to store this meta data in the document where the image is used (using a compound with an image picker and the necessary fields). Documents have workflow, you can create better describing meta data and besides, this can also make it easier to reuse images. If the workflow really needs to be applied on the image, you can simply let the editor select another image in the document. One technical reason to (not) consider implementing workflow for images, is the reason @ilja and @ate.douma are mentioning. I don’t think that has changed.