CroppableImage

[KentBrockman]

noodles and I got this running!

Our scenario was a ProcessWire 2.7.x version we upgraded to ProcessWire 3.0.7. 

Uploads would stop at 100% and not finish. The JavaScript console showed the message jacmaes mentioned above. 

What did we do?

1. We changed all fields of type "CroppableImage" back to "Image" and deleted the module, including the files in /site/assets/cache/FileCompiler/site/modules/CroppableImage.
2. When we reinstalled the module, we were able to upload files successfully and the previously set thumbnails were created by the module! Everything seemed to work to this point, but cropping didn't work, due to missing processes and routes. The page created within the ___install routine of the module wasn't created!(https://github.com/horst-n/CroppableImage/blob/master/ProcessCroppableImage/ProcessCroppableImage.module#L306) 
3. We created it ourself within the admin.php file (dirty, we know - see code below), as a child of /admin/pages, edited and assigned the Process (ProcessCroppableImage) in the given select box within ProcessWire.

Et voilà, it works!

Dirty workaround we used within the admin.php file as a superuser:

$p = new Page();
$p->template = $this->templates->get("admin");
$p->parent = $this->pages->get(3);
$p->title = 'Croppable Images - PW3';
$p->name = 'croppable-image';
$p->addStatus(Page::statusHidden);  
$p->save();

 

This for sure is dirty, but it will give us all a little more time.

We will try to provide a good fix/workaround to make upgrades possible without following the steps above by hand.

[ceberlin]

Hi Horst, a quick question to the roadmap: is this module still maintained or do I need start looking for an alternative?

In PW 3.x I have the problem that, if I change the crop later, it is reflected in the preview but the frontend image does not always update to the new cropped version.

(If I am the only one having this it could be also a misconfiguration or rights problem?)

[horst]

Some of you may have read about it: there are a new core images field in the works for the PW 3 branch. I want to wait until this is released and then update the Croppableimages to sit upon that. I think it will become a new version for PW 3+ only, as there is the current version available for the PW 2 branch.

Besides some PW 3 namespace issues there should be implemented changes to work with the new images field in that way, that it only enhances this with the cropbuttons but leave the other UI as is (reuse it). I'm not very good with this UI stuff, so, if I will not be able to do this myself, I will ask here for help on that. If this will be the case, I will provide an intermediate version that works with the PW3 and new image field first.

Everyone who can't wait until then should use the slightly hacky upgrade procedure provided by @KentBrockmann and @noodles, two posts above this one.

[Peter Knight]

 I want to wait until this is released and then update the Croppableimages to sit upon that. I think it will become a new version for PW 3+ only, as there is the current version available for the PW 2 branch.

I'm looking forward to both the new Images field and the new version of CroppableImage.

I got a little over-ethusiastic about V3 on a few sites and upgraded without checking compatibility. Made me realise the Croppable is probably one of my essential Modules.

Thanks for the update anyway horst.

[Peter Knight]

Horst - is this what you were waiting for? New image fields just announced by Ryan. 
https://processwire.com/talk/topic/13215-pw-3017-major-upgrades-to-images-field/

[horst]

Hey, you impatient PW users,

here is a intermediate version for the current PW 3.0.17 devns branch. It is only available in the Github PW3-Tree. (you need to upload and install manually)

Attention: Please first install the InputfieldRangeSlider module. It is required for the new version!

The module now sits upon the new core Imagefield and provide a few more configsettings as the PW 2 version:

• disable enable the core image editor (default: disabled)
   
• should Imagenames be displayed by default (default: off)
   
• should Thumbnails be displayed complete, not a cropped square (default: off)
   
• style settings (color and transparency) for Thumbbackgrounds
   
• max char number for Imagebasenames (please adjust according to the length of your GridSize) (default: 15)
   
• globally disable the individual selection for Quality and Sharpening, instaed use the ImageSizerEngines defaults or define globally static defaults

In the Inputfield itself, you are able to toggle displaying the Imagenames and how the Thumbnails are displayed: cover or contain. There is also a textinput for filtering by basenames.

Screens:

[ceberlin]

This is SOOO cool - thank you Horst!!!!!!

If the module was previously installed (old version with PW2.x) - can I just continue using it (with PW3.x) or are special steps needed/recommended now to update to the beta? (My first impression was it works right away but I am still testing.)

[horst]

I haven't tested it this way, but I think you will be on the save side with updateting an existing site when you follow this path:

• If missing, install the RangeSlider module
   
• delete the whole croppableimages directory under site/modules
   
• copy the new one into site/modules, (DO NOT SIMPLY COPY IT OVER THE OLD ONE, or AT LEAST MAKE SURE THAT THE FOLLOWING FILES ARE NOT PRESENT THERE **)
   
• clear caches for modules and the file compiler
   
• update your site/config.php with the settings for adminThumbOptions (it needs at least one setting for 'gridSize', I prefer 160 over the new default of 130)
   
• open the module config page and select your setup

**) have a look into site/modules/CroppableImage/InputfieldCroppableImage

