Symphony.

I'm currently working on an 'official' fix for the transparency issues we all notice, and I've come across something quite odd.

Has anyone else noticed that all transparent GIFs are coloured black when using JIT?

It seems it's not just PNGs that are suffering.

Is the consensus that this should be fixed too?

@designermonkey, your pull requested has been merged into the integration branch.

Extension developers, your thoughts are wanted!

i'm not sure if this is the proper channel to go through for issues regarding unreleased branches, but i went ahead and logged it anyway. did we have a change of heart regarding the optional background color for mode 2?

From what I can see in my tent, the code still works. Obviously I'm looking from my crystal iBall so may be wrong...

I've implemented a feature for you to test: JIT recipes. Some of you might have seen slightly different versions before, but this should roughly be the final implementation. Happy testing.

Woohoo! I have been looking forward to playing with this. Thanks Jonas :-)

A woo-girl! ;-)

Any way to incorporate jCrop?
I want to push an update to imageizer.com :)

I have a jCrop branch for the Image Cropper extension. It's not really up to date with the latest JIT changes, but it's just a matter of merging them.

Hi,

I have been trying to get this extension to work but haven't been able to.

I have tried constructing the image path for the image below:

http://smluniverse.com/workspace/images/photobg.jpg

Based on the documentation, I constructed this URL:

http://smluniverse.com/image/1/200/0/images/photobg.jpg

But as you can see, it doesn't return anything. Why is that???

Also of interest, I tried to trigger the 'default: direct display' mode using this URL: http://smluniverse.com/image/1/images/photobg.jpg and very strangely I received an error: "Error: Connecting to that external site is not permitted." But this is the same site...

In your original image url you have workspace. If your image is stored in the workspace folder, you still need that part of the url:

http://smluniverse.com/image/1/200/0/workspace/images/photobg.jpg

Tried the above and get an error.

Next thing is what version of symphony are you running and what version of JIT?

Also what does your htaccess file look like? JIT has a rule in the htaccess to manipulate the url for resizing.

See the git link for JIT README explanation of JIT htaccess rule and check it matches what you have.

github/jitimagemanipulation

In your original image url you have workspace. If your image is stored in the workspace folder, you still need that part of the url:

I thought that the workspace path was already assumed and it shouldn't be in your path?

Make sure the cache folder is writable by PHP, first try 755 on the permissions, failing that 775 should work. If it doesn't that at least strikes this of the list of possible problems...

@designermonkey is the workspace path taken into account always then? every time I've tried to construct a url inside the workspace/images folder, I needed to have "workspace" in the url to use the JIT manipulation?

At last use, JIT looks for images within your workspace folder, so the path in the URL doesn't need to include the leading "workspace" bit.

I may be wrong, it's been a long day ;)

EDIT: Nick beat me to it...

Gotcha.

Symphony Version: 2.2.1

JIT Version: 1.10

All these folders set to 775:

/extensions
/manifest
/manifest/cache
/manifest/logs
/manifest/tmp
/symphony
/workspace

My .htaccess settings (where the ##IMAGE RULES appears to be the same as the JIT readme)

### Symphony 2.2.x ###
Options +FollowSymlinks -Indexes

<IfModule mod_rewrite.c>

    RewriteEngine on
    RewriteBase /

    ### SECURITY - Protect crucial files
    RewriteRule ^manifest/(.*)$ - [F]
    RewriteRule ^workspace/utilities/(.*).xsl$ - [F]
    RewriteRule ^workspace/pages/(.*).xsl$ - [F]
    RewriteRule ^(.*).sql$ - [F]
    RewriteRule (^|/). - [F]

    ### DO NOT APPLY RULES WHEN REQUESTING "favicon.ico"
    RewriteCond %{REQUEST_FILENAME} favicon.ico [NC]
    RewriteRule .* - [S=14]

    ### START RESOLVR RULES
    RewriteRule ^resolvr/((.*/?))?$ //extensions/media_resolvr/lib/resolvr.php?url=$1&%{QUERY_STRING}  [NC,L]
    ### END RESOLVR RULES

    ### IMAGE RULES
    RewriteRule ^image/(.+.(jpg|gif|jpeg|png|bmp))$ extensions/jit_image_manipulation/lib/image.php?param=$1 [L,NC]



    ### CHECK FOR TRAILING SLASH - Will ignore files
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_URI} !/$
    RewriteCond %{REQUEST_URI} !(.*)/$
    RewriteRule ^(.*)$ $1/ [L,R=301]

    ### URL Correction
    RewriteRule ^(symphony/)?index.php(/.*/?) $1$2 [NC]

    ### ADMIN REWRITE
    RewriteRule ^symphony/?$ index.php?mode=administration&%{QUERY_STRING} [NC,L]

    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^symphony(/(.*/?))?$ index.php?symphony-page=$1&mode=administration&%{QUERY_STRING}   [NC,L]

    ### FRONTEND REWRITE - Will ignore files and folders
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*/?)$ index.php?symphony-page=$1&%{QUERY_STRING}    [L]

        ### ADD LOG (SML)
