Hi Edgar,

This is indeed the case - the imaging module could be described as "not 
multisite capable". I would say the current design of the imaging module is 
"parallel" to the multisite concept for the website workspace.

The mode of operation is something like this: /.imaging/<generator-name>/**  
trigger the imaging module and invoke a specific generator. It is then up to 
the generator how the rest of the URL and other parameters are handled, and to 
resolve an image. The concept of site doesn't really enter into it until after 
the STK generator is invoked, when it uses the site to resolve the theme, to 
find the defined variations.
In addition, the imaging module caches such images in the imaging workspace. 
The imaging cache is also not "multisite capable", nor does it evaluate 
permissions in any special way.

I agree with you that this behavior could be viewed as a bug, in the sense that 
it is a "common problem" which many users face when implementing "secured 
areas" in websites, or in co-hosting situations.

Possible improvements might include:

- tie security into the cache (eg something like reading from imaging cache 
requires read permissions on original image)
- make the stk generator multi-site aware and tie in the cross-site security 
(maybe fabrice' solution is a basis for this)
- consider how these concepts mesh with the site variations, personalization, 
vanity URLs and URL shortening features

That's my 2c

Regards from Vienna,

Richard

> -----Ursprüngliche Nachricht-----
> Von: [email protected] [mailto:user-list-owner@magnolia-
> cms.com] Im Auftrag von Edgar Vonk (via Magnolia Forums)
> Gesendet: Montag, 07. Juli 2014 20:43
> An: Magnolia User List
> Betreff: [magnolia-user] Re: Image variation and URL
> 
> Hi guys, we just ran into this issue as well. Took us a while to figure out 
> what
> the problem was.
> 
> Really the issue seems to me that the imaging module simply does not
> support multisite when it comes to generating image variation URLs? It
> seems to me that the custom ImagingSupport class that prepends the
> current site (application) as Fabrice suggests should be the default behaviour
> in Magnolia? Do you agree? Because if so I will create a JIRA issue for
> Magnolia.
> 
> @Fabrice: any chance you would be willing to share the source code of your
> ImagingSupport class?
> 
> cheers
> 
> Edgar
> 
> --
> Context is everything: http://forum.magnolia-
> cms.com/forum/thread.html?threadId=871e4fc3-d8eb-4c50-9232-
> 1c2610739504
> 
> 
> ----------------------------------------------------------------
> For list details, see http://www.magnolia-cms.com/community/mailing-
> lists.html
> Alternatively, use our forums: http://forum.magnolia-cms.com/
> To unsubscribe, E-mail to: <[email protected]>
> ----------------------------------------------------------------



----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------

Reply via email to