jhtjards

1.9.3 works great for me, thanks again for your responsiveness!

@volkmar-kantor Did you just miss it or is there another reason for not implementing the rename() atomic-save fix? (Just want to make sure it doesn’t get lost)

@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.

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)

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 1 month ago by jhtjards.

Same here. I don’t use Comments on my site and I don’t even make use of the comments template. I’ve used the comment-registration setting to make sure no spam comments via rest or xmlrpc or whatever can get through.

At the moment the plugin only checks for the WP Option ‘comment_registration’ and will popup this message as long as this site option is set.

Please make it actually dismissable or maybe someone has a better suggestion for cases like this?

Yep, this works for me!

Thank you!

Hi, have you been able to take a look at this?

I’m seeing more support requests regarding compatibility with (redis) object cache. The above mentioned class is wordpress core, so this might be worth checking, could be an easy fix ??

Hi, so my further investigation (and support ticket with a object-cache-helper plugin developer) has confirmed, that this plugin is missing an object cache flush when changing the order of draft posts.

The dev said the following:

I’ve taken a look at this and I’ve confirmed the issue you are having. However, our Redis object caching is an implementation of the WordPress object-cache.php drop-in, which means that WordPress determines when the object cache is cleared, we don’t control that. So the plugin developer would need to call one of the?WordPress object cache functions?to clear the cache after changing the order.

Could you take a look at this?

I’m not sure why only there, but I also had to reapply the above fix on one of my sites, otherwise no javascript (and probably css) would be loaded.
This occured after an update to all the latest versions of WP, ACF Pro and Embed Privacy. (PHP 8.0)
Reverting to Embed Privacy 1.7.1 or 1.7.0 did not fix the behaviour.
Neither did Reverting to ACF 6.0.7.

In my case the WYSIWYG Field is nested within a Group Field.

It seems to work nicely for new embeds on my sites! Thanks for the fix!

One Question though: It doesn’t seem to update existing videos that didn’t have been working before.
Those videos had post meta data like “_oembed_{hash}” with an empty value.
I was able to manually correct this by:
1. removing the video link from the ACF text-editor field
2. removing the _oembed_{hash} post meta entry (via Post Meta Data Manager)
3. saving the post
4. Entering video Link back again
5. saving the post (hereby creating a correct _oembed_{hash} post meta entry)
6. saving the post again (hereby creating/attaching the sideloaded thumbnail)

This is quite the extensive action to do on all posts with an embedded video.
Do you think you might be able to add a check & refresh function for these cases?
Or maybe an extra helper function to run?

In my specific case it is is a WYSIWYG-Editor Field with:
Tabs: Visual & Text, Toolbar: Full, Show Button for Media Upload

And I’m using the Classic Editor.

Any chance we can get this working?

Looking forward to that! Still one of the most useful Plugins around!

I can confirm this is still broken.

Also, while adding the filter to https://github.com/epiphyt/embed-privacy/blob/main/inc/class-embed-privacy.php#L272
does help initially if you have an embed within an acf editor field, i’m experiencing the strange behaviour that the previously shown YT-preview image gets deleted after I save the post.

These were my steps:

• Have a post with an embed within an ACF WYSIWYG Editor
• Install Embed Privacy 1.6.5
• Enable Javascript detection and preview images
• View Post in frontend (Embed Layout broken and loading is not working, though YT Preview image is shown in Background!)
• add above mentioned filter in class-embed-privacy.php L272
• View Post again: Everything looks and works as it should
• Save/Update Post (no actual changes made)
• Preview image is gone (deleted from post_meta), so a black preview screen remains.

Hope this helps!