Some of us do not have the privilege to have curl installed.

Could we use the Gateway class instead ? http://getsymphony.com/learn/api/2.3.1/toolkit/gateway/

Fail check gives false negatives when applying a filter from another folder than /lib (e.g.: from Image Upload).

Line 296 in /lib/class.image.php:

if(is_null($filter) || !is_file("filters/filter.{$filter}.php")) return false;

should be changed to:

if(is_null($filter) || !is_file(EXTENSIONS . "/jit_image_manipulation/lib/filters/filter.{$filter}.php")) return false;

as per http://symphony-cms.com/discuss/thread/38318/

I use the PageSpeed extension in Chrome, and it thinks the images that JIT makes can be further losslessly compressed. Is it possible to integrate that compression? The extension does the compression and offers an example of the compression, so I imagine the extension has compression built into it.

The documentation on the website doesn't contain information about the resize to fit method. It would be helpful to include this.

For some reason my live server is not showing Image Previews:

http://d.pr/f/Sjtf

I Inspected it to find that for some reason on the Live Server the preview src attribute is adding an extra slash and a call to the workspace folder:

Live

<img src="http://atheycreek.com/image/2/40/40/5//workspace/uploads/images/leaderboards/dudes-donuts_web-01-5078b31c6e0e5.jpg">

Local

<img src="http://atheycreek/image/2/40/40/5/uploads/images/leaderboards/dudes-donuts_web-01-5078b31c6e0e5.jpg">

Do you have any idea why this might be or even where I can dig around to see why this is happening?

I wondered why JIT's rewrite rule expects a file suffix for (internal and external) images:

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

On the web, there might be a lot of (e.g. auto-generated) images without any suffix. (Actually I had an issue with a Twitter profile image which had no suffix.) So what about simplifying the rewrite, like so:

RewriteRule ^image\/(.+)$ extensions/jit_image_manipulation/lib/image.php?param=$1 [B,L,NC]

Please don't anybody say that this is a security feature. Think twice, it is not. :-)

JIT states it requires 2.2.x in the backend. It should be 2.3.

This is a bit pedantic: We you enable and disable this extension for a few times, your .htaccess will contain a lot of empty lines separating the JIT rules from the rest. I guess there is just a line break too much in the code ...

### 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]

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



    ### 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]

</IfModule>
######

I use a extension "Redactor RichText Editor",I want to change the "File upload location",but it notice"An error occurred while saving the JIT recipes. Make sure the recipes file, /workspace/jit-image-manipulation/recipes.php, exists and is writable."

where is this file"recipes.php"?

See http://symphony-cms.com/discuss/thread/74805/

I have a link to a JIT mode 1 transparent PNG /image/1/150/0/0/.../logo.png. I noticed the PNG loses it's transparency.

I tracked it to these lines in /lib/class.imagefilter.php

$colour = imagecolorallocatealpha($dst, 0, 0, 0, 127);
imagefill($dst, 0, 0, $colour);

Is there any particular reason for filling the image?

Apparently, installation fails if .htaccess is now writeable by PHP.

I believe that if changing the file fails, an error should be displayed.

jcrop seems bhe be a new easy to handle feauture to resize and crop images.
jcrop seems not to be know at recipe at switch:
https://github.com/bernardodiasc/jit_image_manipulation/blob/jcrop/lib/image.php#L85

and obvious:
https://github.com/symphonycms/jit_image_manipulation/blob/master/lib/image.php#L82

would it be more cositent to add the new mode here too?

I updated my development copy of Symphony from 2.2.5 to 2.3.2beta1. After updating JIT, I now have two problems:

• My local server throws an error: RewriteRule: unknown flag 'B', referer: http://symphony/symphony-2/symphony/system/preferences/
• My .htaccess contains two set of rules, one for Symphony 2.2.5 and one for 2.3.2:

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

<IfModule mod_rewrite.c>

    RewriteEngine on
    RewriteBase /symphony-2/

    ### 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]








    ### IMAGE RULES
    RewriteRule ^image\/(.+\.(jpg|gif|jpeg|png|bmp))$ extensions/jit_image_manipulation/lib/image.php?param=$1 [B,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]