and delete the InputfieldCroppableImage.js and InputfieldCroppableImage.css if they exists.

The PW 3 intermediate Version doesn't use this files atm. It uses InputfieldImage.js/css and InputfieldCroppableImageMan.css/js

[ceberlin]

Thanks a lot again, Horst. Looks like the update created no problem. During the process I run into an Exception after hitting "Update Modules". But clearing the compiler cache files another time and hitting "Update Modules" again, fixed it. 

I have something funny because I use the cropped image to resize it further with PW. Here's what I tried

1.  I change the crop and save the page
2.  I check with FTP that a new cropped version is saved that looks like I want it
3. In my code I work with that image as source for further manipulation, like so:
   $img_medium = $child->keyvisual->getCrop('header_thumb')->width(767, array( 'upscaling' => false, 'cropping' => false, 'quality' => 70 ) );
4. Expected behavior: those get updated too.
5. Current behavior: No change to the images (PW does not detect them as changes and to be redrawn)
6. I delete those variants manually with FTP to force a redraw - PW redraws them correctly now

Is this an issue to report for PW or is this something with the module so PW3 does not know about the change?

[horst]

If there are image variations present, you need to add a 'forceNew' => true to your options array.
But this shouldn't stay always in your code. So, you need to find a way to manually or half-automated set a flag if the following derivatives should be recreated or not, I think.

[ceberlin]

Interesting. Did not know about forceNew although it's in the core for a year already. Thank you for the hint. Very useful for spring cleanings.

To add an automated approach I could try to find all variants and see if any of their dates are older than the one of the master image. In each template where the image occurs. Is it this what you mean? I am just worried of the overhead and it makes the implementation of variants of cropped images  in templates more complicated.

Isn't it a much easier and newbie friendly approach to just have the module remove existing variants (if any) on saving if the crop, so PW simply can recreate them if and where needed? (If that helps: the old module version / PW2 worked flawlessly already with those recreations, no further action needed.)

[horst]

Ok, if this has worked with PW 2, there is something broken / has changed. I put this on the bug list! But atm there is not much time I can spent on it.

[ceberlin]

By the way, for anyone interested: For an aforementioned spring cleaning there is a little module existing already (credits to Horst and tpr):

https://processwire.com/talk/topic/261-where-to-set-image-resizing-quality-and-how-to-re-resize-images/page-2

Update:
A WARNING: Right now, that spring cleaning module treats crops as "variations" and resets them too - which normally is not desired.

[horst]

Crops are variations, and they clearly should be removed! But they will be recreated automagically to the exact last selected crop-rectangle and with your used values for quality and sharpening. It can do that because we save every named crop with your last selected coordinates into the metadata of the original image.   So, even if the crops are gone, if you recall it via API, it recreates a new one. (At least it is expected to do so)

Edited May 10, 2016 by horst

[Peter Knight]

update your site/config.php with the settings for adminThumbOptions (it needs at least one setting for 'gridSize', I prefer 160 over the new default of 130)

If you're wondering what adminThumpOptions are (I was), see https://processwire.com/blog/posts/processwire-core-updates-2.5.9/

(BUT USE THIS SETTINGS FOR PW3+)

Thanks for this making this V3 compatible Horst. Now I can properly use PW 3 goodness

