cropping no longer possible after update – server error

@mariachellini – The plugin now seems to require at least WordPress version 6.5, as it uses the wp_enqueue_script_module() function added in that update.

@richardlampitt Thanks for the suggestion. Just had a look, my WordPress version is 6.6.2. I also tried the plugin’s self-check, but here also all tests were successful.

For now, I downgraded to plugin version 1.8.0, which is working fine.

To further contribute to finding the potential bug:

I’ve noticed an intermittent server error when reading the file. Weirdly sometimes cropping is successful, sometimes it isn’t and the thumbnail preview of that size stays empty. (+Error message in console (For GET request))

In these cases my server log says this:

2024/10/21 14:25:58 [alert] 28436#28436: *6975 pread() read only 18614 of 23955 from "/var/www/mysite.com/htdocs/wp-content/uploads/2024/10/my-image-740x212.jpg" while sending response to client, client: 185.55.**.***, server: mysite.com, request: "GET /wp-content/uploads/2024/10/my-image-740x212.jpg?cacheBreak=1729513558461 HTTP/2.0", host: "mysite.com", referrer: "https://mysite.com/wp-admin/post.php?post=16&action=edit"

2024/10/21 14:25:58 [alert] 28436#28436: *6975 pread() read only 16937 of 32768 from "/var/www/mysite.com/htdocs/wp-content/uploads/2024/10/my-image-1480x424.jpg" while sending response to client, client: 185.55.**.***, server: mysite.com, request: "GET /wp-content/uploads/2024/10/my-image-1480x424.jpg?cacheBreak=1729513558461 HTTP/2.0", host: "mysite.com", referrer: "https://mysite.com/wp-admin/post.php?post=16&action=edit"

2024/10/21 14:25:58 [alert] 28436#28436: *6975 pread() read only 25845 of 32768 from "/var/www/mysite.com/htdocs/wp-content/uploads/2024/10/my-image-1664x477.jpg" while sending response to client, client: 185.55.**.***, server: mysite.com, request: "GET /wp-content/uploads/2024/10/my-image-1664x477.jpg?cacheBreak=1729513558461 HTTP/2.0", host: "mysite.com", referrer: "https://mysite.com/wp-admin/post.php?post=16&action=edit"

2024/10/21 14:25:58 [alert] 28436#28436: *6975 pread() read only 18614 of 23955 from "/var/www/mysite.com/htdocs/wp-content/uploads/2024/10/my-image-740x212.jpg" while sending response to client, client: 185.55.**.***, server: mysite.com, request: "GET /wp-content/uploads/2024/10/my-image-740x212.jpg?cacheBreak=1729513558461 HTTP/2.0", host: "mysite.com", referrer: "https://mysite.com/wp-admin/post.php?post=16&action=edit"

2024/10/21 14:25:58 [alert] 28436#28436: *6975 pread() read only 16937 of 32768 from "/var/www/mysite.com/htdocs/wp-content/uploads/2024/10/my-image-1480x424.jpg" while sending response to client, client: 185.55.**.***, server: mysite.com, request: "GET /wp-content/uploads/2024/10/my-image-1480x424.jpg?cacheBreak=1729513558461 HTTP/2.0", host: "mysite.com", referrer: "https://mysite.com/wp-admin/post.php?post=16&action=edit"

2024/10/21 14:25:58 [alert] 28436#28436: *6975 pread() read only 18614 of 23955 from "/var/www/mysite.com/htdocs/wp-content/uploads/2024/10/my-image-740x212.jpg" while sending response to client, client: 185.55.**.***, server: mysite.com, request: "GET /wp-content/uploads/2024/10/my-image-740x212.jpg?cacheBreak=1729513558461 HTTP/2.0", host: "mysite.com", referrer: "https://mysite.com/wp-admin/post.php?post=16&action=edit"

2024/10/21 14:25:58 [alert] 28436#28436: *6975 pread() read only 5215 of 29599 from "/var/www/mysite.com/htdocs/wp-content/uploads/2024/10/my-image-1664x477.jpg" while sending response to client, client: 185.55.**.***, server: mysite.com, request: "GET /wp-content/uploads/2024/10/my-image-1664x477.jpg?cacheBreak=1729513558461 HTTP/2.0", host: "mysite.com", referrer: "https://mysite.com/wp-admin/post.php?post=16&action=edit"

2024/10/21 14:25:58 [alert] 28436#28436: *6975 pread() read only 16937 of 32768 from "/var/www/mysite.com/htdocs/wp-content/uploads/2024/10/my-image-1480x424.jpg" while sending response to client, client: 185.55.**.***, server: mysite.com, request: "GET /wp-content/uploads/2024/10/my-image-1480x424.jpg?cacheBreak=1729513558461 HTTP/2.0", host: "mysite.com", referrer: "https://mysite.com/wp-admin/post.php?post=16&action=edit"