</IfModule>
######
### Symphony 2.3.x ###
Options +FollowSymlinks -Indexes

<IfModule mod_rewrite.c>

    RewriteEngine on
    RewriteBase /symphony-2

    ### 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]





    ### IMAGE RULES
    RewriteRule ^image\/(.+\.(jpg|gif|jpeg|png|bmp))$ extensions/jit_image_manipulation/lib/image.php?param=$1 [B,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]

</IfModule>
######

It's basically all in the title. Will look into this and try to provide a fix...

@brendo, @klaftertief:

Isn't the quality setting completely superfluous in direct display mode? I didn't see any effect when I changed it.

Or is the quality setting supposed to work? (In this case we should file a new issue.)

It would be great if when using the JIT & S3 upload extensions together we could store the cached images directly in the S3 bucket instead of the default manifest/cache dir.

The size math isn't forgiving in this use-case

http://see.weareinto.com/B7q4

The image is too skinny and the right-hand side is getting clipped.

http://sante.elektrobio.de/image/2/214/0/5/0/uploads/news/s_kajaleyeliner08-4e956637669fc.png

Complete image here http://sante.elektrobio.de/image/2/220/0/5/0/uploads/news/s_kajaleyeliner08-4e956637669fc.png

or here http://sante.elektrobio.de/image/0/uploads/news/s_kajaleyeliner08-4e956637669fc.png

I think it's about time we supported this. The functions are available in PHP since v5.

Just wanted to float the idea of dropping localisation for the actual image.php file.

At the moment this is solely used for error reporting, and even then it's pretty lackluster supporting only 'Error generating image' or 'Image not found'. Could this be dropped to make image.php lightweight and just have the errors logged in English?

Localisation would still be used for the Preferences panel and other areas in Symphony, just not in the actual processing of images.

Thoughts?

@carsten, @nilshoerrmann, @eKoEs, @rainerborene

JIT is using cURL to load external images, but it does not follow redirects. Is there any special reason for this?

I suggest to add this and set a maximum of redirects to follow.

If this is considered a desired feature, I can send a pull request.

Thoughts?

The latest integration code renders useful information if a 404 error occurs. That's great in the logfile. But one might argue that revealing the full path of an image in the browser is a small security flaw, because everybody can see where the software (i.e. Symphony) is located in the file system of the server.

So in line 118 of the extension driver we might output the basename of the file instead of the full path.

@brendo: What do you think?

Reminder to myself to ensure that a default timezone is set so that if an error occurs, the Log calls will still work. At the moment if no default timezone is set, the Log class will throw an exception as PHP5.3 will complain about the lack of the timezone. Because this all occurs within an error handler, the result is a white page.

The solution is to load the Configuration file and set the default timezone using this information. I don't anticipate this will cause a negative impact on performance.

Direct display mode has been broken by this commit:

ab18290

Sorry, don't know how to reference the symphonycms/symphonycms#1419 thread

"Disable dynamic URLs and use named recipes only" preference blocks generation of preview thumbs in Symphony's backend section listing, as it uses JIT dynamic URLs parameters.

Added: This topic is to advanced for me to come up with some proper solution (whetever to user some kind of system recipes presets for internal previews or to allow backend to bypass the disabling preference).

Solving it at the JIT's side would mean I guess to spare the need to update all other extensions, on the other hand I am not sure if bypassing such a straightforward disabling preference by doing the opposite way under some condition is a good way.

I guess I can not contribute to this. Also I am not a programmer, but making some slowly steps in that way.

Thank you.

I have a named recipe set up in system preferences, e.g. with the name thumb.

Two situations happen

1. When I create another recipe starting with the same name plus one letter, e.g. thumbs, its rules are ignored in favor of the thumb rules.
2. If I write even a longer name like thumbsuperlong, the image is not found at all, returning a 404 saying Error loading image /workspace/uperlong/my/filesystem/path/to/image.jpg

If I create a sthumb variation name, everything is fine.

Expected
I could have defined recipes with similar names with no interference between each other.