</IfModule>
######

Noticed you have resolvr rules in there. Have you tried disabling resolvr extension to see if there is a conflict?

@seeminglee:

But as you can see, it doesn't return anything. Why is that???

The URL returns a 500 error. Try enabling PHP errors in your htaccess file and you'll see a more descriptive error:

php_flag display_errors 1

@klaftertief:

I've implemented a feature for you to test: JIT recipes. Some of you might have seen slightly different versions before, but this should roughly be the final implementation. Happy testing.

This works really well! I have some comments:

• It took me a while to figure out what "URL Parameter" meant. I think perhaps "Recipe name" might make more sense. And if a user enters "My Recipe" then it auto-handlises it to "my-recipe" on save.
• There isn't any validation of required fields in the duplicator. I know this is quite a fiddly thing to implement so you probably left it out. It's not a major problem, but wanted to raise it in case you knew of an easy way of implementing it.
• I think there's now a three-column layout for duplicators (although I can't remember where I saw it). It might be useful to reduce the size of input elements when they are very wide (50%) but accept only a short value (e.g. "Width").
• The duplicator is orderable. Does it need to be?
• I didn't understand the difference between "Direct display" and "Custom" since the duplicator options are identical.
• The checkbox label "Check this field if you want to allow only custom JIT rules" is a little misleading when there is a "Custom" rule in the duplicator. Maybe it should say "Disable dynamic JIT URLs and use named recipes only" or similar?

This is very, very cool though. I've started a prototype of an extension that processes images through recipes as you upload them to entries. This means they can be pushed up to Amazon S3 immediately without a need to serve images through JIT to the user at all.

Thanks for testing, Nick. Some answers:

It took me a while to figure out what "URL Parameter" meant. I think perhaps "Recipe name" might make more sense. And if a user enters "My Recipe" then it auto-handlises it to "my-recipe" on save.

I'm not sure or happy about the naming, either. I wanted to have the same name for the traditional and the custom regex recipes. All map an incoming URL/paramter to something different. Some kind of help text would be useful, but then the template would have even more elements.

There isn't any validation of required fields in the duplicator. I know this is quite a fiddly thing to implement so you probably left it out. It's not a major problem, but wanted to raise it in case you knew of an easy way of implementing it.

Yep, I started working on validation at some earlier version, but stopped because it's not really supported and AFAIK there is no validation in any of the existing preferences.

I think there's now a three-column layout for duplicators (although I can't remember where I saw it). It might be useful to reduce the size of input elements when they are very wide (50%) but accept only a short value (e.g. "Width").

I think it's a general backend layout option triggered with .group.triple. I wanted to have the fields on consistent positions and avoid template code duplication. I'll have a look and see if the same can be achieved with a three column layout.

The duplicator is orderable. Does it need to be?

The first matched recipe wins (top from bottom). The matching logic is either a regex for custom recipes or a check if the incoming JIT URL starts with given value of the URL Parameter field. So more specific rules at the top don't block more general rules further down, but the other way around. E.g. thumbnail at the top blocks thumbnail-square because it matches both.

I didn't understand the difference between "Direct display" and "Custom" since the duplicator options are identical.

That's a bug, introduced by trying to be DRY or too clever :-)

The checkbox label "Check this field if you want to allow only custom JIT rules" is a little misleading when there is a "Custom" rule in the duplicator. Maybe it should say "Disable dynamic JIT URLs and use named recipes only" or similar?

Sounds better. I'm not a word magician and happy to change it.

This is very, very cool though. I've started a prototype of an extension that processes images through recipes as you upload them to entries. This means they can be pushed up to Amazon S3 immediately without a need to serve images through JIT to the user at all.

Nice. I had the idea to let the recipes call a script (named like the recipe, in a special folder) to allow post-processing of the images. This would be a way to add functionality to JIT (like b&w filters or watermarks) without too many changes.