No publication status for images

[Prabudoss H]

Hi,

I would like to know why there is no publication status for images and assets. Its usually different in other CMS systems where all the resources are strictly controlled through the workflow publication process. The short risk that I can think of is that if the author has uploaded a wrong image or image with wrong aspect ratio which usually happens btw and caught during the preview. But here there is no such opportunity to catch this before publishing.

Sure this is not something new in this forum just that i am not able to completely understand this

Thanks,

Prabu 

[Stefan Schinkel]

Hi,

Workflow only works if you encapsulate assets in a document.

Best

Stefan

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-community@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-community+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

--

Kind regards

Stefan Schinkel

m. e.

617.901.2226 stefan....@bloomreach.com

___________________________________________________________________

[Prabudoss H]

Thanks Stefan for the speedy response. I read through this link https://www.onehippo.org/12/library/concepts/images-and-assets/binaries-that-need-workflow.html which basically says to use embedded resources to have workflow on images. But it essentially means that the images should not be uploaded into "Images" folder. If we do then it goes live instantly. It looks like a significant risk if we are not controlling the image uploaded to "Images" folder via a publication process. Please correct me I am wrong

Thx,

Prabu

On Thursday, 27 July 2017 17:03:45 UTC-4, stefan.schinkel wrote:

Hi,

Workflow only works if you encapsulate assets in a document.

Best

Stefan

On Thu, Jul 27, 2017 at 4:53 PM, Prabudoss H <prabu...@gmail.com> wrote:

Hi,

I would like to know why there is no publication status for images and assets. Its usually different in other CMS systems where all the resources are strictly controlled through the workflow publication process. The short risk that I can think of is that if the author has uploaded a wrong image or image with wrong aspect ratio which usually happens btw and caught during the preview. But here there is no such opportunity to catch this before publishing.

Sure this is not something new in this forum just that i am not able to completely understand this

Thanks,

Prabu 

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 

To post to this group, send email to hippo-c...@googlegroups.com

RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hippo-communi...@googlegroups.com.

Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

[Ard Schrijvers]

Hey Prabu,

On Thu, Jul 27, 2017 at 11:21 PM, Prabudoss H <prabu...@gmail.com> wrote:
>
> Thanks Stefan for the speedy response. I read through this link https://www.onehippo.org/12/library/concepts/images-and-assets/binaries-that-need-workflow.html which basically says to use embedded resources to have workflow on images. But it essentially means that the images should not be uploaded into "Images" folder. If we do then it goes live instantly. It looks like a significant risk if we are not controlling the image uploaded to "Images" folder via a publication process. Please correct me I am wrong

I don't wanna claim per se that you are wrong, although I tend to
disagree that it is a significant risk. Let me explain, and also, at
the end of my reply, I will mention a customer that didn't want this
behavior and hooked in a pre-validation for images.

First of all, images are typically not very 'risky' to expose
them....I mean, it is not that they contain sensitive text or
something in general. If they do, well....they might belong explicitly
to some document, so them use the assets in a document so it
piggybacks on the document workflow. Likewise for a, say, sensitive
pdf : Have them as an embedded document.

Secondly, in general, we strongly advice not to replace *existing*
images, but add a new one. In general, an image is visible in the
frontend by some document that links to it. Only the preview document
version in general will link to the image, so, in general, on one will
see the image. Yes, it is visible if you as an end user guess the URL.
If that is really really really a security risk, well, then we are
back at that the image should be a document embedded image because it
is apparently to sensitive. We do advice to add new images instead of
replacing because in general, images are (can be / are likely to be)
cached by all kind of intermediate proxies (like squid, varnish or
some cdn) or in the browser itself. Hence replacing an image is in
general a bad practice (this is regardless our stack, it is a general
web development thing...or if you replace it, at least add some hash
in the url for example or etag check). Any way, we thus advice adding
new images.

Thirdly, we have images decoupled from content. Many documents can use
(link to) the same image. Now assume you want to take the image
offline. This means you also first need to modify all the published
documents that link to the image....or also take them offline. Any
way, you see the point, it easily results in way more downsides and
upsides

For the above reasons, I consider the risk you mention to be in
general not applicable. As said, if it is, use embedded document
images. If you really want it differently, you can also use what a
customer did: Whenever serving an image, they first do a check whether
the image is used by at least one live document. If not, the image URL
does not work and returns a 404. That is an option, at the expense of
some performance. Also however do realize the 'check' does not work if
you want to enable cdn/caching proxies : Namely, once the image has
been live, it typically gets cached in the proxy never checking the
container any more.

I hope you see my points. Having no workflow on images in the images
folder is not some thing we missed. We have thought it through, and
apart from some minor counter arguments, I still consider having no
workflow on images by far better than having it on images. Certainly
because we do support alternatives and even hooks to plug in your own
checks and balances.

Hope this helps understanding the images design not having workflow

Regards Ard

>> m.
>>
>> e.
>>
>> 617.901.2226
>>
>> stefan....@bloomreach.com
>>
>>
>> ___________________________________________________________________

>>
>>
> --
> Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
>
> To post to this group, send email to hippo-c...@googlegroups.com
> RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
> ---
> You received this message because you are subscribed to the Google Groups "Hippo Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hippo-communi...@googlegroups.com.
> Visit this group at https://groups.google.com/group/hippo-community.
> For more options, visit https://groups.google.com/d/optout.




--

Hippo Netherlands, Oosteinde 11, 1017 WT Amsterdam, Netherlands
Hippo USA, Inc. 71 Summer Street, 2nd Floor Boston, MA 02110, United
states of America.

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

[Prabudoss H]

Thanks Ard. I see your point here. We should be able to set some guidelines on image replacing and number of images being uploaded into the system. Probably no publish status for images forces us to follow some discipline in-terms of uploading number of images in the system.   

[Ard Schrijvers]

Hey Prabu,

On Fri, Jul 28, 2017 at 6:52 PM, Prabudoss H <prabu...@gmail.com> wrote:
> Thanks Ard. I see your point here. We should be able to set some guidelines
> on image replacing and number of images being uploaded into the system.
> Probably no publish status for images forces us to follow some discipline
> in-terms of uploading number of images in the system.

I am not sure what exactly the relation to the number of images is wrt
workflow on images. As said, you can hook in some check in the
delivery tier to only expose images that have a least a published
document referring to it. Also just fyi, there are quite some
integrations with other systems if you want to store images (or
movies) outside hippo....probably not something you want but just to
inform you that it is all quite flexible.

HTH,

Regards Ard

[Prabudoss H]

Hi Ard, 

Thanks for the response Ard. If you are talking about this approach of checking whether the image is used by at least one live document. If not, the image URL does not work and returns a 404. It might have some performance implications so we would not follow this approach. The other approach using lets say 3rd party SaaS providers like cloudinary is not something we want to add at this point of time. I have put forth the 2 approaches (1) uploading the image to "Images" folder (2) upload directly into the document as resource to our UX team, lets see what their response is

The second approach dictates that we can't use the system's capability to create renditions so just wondering how does it work in other form factors (mobile, tabs)?

Thx,

Prabu