Impatient Pete

Edited May 10, 2016 by horst
added link to the new AdminThumbOptions settings with gridSize!

[horst]

Hi impatient Pete,

I have edit your post and added the link to the new AdminThumbOptions array on Github. The PW 2.5 is obsolete with PW 3.0.17, so this is important to know, and not to rely on the old settings!

And just to clarify: I wrote "Hey you impatient PW users", not "Hey you impatient PW user".

[Peter Knight]

And just to clarify: I wrote "Hey you impatient PW users", not "Hey you impatient PW user".

No clarification needed

I work from home on my own all day so I rely on the PW forums for my daily humour :-/

[Peter Knight]

Hi Horst

Having a few image issues when I install CroppableImage on 3.0.17

Symptoms are

• Clicking the trash icon on the thumbnail has no effect. Normally a red border around the image suggests it's ready for deletion on page save
• Clicking a thumbnail doesn't go into edit mode where 3.0.17 image information panel appears. Normally this displays image name, Crop button, Variations button

copy the new one into site/modules, (DO NOT SIMPLY COPY IT OVER THE OLD ONE, or AT LEAST MAKE SURE THAT THE FOLLOWING FILES ARE NOT PRESENT THERE **)

Ultimately, when the new folder is copied into site/modules, what should it's exact name be?

Is it not advised to manually remove the folder FieldtypeCroppableImages and then upload your ZIp via Modules manager (instead pf copying)?

clear caches for modules and the file compiler

This is clearing the contents of site/assets/cache, right?

update your site/config.php with the settings for adminThumbOptions (it needs at least one setting for 'gridSize', I prefer 160 over the new default of 130)

site/config.php doesn't have any adminThumbOptions options. Did you mean wire/config.php which does?

Assuming all of the above is correct, I'm still getting those symptoms mentioned above. 

I did briefly get the following error flash up and it's very likely they're related but unsure why installing Croppable would cause the first two. In the meantime, I'm going to manually find and copy over those 404 files.

[ceberlin]

Hi Horst, thank you for your quick replies (I know you are busy)! If I can say thank you with a little invitation, send me a pm.

That said, I was really inadvertently resetting all crops (many, many) on my test site. But I had a backup in place, I know I run on thin ice with early beta software but I am so extremely happy that the cropping is working again.

I was expecting that - as you wrote earlier here - it does not matter if the cropped versions are deleted, they would be recreated with the stored cropping coordinates. But in fact they were all reset to default instead. Maybe that had to do with the fact I was updating the module only and had no fresh setup.

After the page is saved once, the positions get remembered most of the time, but still not always. - If I have more information, I will file a report at your GitHub page.

[ceberlin]

Trashing images stopped working for normal image fields (PW 3.17 and 3.18)

Edited May 13, 2016 by ceberlin

[horst]

With PW 3.0.18 there were again major changes in the code of the core images field that renders the intermediate version invalid, (again). So, atm it doesn't make much sense and also I don't have the time to find a way how to implement the croppable images functionality into the new images field. At least, because there is no easy interface or hooking point supported to archive that.

One possible solution could be to make the old core images field a third party module, so that the crop tools can extend this as it was before. Ryan mentioned this somewhere already. Another solution, what I would prefer is, what @Martijn suggested: https://processwire.com/talk/topic/13279-pw-3018-yet-more-images-field-upgrades/#entry120097

[Noboru]

Hi Horst,
any news on this topic? At the moment no good cropping solution for ProcessWire 2.8 and 3.0 seems to exist.

[apeisa]

I have been thinking about what would be the best option for core to handle the frontend variation image cropping. Would simply setting the focus point be enough? That would always be center when cropping (if not explicitly wanted something else). This would require zero configuration, wouldn't contain any design specific information (like image sizes) and would work for both horizontal and vertical images.

[apeisa]

This demonstrates the idea: http://jonom.github.io/jquery-focuspoint/demos/helper/index.html

[horst]

It is an interesting option. Only thing that I may think of what is not good, is that it ever takes full width or full height of the original image. There are use cases where one want crop out a part. But for many other cases this seems a good solution. If I understand the concept right, there would be less hassle with lots of variations. Right?