Custom loader

[leesherwood]

It would be good if we could override the built in image loader with one of our own. I have tried for 2 days now to somehow bridge this plugin with the flysystem plugin so that i have the power of this library with the extensibility of the filesystem plugin so i can switch my image store between local folders (for dev) and AWS S3 (for production).

I've tried to register my own service provider for this class, to somehow provide my own image loader class (probably a custom resolver class instead of just a loader as i'd want full control over any filesystem functions). However as of yet i've failed to get anywhere with that route, i may just be trying to achieve the impossible

[iwyg]

This is kind of on my todo list (for reference: laravel-image)

However you may have a look at the the ImageSourceLoader and the ImageCache classes. This is where fileaccess happens.

[leesherwood]

Guess i'll just fork your repo and have a go at doing it myself. I'm still fairly new to laravel and don't really have a good handle on how your classes all integrate together so i'll probably end up doing it incorrectly or not inline with how you would do it yourself, but if i can get it working for myself for now i can at least get on with my stuff.

I'm imagining simply abstracting any of your filesystem related stuff (which you have probably already done anyway), and just allowing 3rd parties to extend that class somehow (config, IOC, ???, not sure but google will tell me im sure). Then you'd just be able to create adapters.

[iwyg]

You could create your own ServiceProvider and and override the imagecache (see https://github.com/iwyg/jitimage/blob/master/src/Thapp/JitImage/JitImageServiceProvider.php#L90)

$app->bind(
    'Thapp\JitImage\Cache\CacheInterface', 
    'Your\OwnCacheInterfaceImplementation'
);

and also override the sourceloader (see https://github.com/iwyg/jitimage/blob/master/src/Thapp/JitImage/JitImageServiceProvider.php#L105)

$app->bind(
    'Thapp\JitImage\Driver\SourceLoaderInterface', 
    'Your\OwnSourceLoaderInterfaceImplementation'
);

[leesherwood]

I did try to NOT register your service provider, and just created a service provider class of my own in the /app/ directory, which extends your service provider and registered that class instead (which if it worked, would have let me start editing the provider as your suggested). However the custom service provider seemed to fail getting any config vars, ( $config->get('jitimage::driver', 'gd') returns an empty array for example).

So im guessing i'll have to fork your repo still and edit the service provider in my own copy of the repo rather than trying to "extend" yours.

[iwyg]

Doesn't matter actually as long as you override the SourceLoaderInterface and CacheInterface implementations.

[leesherwood]

The ResolverInterface too from what i can tell.

Just trying to work out if i can somehow provide a way of specifying the implementation elsewhere. So instead of the Service Provider binding the resolver, there would be a way of providing a resolver to use from outside of the package. Currently i'm thinking the IOC would be the only way to do that, but then you'd have to create a SP to register the resolver, loader and cache i think.

Maybe i'm running before i can walk with this. Might just stick with editing the source files and maintain my own copy of the repo until you have chance to do things the proper way.

[iwyg]

Right, the isReadableFile could be a showstopper here.

Have a look at the https://github.com/AndreasHeiberg/laravel-image package. It uses the https://github.com/thephpleague/flysystem drivers that support a bunch of CDNs including AWS.

[abhimanyu003]

+1 to suggested feature

[tomc3]

Any news or guide on integrating this package with flysystem. It will be really great if there is possibility to store images and cache on s3

[iwyg]

Maybe for the next major version.

[tomc3]

Thanks for information, any estimate time. I really like you package.

[iwyg]

v0.2.x will be available soon and will include:

• multiple routes and base paths
• different loading strategies including support for custom loaders
• different caching strategies including support for custom caches
• value constraints for dynamic processing.

The package will be split into the actual jitimage package and a stand-alone image processing library. I'll probably provide a laravel wrapper for the processing library as well. This is useful if you need image processing without the need of the jitimage stuff. How about an image processing queue worker?

[iwyg]

@see #45