Scale required in portal.imageUrl()

Bugs
1

Enonic version: XP 6.0.0-RC2
OS: OSX 10.10.5

Hi.

The new portal.imageUrl() now requires that you give the scale parameter. Too me this is a hassle that I could be without. I know I can use ‘(1,1)’ with parameter to get no scaling but it seems like the logic thing would be that it would default to that if you did not give the scale parameter.

I know this is considered a feature and not a bug, but I disagree. :stuck_out_tongue:
Some of the others at the course on thursday expressed some irritation with this as well.

Are there any spesific reasons that you made the imageUrl function this way?

2 Likes
2

I’m glad the “scale” parameter was separated from the “filter” parameter. But, like you, I was surprised that “scale” is now required. I discovered by accident that {scale: ‘(1,1)’} would render the original. When I mentioned this to my colleagues, Thomas said that “(1,1”) was overlooked and shouldn’t work. I was shocked because there are times when you need the original size image. But when Thomas explained why then I immediately understood.

I worked with a lot of Enonic CMS (4.x) customers and most of the time, when a performance issue came up, it was easily traced back to image handling. These were inevitably customers who didn’t use the STK (“not invented here syndrome” or something) and so they were often scaling huge, original size images for everything instead of using the appropriate pre-scaled image like the STK does. XP won’t have that problem because of much better backend image handling, as long as people make proper use of the scaling functions. So with XP we are learning from past mistakes. The required “scale” parameter prevents people from getting into the bad habit of using original sized images for everything.

The (1,1) scale might be removed, but you can use portal.attachmentUrl() to get the original image. In my opinion, scale (1,1) should remain, but the documentation should warn that this should only be used in certain situations when you are certain that you need the original sized image.

Here is an example of why I think (1,1) should stay. If you had to use a different URL function (attachmentUrl) for the original size image then you couldn’t easily handle situations where you might need different scalings.

var scale;

if(/* test something */) {
    scale = 'wide(300)';
}
else {
    scale = '(1,1)';
}

var image = portal.imageUrl({
    id: conent.id,
    scale: scale
});
1 Like