This is fantastic news Jordan, Piknik is not the most intuitive.
I think this is something that would help lots of us.
I am going to grab a copy later on and test it out on my dev site.
I am no coder but I am more than happy to help you test it from a users point of view.

Alex

Edit: Could not wait so got a copy, do you want feed back via PM?

Thanks Alex,
Yes, please by all means grab a copy (again, it can be downloaded from the link above without you having to install git or sign up for a github account).

All feedback is welcome, even if you're not a developer (it would be great to hear everyone's ideas as end-users as well).

This is neat. I do personally use picnik and it works for me - but I only ever use it for cropping and resizing. A lighter weight solution would be nice. I believe with concrete5's file type library you could even package this up and have it available as a download, and someone could install it without even touching code.

--
Andrew Embler
CTO concrete5
http://about.me/aembler

It's already a package that can be installed just like any other. It's currently on github so that developers who want to help with the code can do so easily. But you can also just download the files from there and install it on your site without touching code (installation instructions are on that page, you just need to scroll down a bit).

Once it's finished and tested, it's definitely going on the marketplace.

Not sure I understand what you mean about the file type library -- could you explain that in a little more detail?

Thanks.

-Jordan

You should be able to extend the image file type to use your editor instead of the built-in one through the use a concrete5 event, which would make it so that you wouldn't have to tell people they had to copy the file as part of the installation instructions. Something like adding on_start() to your package, and then this:


$ft = FileTypeList::getInstance();
$ft->define('jpg,jpeg,jpe', t('JPEG'), FileType::T_IMAGE, 'image', 'image', 'image', 'c5_image_cropper');
$ft->define('gif', t('GIF'), FileType::T_IMAGE, 'image', 'image', 'image', 'c5_image_cropper');
$ft->define('png', t('PNG'), FileType::T_IMAGE, 'image', 'image', 'image', 'c5_image_cropper');

This would make the editor for all JPEGs PNGs and GIFs on your site your own editor instead of the built-in picnik one. At least that's the goal with this type of code :) It's a little experimental though, even though it's been in the core for awhile. Not too many people using that functionality.

That is good to know and I will try it out -- if it works it's a much less hacky solution than what I've got (basically rewriting the menu javascript that's outputted by ccm.filemanager.js). Also hopefully that saves me from having to manually refresh the file manager list upon completion of operation (and manually updating the image control in a block edit form -- which I was dreading having to figure out!).

But I'm not sure I understand your concern with "copying the file" -- there is no copying of files -- just download the folder, rename it (because github gives it a crazy sha1 hash name), and drop it into your packages directory. When it's on the marketplace, of course, no renaming or anything like that will be needed.

Hey Jordan,
Great addon to have. Every time my client has had to use Picnik it's because they needed to resize/crop and image.

My only comment is that it would be nice to Name the "new" image you create, instead of editing the properties once you've created it.

Look forward to using it when available

D!!

Thanks for the feedback.
I hadn't thought about allowing the name to be set. I'm trying to keep the interface as sparse as possible. I'm even wondering if I should have that "overwrite" checkbox -- maybe just every time you save the image it replaces the one already there. If you make a mistake, you can always roll back the file to its prior version. If you need 2 different versions of the file you would just have to duplicate it first.

I guess it depends on the use case -- in my mind I imagine a client who is uploading 3MB JPG's (4800x3200 pixels or something ridiculous like that) from their camera, and I need to be able to give them easy-to-understand instructions, like "after upload, click the thumbnail, choose edit, type '600' into the width box, and click 'Save'".

But it sounds like perhaps you have a different use case in mind -- perhaps you or the client wants to be able to use both the larger and the smaller image in different situations? Please explain more as I don't want to assume what's in my head is going to work for everybody.

Thanks!

-Jordan

Hi. does this work in the latest C5?

i keep having problems with my clients uploading stupidly huge images.

my galleries do automatically crop / resize but there comes a point where the page will break as the server will run out of memory if the client adds to many images that all need to be resized. I already have the server memory allowance set very high!

The default C5 file manager image edit tool is not working with my huge images. i dont think it can crop images over 2000px wide? so this is not helping me.

I've used pickmonkey but its super slow... especially when you have a lot of images that need processing.

so i've been searching for a more light weight way of resizing images. I've even looked into ways of automatically resizing the images on upload but found that others have not got very far with that.

so i was just hoping that this thread might have the answer? even though its old :)

Hi,
I abandoned this a long time ago. But I've had some success implementing the "automatically resize images larger than x/y upon upload" solution (as discussed here:http://www.concrete5.org/community/forums/customizing_c5/automatic-... ). It's not very automatic because you need to install a command-line program (ImageMagick) on your server, which may or may not be feasible (or it may already be installed, which would make life easier -- just totally depends on your web hosting company -- contact their tech support to ask if you're unsure).

Best of luck,
Jordan

ah yes I've come across that thread b4

hmm i will have to research how to install image magic on my virtual server.

Architecturally I think I would modify the solution to override both the image helper and the importer.

That way, the 'new' importer can call the 'new' image helper, and the image helper can then:

- see if image magick is available as a php module

- or see if image magick is installed and available via exec

(and maybe cache the results of the above tests in the Config table)

- for resizing of images over a certain size, use image magick in preference to the built in php/gd according to availability.