szabesz Posted July 28, 2018 Share Posted July 28, 2018 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? Link to comment Share on other sites More sharing options...
Zeka Posted July 28, 2018 Share Posted July 28, 2018 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? 1 Link to comment Share on other sites More sharing options...
szabesz Posted July 28, 2018 Author Share Posted July 28, 2018 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... Link to comment Share on other sites More sharing options...
Zeka Posted July 28, 2018 Share Posted July 28, 2018 Max allowed files ? 1 Link to comment Share on other sites More sharing options...
Robin S Posted July 28, 2018 Share Posted July 28, 2018 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). 2 Link to comment Share on other sites More sharing options...
szabesz Posted July 28, 2018 Author Share Posted July 28, 2018 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? ? Link to comment Share on other sites More sharing options...
Robin S Posted July 28, 2018 Share Posted July 28, 2018 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? 1 Link to comment Share on other sites More sharing options...
szabesz Posted July 28, 2018 Author Share Posted July 28, 2018 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: Link to comment Share on other sites More sharing options...
Robin S Posted July 28, 2018 Share Posted July 28, 2018 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: 1 Link to comment Share on other sites More sharing options...
szabesz Posted July 28, 2018 Author Share Posted July 28, 2018 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! Link to comment Share on other sites More sharing options...
wbmnfktr Posted July 28, 2018 Share Posted July 28, 2018 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. 1 Link to comment Share on other sites More sharing options...
Robin S Posted July 28, 2018 Share Posted July 28, 2018 Potentially related issues: https://processwire.com/talk/topic/16685-images-are-not-saved-permanently-with-ajax-upload/https://github.com/processwire/processwire-issues/issues/132https://github.com/processwire/processwire-issues/issues/42https://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. 1 Link to comment Share on other sites More sharing options...
szabesz Posted July 29, 2018 Author Share Posted July 29, 2018 (edited) 8 hours ago, Robin S said: https://github.com/processwire/processwire-issues/issues/42https://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 :) Link to comment Share on other sites More sharing options...
szabesz Posted July 29, 2018 Author Share Posted July 29, 2018 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. Link to comment Share on other sites More sharing options...
szabesz Posted July 29, 2018 Author Share Posted July 29, 2018 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! 4 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now