2024/10/21 14:25:58 [alert] 28436#28436: *6975 pread() read only 17980 of 32768 from "/var/www/mysite.com/htdocs/wp-content/uploads/2024/10/my-image-1664x477.jpg" while sending response to client, client: 185.55.**.***, server: mysite.com, request: "GET /wp-content/uploads/2024/10/my-image-1664x477.jpg?cacheBreak=1729513558461 HTTP/2.0", host: "mysite.com", referrer: "https://mysite.com/wp-admin/post.php?post=16&action=edit"

Edit:
I’ve downgraded to 1.8.0 in the meantime and am still getting the same error sometimes. My issue seems to be more related to my server setup (which is nginx with “open file cache”) and maybe not related to the op’s problem. (Sorry)

But while we’re here, this is what I’ve found out:
This error seems to be triggered when the image file is accessed while still being modified.
Maybe there can be done something in the way newly-cropped images are saved and then accessed?
I cannot trigger the same error (and I tried a lot) when I use “regenerate thumbnails” by Alex Mills.

Here’s some more context from the nginx forum:

It’s not “related” to the “open_file_cache” directive, but the
“open_file_cache” directive makes the underlying problem more
visible.

The root cause of the messages in question is non-atomic file
update. Somebody on your system edited the file in question
in-place, instead of re-creating it with a temporary name and then
using “mv” to atomically update the file.

Non-atomic updates create a race: a file which is opened by nginx
(and stat()’ed for nginx to know it’s length) suddenly changes.
This can happen in the middle of a response, and results in a
corrupted response – first part of a response is from original
file, and second is from updated one. If nginx is able to detect
the problem due to file size mismatch – it logs the message in
question.

The only correct solution is to update files atomically, i.e.,
create a new file and then rename to a desired name.

However, the “open_file_cache” directive makes the race window
bigger by keeping files open for a long time. Switching it off is
a good idea if you can’t eliminate non-atomic updates for some
reason.

https://forum.nginx.org/read.php?2,244861,244871

Maybe this helps?

• This reply was modified 4 months, 1 week ago by jhtjards.

Maybe a naive thought, but could there be a way to wait for the server’s completion of the crop (and save) and only then reload the newly cropped image via ajax in the crop window?

(sorry can’t edit my post above anymore)

Hi there,

version 1.9.0 has changed from the old ajax api to the newer rest api. I obviously tested this, so would be interesting to get more informations what happend on your server that a connection could not be made.

@mariachellini could you try to open the developer tools of your browser and check if there any errors-message. How long does takes before the message is displayed?

@richardlampitt thank you for pointing this out – i will update the readme.

@mariachellini can you please also check one more thing. How does the image behave on small images like for example a 600×600 pixel image. Do it work on this image?

@volkmar-kantor the error happens on all images, even the small 150×150 version. also the error message popup shows up instantly once the “save crop” button is pressed.

here’s the console error:

main.js?ver=1.9.0:73

POST https://local.dev/wp-json/crop_thumbnails/v1/crop 500 (Internal Server Error)

(anonymous) @ main.js?ver=1.9.0:73

xhr @ main.js?ver=1.9.0:73

Nh @ main.js?ver=1.9.0:75

_request @ main.js?ver=1.9.0:76

request @ main.js?ver=1.9.0:75

(anonymous) @ main.js?ver=1.9.0:71

RT @ main.js?ver=1.9.0:76

cropThumbnails @ main.js?ver=1.9.0:76

e.cropData.e.cropData.hiddenOnPostType.e.errorMessage.U.onClick.t.<computed>.t.<computed> @ main.js?ver=1.9.0:76

Ys @ main.js?ver=1.9.0:25

In @ main.js?ver=1.9.0:25

n @ main.js?ver=1.9.0:30

main.js?ver=1.9.0:76 crop-thumbnails connection error {status: 500, statusText: '', requestUrl: 'https://local.dev/wp-json/crop_thumbnails/v1/crop', requestParams: '{"crop_thumbnails":{"selection":{"x":165,"y":0,"x2…width":150,"height":150,"ratio":1,"crop":true}]}}'}requestParams: "{\"crop_thumbnails\":{\"selection\":{\"x\":165,\"y\":0,\"x2\":742,\"y2\":577,\"w\":577,\"h\":577,\"cropBaseSize\":\"large\"},\"sourceImageId\":115208,\"activeImageSizes\":[{\"name\":\"thumbnail\",\"width\":150,\"height\":150,\"ratio\":1,\"crop\":true}]}}"requestUrl: "https://local.dev/wp-json/crop_thumbnails/v1/crop"status: 500statusText: ""[[Prototype]]: Objectconstructor: ? Object()hasOwnProperty: ? hasOwnProperty()isPrototypeOf: ? isPrototypeOf()propertyIsEnumerable: ? propertyIsEnumerable()toLocaleString: ? toLocaleString()toString: ? toString()valueOf: ? valueOf()__defineGetter__: ? __defineGetter__()__defineSetter__: ? __defineSetter__()__lookupGetter__: ? __lookupGetter__()__lookupSetter__: ? __lookupSetter__()__proto__: (...)get __proto__: ? __proto__()set __proto__: ? __proto__()

(anonymous) @ main.js?ver=1.9.0:76

Promise.catch

cropThumbnails @ main.js?ver=1.9.0:76

