Symphony.

Hi guys, i m a bit lost in the JIT...

I m looking for the post processing function to add watermarks to the images, i tried the custom branch but the interface is not the same as the recipe branch. I can't add new rules to create multiple watermarks, its not the same interface in preferences as the recipe branch...

Where should i go to find what i saw in the impressive screenr ? with this interface: http://downloads.getsymphony.com/global-asset-download/file/61859/screen-capture-2.png/

Thank you so much for all the awesome new features for JIT your are developing!

Hi Vincent,

I believe you are referring to my old custom rules branch. This is only working in the 2.1.* versions of Symphony. You could try to back-port changes I did in the recipes branch, mainly in the markup and JS for the duplicator.

I m using symphony 2.2.1. Ok i ll try to compare the code, thank you for your quick answer.

Can anyone tell me if JIT still processes images which are already sized at the specified image dimensions? In order to minimise compression and server load I currently use this long-winded code to display the image unprocessed if it is already correctly sized.

I'm not sure if it's necessary or not. Thanks

<xsl:choose>
<xsl:when test="(image/meta/@width != 95) and (image/meta/@height != 106)">
     <img src="{$root}/image/2/95/106/5{image/@path}/{image/filename}" alt="{name}" />
</xsl:when>
<xsl:otherwise>
     <img src="{$workspace}{image/@path}/{image/filename}" alt="{name}" />
</xsl:otherwise>
</xsl:choose>

Can anyone tell me if JIT still processes images which are already sized at the specified image dimensions

I believe it does. It does not first check if the source image already matches the desired output dimensions.

Thanks :-)

I believe you are referring to my old custom rules branch. This is only working in the 2.1.* versions of Symphony. You could try to back-port changes I did in the recipes branch, mainly in the markup and JS for the duplicator.

I'm a bit confused: Is there an official branch containing the recipes or is this feature just in your custom branch, Jonas?

It's currently in Jonas's custom branch, but we hope to flesh it out further and include it in JIT for 2.3.

It's currently in Jonas's custom branch, but we hope to flesh it out further and include it in JIT for 2.3.

Yep.

My custom rules branch is a version for Symphony 2.1 and contains watermarking functionality. My recipes branch is the developing branch for recipes for Symphony > 2.2. Maybe we should add the branch to the official JIT repository to have a central place for development. Brendan? I'll probably find some time to work on it again in the second half of september.

second half of september

Ooo, just in time for Symposium!

(you see what I did there, right?)

I saw this today, adaptive images which works kind of like JIT, worth a look ...

@Fazal I've looked into it too. Seems a nice way to deal with the 'Responsive Images Problem'. I immediately thought of Symphony :)

The 'adaptive images' technique makes use of cookies. Maybe one could fork JIT and create a cool Symphony Adaptive Images extension?

If you like to have adaptive images, you have two simple ways to achieve this using Symphony and this extension:

• Detect the current viewport and simply change the JIT image URL settings via JavaScript
• Store the viewport in a cookie using JavaScript (as in the mentioned technique) and use Cookie Monster to use this value when building your image URLs.

Sounds like this needs a new thread ;-)

(@nickdunn Correct me if I'm wrong but discussing a change of/addition to JIT should be done in this thread, no?)

Could JIT not be slightly changed to include src.sencha.io like functionality? Combined with a caching/cookie solution (like Adaptive Images) this would give Symphony a really nice out-of-the-box solution for images in a 'responsive context'.

To me (as a PHP/Symphony layman) it looks like 80% of the functionality is already in JIT. What would be needed in addition to the scaling is a way to detect 'max size' (based on device-detection or viewport width) automatically.

Maybe this could even be a separate extension that depends on/works with JIT?

David, can you explain to me which functionality you think is missing at the moment?

• JIT can resize images based on URL parameters.
• You can detect the current screen size using window.innerWidth inside your JavaScript (or .width() if you're using jQuery).
• You can dynamically change the URL of your images using JavaScript, if you detect a mobile device or a resized window.

In my eyes, this is front-end JavaScript problem, that should be solved for each site individually.

@Nils.

Besides some niceties in Sencha.io Src such as 'Formulaic and Percentage sizing' and Data URI's etc. it is the automatic (screen) size detection on the server that I am most interested in.

One of the difficulties in working with images in a 'responsive context' is the fact that one would rather not 'just use the largest images' and scale them down on mobile etc. We would like to provide each environment with the optimal image re: both filesize and size.

A JS solution such as you describe has a few disadvantages (if I understand you correctly):

• dependency on JS (and the correct loading thereof)
• rewriting the img.src with JS does not prevent all devices to download large desktop-centric images
• Lack of caching. Extra http request. etc.

I disagree that this is a 'front-end' problem. If it was you would have to decide to use a JS solution for most scenario's that JIT handles today. JIT can (and should) scale and cache site images (thankfully).

Delivering proper, suitable, images for various screen-sizes and devices could very well be a JIT (back-end) responsability and handling this on the back-end has a lot of benefits re: device-detection, caching, http requests etc.

dependency on JS (and the correct loading thereof)

The current window size always depends on the client side. So you will always need JavaScript to store the current size and to fetch window resizing. There isn't a "server-side only" solution.

If we are talking about mobile devices, there is the Mobile Device Detection extension that returns the current device name and OS version. Based on this you could adjust your JIT URLs inside your XSL template with a simple choose statement. We don't have to adjust JIT for this use case.

rewriting the img.src with JS does not prevent all devices to download large desktop-centric images

That's true, but you could default to the small sizes and switch to the larger ones when the DOM is ready.

If you like to follow the Adaptive Images way, you could store the current size in a cookie (again using JavaScript) and get the value with the Cookie Monster extension which allows you to set the correct image size in your XSL templates again. Again, no need to change the current JIT implementation.

Lack of caching. Extra http request. etc.

Why shouldn't the images been cached?

Hi guys, new to Symphony, enjoying it a lot :)

Coming from MODx I miss one, quite essential feature in JIT, changing image format and quality (compression). My customers tend to upload uncompressed PNGs; I even had problem with one of them uploading huge BMP.

While JIT can resize and cache images without a hassle I haven't noticed ability to turn uploaded images into 80% quality JPEGs.

Am I missing something?

If not, I'd like to propose it as a feature. As far as I can tell, GD supports that: http://www.php.net/manual/en/function.imagejpeg.php

Welcome :-)

haven't noticed ability to turn uploaded images into 80% quality JPEGs.

There's an option in the Symphony config file to change this. Take a look in/manifest/config.php for a quality setting under the JIT group.