The recipe type is crop to fill (haven't tried others for this behaviour) - don't know if this is significant. But I tested JIT v1.17 and v1.16 for this and its the same.

Can anyone confirm?

Thanks.

(EDIT Some minor typos)

image.php line 194:

$image_path = ($param->external === true ? "http://{$param->file}" : WORKSPACE . "/{$param->file}");

causes JIT to add an http to external images.

this is not as flexible, iI think.

one possibility is to an an external flag with 2, means https, the other is not to add any http prefix. I'll prefer the second one, in oder to use external pictures from all curl possible protocols.

readme indicates it is optional

I think this extension can benefit a lot from our new way of setting the HTTP Status Code.

I am willing to fork and do it if anybody does not see any inconvenience.

@leon13 has hacked JIT (line 178 image.php) to make it work with + in the filenames:

$url = parse_url($_SERVER['REQUEST_URI']);
$bug_image = str_replace('/image/', '', $url['path']);
$param = processParams($bug_image, $settings['image']);

This obviously stops the need for passing a GET param through to JIT, but still requires the htaccess rule.

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

could now be:

RewriteRule ^image\/(.+\.(jpg|gif|jpeg|png|bmp))$ extensions/jit_image_manipulation/lib/image.php [B,L,NC]

$_GET in php is translating the + to a space and therefore it fails in JIT.

On the extensions page, you can not update to the current version of JIT. The error is:

rename(/Users/me/Sites/dev/me/symphony-2/manifest/jit-trusted-sites,/Users/me/Sites/dev/me/symphony-2/workspace/jit-image-manipulation/trusted-sites): No such file or directory

The code for JIT recipes can be found at https://github.com/klaftertief/jit_image_manipulation/tree/recipes.
I'm not sure about the naming of the input elements, so any recommendations from native speakers are welcome.
For each mode there is a separate duplicator template in the preferences. Each mode needs a URL Parameter that identifies a recipe. It's the first part after /image/as a normal string for each mode except the custom recipe, where it needs to be a regular expression. So example values would be thumbnail to map /image/thumbnail/path/to/image.png to a corresponding mode for the regular recipes and /^thumbnail/ for regex recipes, or /^square\/(\d+)\/(.+)/ as URL parameter and 2/$1/$1/5/$2 as the replacement JIT parameter for semi-dynamic regex recipes.

As of GD version 2.0.22 there is simple support for CMYK to RGB conversion on the fly so that older browsers may be able to handle images uploaded with CMYK colourspace.

Is there scope to cater for this in the 3 channel meta check conditional within the extension maybe?

@brendo, @klaftertief:

In the recipes settings, it is possible to define several rules using the same handle. However, only the first of these rules will actually be triggered (of course).

Handles should be forced to be unique.

ob_clean() was added to the renderOutputHeaders method a while back because @jonmifsud was getting images that browsers weren't recognising as valid.

This addition didn't pose any problem for me until now. I've set up a new dev environment using PHP 5.4, and I'm finding that the addition of ob_clean results in the same error @jonmifsud had without it.

Both of the following fix it for me:

• Removing ob_clean()
• Replacing ob_clean() with ob_end_clean()

Hopefully @jonmifsud will find that ob_end_clean() works, too. Having said that, if Symphony/JIT hasn't already added any output to the output buffer, neither of the ob_ calls should be necessary, right?

A comment from the ob_clean PHP page:

Don't use ob_clean() to clear white-space or other unwanted content "accidentally" generated by included files.
Included files should not generate unwanted content in the first place.
If they do, You are doing something wrong, like inserting white-space after "?>" (there should not be a "?>" at the end of PHP files: http://php.net/manual/en/language.basic-syntax.phptags.php ).

This issue is not related to the latest issues. It might be related to some cleanups, or it may as well be rather old: JIT forces server errors if an image is not found.

Try a working URL, then make the image path invalid — the browser will render a white page without any useful header.

need to tag version 1.10 before any more updates are made.

JIT sometimes throws this error:

Fatal error: Call to undefined method Page::renderStatusCode() in [...]\extensions\jit_image_manipulation\lib\image.php on line 290

And when I say sometimes, I litterally mean 'sometimes'. Pressing refresh multiple times results in sometimes rendering the picture, sometimes throwing a 500 internal server error. ini_setting display_errors to on shows this error.

This is one of the most frequent error I do so, nobody is to blame 😄

This path: {$root}/image/2/80/80/5/fff/{image/@path}/{image/filename} should be {$root}/image/2/80/80/5/fff{image/@path}/{image/filename}

Notice the extra / in the current version ? You do not need it, since the path attribute always has it.

I was going through the code to look at adding a resize method that maintains the proportions (aspect ratio) of the original image. I see that this functionality is already in there if you set the height parameter to zero. Definitely worth a mention in the Readme.

Cached images should not be delivered anymore if the original file is gone (because it has been removed).

I am working on this issue. It should work for local and external files alike.

Is it by design that JIT doesn't support the following image modes?

• 2 (resize and crop)
• 3 (crop)
• 4 (resize to fit)

I have a feeling it's related to the removal of file types from the regex in htaccess file.

#75

So there's been previous discussion and gripes about how JIT is quite hard to expand upon at the moment to allow for new modes.

I know there has been some previous discussion about this, so I apologise for not being up to date with the possible solutions that have arisen from those, but I'd like to propose another idea (or it may be the same idea that has been thrown around).

This is what currently happens:

1. Any request that starts with image/gets redirected to /extensions/jit_image_manipulation/lib/image.php for processing
2. This file creates a bit of Symphony stub and then parses the current URL, using the first parameter (an integer) as the mode and the rest of the URL into other properties (such as width/height/path to the file etc)
3. A whole bunch of logic then happens to see if there is a cached file (304's), to see if the file exists etc.
4. Provided a file exists, a switch then determines what filter (inside /lib/filters) needs to be called to generate the (image) resource
5. The resource is saved to cached and then served

What we fortunate to have at the moment is that 4. calls the abstract image's applyFilter function which looks for filters in the filters folder.

What I'd like to do is create a Filter interface, that requires filters to provide at least 3 functions, one that is called at 2, one that is called at 4 and then the actual processing logic.

Developers could then create new filters and drop them into the /filters folder.

Why this is good

• It allows developers to create filters quickly without toying with the .htaccess
• It makes use of what have got (which admittedly is not amazing), and is unlikely to cause any additional problems
• It's in scope for 2.2.2 (release ~ 1 month)
• The image.php class doesn't load the ExtensionManager, so it's difficult to use our usual conventions.

Why this sucks

• It breaks the convention of extensions living in their own folder
• If jit_image_manipulation is added as a submodule, adding filters will not make them track with .git

Thoughts?

@fawx, @designermonkey, @klaftertief, @josephdenne, @nickdunn, @czheng, @allen

After pulling from symphony/integration (2.3 beta) I updated submodules. Version 1.15 of JIT came in. At the extensions page, when selecting it and choosing to update, I got a yellow flash notification:

rename(/srv/www/sym-2-3/webroot/manifest/jit-trusted-sites,/srv/www/sym-2-3/webroot/workspace/jit-image-manipulation/trusted-sites):  No such file or directory

I created a blank manifest/jit-trusted-sites file, tried again - no error notification and a successful update to 1.15.

Is it possible that users upgrading will also not have a manifest/jit-trusted-sites file, and receive the error on extension update?

Not sure why, but after uploading the v1.3 into Symphony 2.4RC2, the update to v1.3 is not indicated at /symphony/system/extensions/.

I uploaded a photo containing a '+' in the filename
When the photo is called through JIT it won't get displayed giving the error:
'Check if file exists and is readable'

See related thread: http://symphony-cms.com/discuss/thread/54567/

Edit: Url encoding the '+' with '%2B' does not make a difference...

Some time ago @klaftertief forked JIT to implement new cropping mode for his super-useful ImageCropper extension. However, two JIT extensions can't live together in one Symphony install, what leads to possible compatibility problems, and i don't think that @klaftertief is still actively maintaining his version of JIT.

In order to better support ImageCropper, is it possible to merge in jCrop cropping mode from @klaftertief repo to the upstream?

upd seems that @bernardodiasc maintaining his fork with jCrop included in actual state

As in the title – nothing is saved but I get a Preferences saved message.