e.cropData.e.cropData.hiddenOnPostType.e.errorMessage.U.onClick.t.<computed>.t.<computed> @ main.js?ver=1.9.0:76

Ys @ main.js?ver=1.9.0:25

In @ main.js?ver=1.9.0:25

n @ main.js?ver=1.9.0:30

@mariachellini thank you for the fast feedback. It seems the error is definitely on the php side. Is there anything in your logs? A Internal Server Error would only be shown if there is anything that your php-interpreter do not want to process. Like a syntax error. Maybe i change something, that your php do not like.

• Do you have any “hardend” php settings – i.e. more strict rules how to process the php as a usual setup?
• Do you have used one of the hooks or actions the crop-thumbnail plugin provided?

About the 600×600 pixel size –> i meant that this should be the maximum size of the uploaded image.

• This reply was modified 4 months, 1 week ago by Volkmar Kantor.

@jhtjards Ok, i just noticed you edited your post – and now i guess we have to (seemingly) different problem.

About your question. As far as i understand from your description, there may be an problem with nginx, as there is some kind of file caching and if the image is requested in the middle of the copy process the server may have problems getting the image.
For clearity here is what the plugin does on the frontend: a cache break variable is added to the images in the plugins frontend once on initially load (A) and once right after the cropping is finished (B). From my perspective this should be enough to not get into trouble. As long as the images in from cache break (A) are completely loaded.

On the server side my plugin uses the php copy function to save the function onto the old image (functions\save.php line 121). @jhtjards Do you think that this is cause your problems? Could you possibly test this by replacing the copy code with some rename (https://www.php.net/manual/en/function.rename.php) code?

• This reply was modified 4 months, 1 week ago by Volkmar Kantor.

Hi There,

I’m also seeing a server error on a client site that uses NGINX.

I tracked down the 500 to:

Fatal error: Uncaught Error: Division by zero
in ../wp-content/plugins/crop-thumbnails/functions/save.php on line 475

Call stack:
1. crop_thumbnailsCptSaveThumbnail::filter_optimizeInputForScaledImages() - wp-includes/class-wp-hook.php:324
2. WP_Hook::apply_filters() - wp-includes/plugin.php:205
3. apply_filters() - wp-content/plugins/crop-thumbnails/functions/save.php:403
4. crop_thumbnailsCptSaveThumbnail::getValidatedInput() - wp-content/plugins/crop-thumbnails/functions/save.php:52
5. crop_thumbnailsCptSaveThumbnail::saveThumbnail() - wp-includes/rest-api/class-wp-rest-server.php:1230
6. WP_REST_Server::respond_to_request() - wp-includes/rest-api/class-wp-rest-server.php:1063
7. WP_REST_Server::dispatch() - wp-includes/rest-api/class-wp-rest-server.php:439
8. WP_REST_Server::serve_request() - wp-includes/rest-api.php:420
9. rest_api_loaded() - wp-includes/class-wp-hook.php:324
10. WP_Hook::apply_filters() - wp-includes/class-wp-hook.php:348
11. WP_Hook::do_action() - wp-includes/plugin.php:565
12. do_action_ref_array() - wp-includes/class-wp.php:418
13. WP::parse_request() - wp-includes/class-wp.php:813
14. WP::main() - wp-includes/functions.php:1336
15. wp() - wp-blog-header.php:16
16. require() - index.php:17

Looking at the code around this it does check for the variables before it runs so I’m not sure why it’s getting a zero on one of these but I’m assuming it’s not finding something when doing getimagesize() before this maths?

 $scale = $originalFileData[1] / $baseFileData[1];

Please do let me know if you’d like me to open a different issue thread for this.

Alex

@volkmar-kantor Awesome! Using rename() solved it! I was not able to produce that error again with your suggested change. So the non-atomic file write really was the problem here.
I’ve also tested this change on a few other servers, including apache powered ones, and it worked in every setting for me + no negative side effects.

Sorry again for hijacking the thread, but at least we’ve quickly squashed a potentially hard-to-get bug.
Good luck to the OP solving their issue! I’ll quietly leave now.

Hi,

I also have a problem after the update; I get the error that there is no access to the endpoint: https://ttb.nl/wp-json/crop_thumbnails/v1/crop. I am logged in as an admin.

Cropping is no longer possible; I saw that you made an update with the REST API, mayby somting whet wrong?

Thanks,
Koen

@koendoit please start a new thread as this is not the same error description as before.

Hi @volkmar-kantor ,

Isn’t it? I also get the server error popup mentioned in the first post: https://ibb.co/zfZPbTq console log: https://ibb.co/9TZ6DJF.

If it isn’t, I will start a new thread.

Thanks for your time.

@koendoit ok, i will investigate with a ddev setup on my own.

Seems that there are maybe multiple problems. You may use version 1.8.0 in production till this is fixed.

@alexgwcog could you please post your image settings (what resolutions do you crop for)?

• This reply was modified 4 months, 1 week ago by Volkmar Kantor.
• This reply was modified 4 months, 1 week ago by Volkmar Kantor.