Symphony.

Thank you Nick. I’m kinda noob in “non-basic” coding so I’m sorry for the eventual dumb questions. Anyway, I’ll take a deep look on that link!

Just a quick notice about my implementation of custom regex based JIT rules. Still needs a bit of work, so I would be happy to get some feedback. I’ve only tested it on 2.1.2, the preferences will probably look a bit buggy on 2.2.

Attachments:

screen-capture-2.png

Awesome work, how would it b implemented in an xsl file then?

Create an image element as normal, with the @src attribute that matches one of your custom rules. You can still have dynamic parts, when you set up the regex this way. Have a look at the quick screen-cast, it should make it clearer.

The custom rules support

• custom per rule quality
• watermarking, with custom position (1-9) and opacity (buggy with alpha transparency)
• disabling of regular JIT rules

This is really cool! Will this eventually be pushed into the main repository?

This is exactly what I was going to propose for Symphony 3, but you beat me to it! Masking the resize dimensions with a handle is much more secure and makes more sense. I thought about just storing them in an XML file, but it’s great to have a UI to create them too. We sometimes use a thumbnail script from one of our clients which refers to each of these rules as “recipes”, which I think is a nice term.

This is really cool! Will this eventually be pushed into the main repository?

I wouldn’t merge it like that. This branch has three changes:

• custom rules
• watermarking
• new mode for cropping (from my jCrop branch)

The implementation of the custom rules is pretty straight forward. It is just a pre-processing (heavily inspired by Robs URL Router extension) of the image path before the normal processing and could be merged with the main branch.

Watermarking is post-processing of the generated image. I don’t like this being hardcoded, because you will find other needs in like masking, changing the color etc. What about a delegate for post-processing?

The same is true for other modes. It would be cool to be able to add more modes via extensions without forking JIT.

Should I strip down the changes to just include the pre-processing part and send a pull-request? What are your thoughts?

I vote for it. The pre-processing part is really cool, and it makes sense for everybody.

Brilliant work, Jonas.

I agree with the overall sentiment here. We should look at getting the preprocessing/rules into the main JIT extension, and add a delegate for extensions to do custom post-processing.

Here is a stripped down "recipes" version of JIT, compatible with Symphony 2.2:

https://github.com/klaftertief/jit_image_manipulation/tree/recipes

It doesn't add any modes or post-processing functionality. You can only define from- and to-values and set a per-recipe quality. Should this go into Symphony 2.2.1?

Because JIT doesn't know Symphony, we can't use delegates to add or modify JITs toolkit, and we probably don't want to use delegates, because they add DB queries.

So what would be a good way to extend JIT? For post-processing, we could go the XML Importer way and support custom PHP functions (both directly in an extra text input element or saved in e.g. lib/class.imagehelpers.php). But what about extra modes? They are much more integrated.

What other modes can you think there may be a requirement for? I can't think of any myself.

I think you've done some excellent work here dude, masking the actual transformations is a really good idea.

There is Joseph's fork for with a rotate mode and my own one for the image cropper extension. But both could be implemented as post-processing rules as well (with the rotation probably being a better fit). In general (thinking out loud), a mode is everything you would want to be dynamic/user definable (with boundaries) and post-processing is something you want to be fixed/discreet.

I am having an issue with accessing an external image with/through JIT running Symphony 2.2 and Alistair's JIT 1.09 (default) on a local site.dev domain.

I have both added site2.dev* and * as Trusted Sites to site1.dev's Preferences (which works since removing it results in a 'not permitted' warning).

When I try to access an image on site2.dev with..

http://site1.dev/image/1/80/0/1/http://site2.dev/workspace/media/images/dummyimage.png

.. I get a blank page. The following PHP error shows up in my PHP error log:

PHP Fatal error:  Undefined class constant 'ERROR' in /my/site/site/extensions/jit_image_manipulation/lib/image.php on line 89

Accessing an image locally through JIT works fine. Any ideas on this Undefined class constant 'ERROR' and why retrieving the external image does not work?

UPDATE

I've been able to get some more error info by echo-ing the $errno (82) and $errstr params manually:

Trying to get property of non-objectCannot modify header information - headers already sent by (output started at /my/site/extensions/jit_image_manipulation/lib/image.php:84)

.. maybe this is of some use?

Pretty sure you can't include the additional http:// in your URLs:

http://site1.dev/image/1/80/0/1/http://site2.dev/workspace/media/images/dummyimage.png

Should be:

http://site1.dev/image/1/80/0/1/site2.dev/workspace/media/images/dummyimage.png

That was it… I can't believe it was something simple as that!

It's actually mentioned in the docs for the path param: (excluding http://)

(This c|should have been handled more gracefully though…)

Thanks!

It seems JIT has not been updated to work with 2.2 yet.

For instance, the filemtime function sometimes fails on my installation (windows) causing the extension to break. This did not happen in the past because of the @ sign before the filemtime function.

For some reason, if I reset the error handler by using restore_error_handler();, it works as expected (except of the lost logging)..

Does anyone have any idea why prepending a function by @ doesn't work anymore?

EDIT: I should read the documentation before asking.

I'm still having difficulty getting JIT to handle alpha transparent PNGs. Is anyone else having this problem?

I'm using the latest version, 1.0.9, along with Symphony 2.1.2.

Anyone have any solutions for handling transparent PNGs with the current version of JIT? Is anyone else having the problem that it is ignoring the alpha transparency of PNGs???

Is anyone else having the problem that it is ignoring the alpha transparency of PNGs???

In Symphony 2.2 (JIT 1.09) alpha transparency is preserved for me.

When I initially tested, I thought the transparent portions had been replaced with opaque white, but it turned out my test page had a background colour applied to images. Don't suppose this is the problem?

Is anyone else having the problem that it is ignoring the alpha transparency of PNGs???

I had the problem on some sites and this change fixed it for me.