[answered] Cropped images are not in Pageimages. Why?

[szabesz]

Hello,

This is the very first time I want to use the built in image crop feature of the admin. I'm using PW 3.0.108

Cropping in the admin is fun, displaying the result on the frontend is not... So I have an Image field named pictures, and let's say I upload one image. Then I crop it and click "Save as Copy". At this stage two images are displayed in the admin; the original and the cropped one.  So far so good.

And I presumed that outputting both is easy, until I realized that the Pageimages I get by $page->pictures has only one image, the original one. No matter how many new images are generated by cropping, they are never included in the resulting Pageimages array, but why?

[Zeka]

Hi @szabesz

I'm also on 3.0.108 and it works for me as expected. After cropping an image I have to images in Pageimages. 

What type of formatted value do you use for this field? 

[szabesz]

Thanks for the late night repy Zeka ? 

2 minutes ago, Zeka said:

What type of formatted value do you use for this field? 

Array of Items.
And I do get the array, it's just missing the cropped images, very strange...

[Zeka]

Max allowed files ? 

[Robin S]

Works for me also. Screenshot below has crop saved from the first image:

And if I try cropping an image in a field with max files = 1 then there is no "save copy" option in the cropping dialog (as expected).

[szabesz]

6 minutes ago, Zeka said:

Max allowed files ? 

0 or 50, does not matter.

4 minutes ago, Robin S said:

Works for me also.

Thanks for testing, Robin! This is my result:

And I have the cropped copy as the first one, but obviously in my case $page->pictures->first() gets the "second one"... Black magic? ? 

 

[Robin S]

Is the cropped copy still there after you save the page? If so then I don't understand how that's possible, because the inputfield gets the images it displays from the field value (in the database), so if you see two images in the inputfield then there should be two images in the field value. Have you had a look in phpMyAdmin to see if you can see the copy in the field table?

[szabesz]

11 minutes ago, Robin S said:

Is the cropped copy still there after you save the page?

Yes, that's what you can see in the screenshot. I've been fiddling with this issue for three hours by now ?

11 minutes ago, Robin S said:

Have you had a look in phpMyAdmin to see if you can see the copy in the field table?

I also created another one, I have them both along with the original one:

[Robin S]

Check out the created dates on the copies. There's obviously something not right there, but not sure what exactly. Hopefully someone who knows more about these things can shed some light. Would be worth seeing if you get the same issue with a new clean PW installation.

Here is how my table looks for comparison:

[szabesz]

7 minutes ago, Robin S said:

created dates on the copies

Yep, they do look suspicious but I cannot see where to go from here...

8 minutes ago, Robin S said:

Hopefully someone who knows more about these things can shed some light.

@ryan or @horst maybe? ? 

8 minutes ago, Robin S said:

Would be worth seeing if you get the same issue with a new clean PW installation.

I need to go to bed now but in the morning I will try it out with a clean install. Thanks for your time!

[wbmnfktr]

In my case it wasn't cropping the image which led to unexpected results it was only resizing. It took me hours without any results until I used a different image.

I don't know if you test with only one or several images but if there is only one image you use, please try another one.

My .jpg was more of a corrupted-Frankenstein-PNG-saved-to.jpg file. 

May sound ridiculous but you never know.

[Robin S]

Potentially related issues:

https://processwire.com/talk/topic/16685-images-are-not-saved-permanently-with-ajax-upload/
https://github.com/processwire/processwire-issues/issues/132
https://github.com/processwire/processwire-issues/issues/42
https://github.com/processwire/processwire-issues/issues/41

In one of the issues Ryan said that the 1970 timestamp is something that PW does to indicate that the image has not yet been saved, but this should be updated when the page is saved.

Quote

I wasn't able to duplicate this one, but I can provide some additional info that may help to explain why you are seeing the behavior. The timestamp that you see there is one that ProcessWire specifically uses to identify uploaded files that are on a page where the user hasn't yet clicked the "Save" button. So the timestamp is correct, but it would automatically be changed to the correct timestamp after the page has been saved (and thus confirmed that the files/images will remain on the page).

The first of those GitHub issues suggests that the problem was related to a specific PHP version, and upgrading PHP fixed the issue. So that could be something to try.

[szabesz]

8 hours ago, Robin S said:

https://github.com/processwire/processwire-issues/issues/42
https://github.com/processwire/processwire-issues/issues/41

Thanks a lot! I've been hit by this "1970-01-01 01:00:10" issue for sure! If I manually change created in the db table, then all is good. Now I "just" have to track down what causes this. Since I do not even have any hooks added by me just yet, it is probably a module in action. At least this is where I look first.

8 hours ago, wbmnfktr said:

May sound ridiculous but you never know.

No, it' doesn't sound like that. I just forgot to state that it happens with all sorts of JPGs I tried.

Edited July 29, 2018 by szabesz
fix :)

[szabesz]

I have uninstalled almost all third party stuff to no avail. I also tested another site of mine which was last updated half a year ago or so, and that site has the same issue even though that the "old" site was developed "from scratch" just as this one I am working on. So the relation between the two is that I use similar modules and settings, of course.

I also installed a clean PW 3.0.108 which works as expected.

[szabesz]

I could track it down and reported it as it looks like a bug in the core: https://github.com/processwire/processwire-issues/issues/650

In short: If Inputfiled Images with "Overwrite existing files" is ON then creating a cropped image yields created=1970-01-01 01:00:10, ie. when this option is on, ProcessWire does not update the "created" field in the database.

Thanks for the help guys!