Make WordPress Core

Opened 15 months ago

Closed 7 months ago

Last modified 4 months ago

#58944 closed defect (bug) (worksforme)

Upload to Media Library not replicating to all pod's 6.2.2

Reported by: vitorgandra's profile vitorgandra Owned by:
Milestone: Priority: normal
Severity: normal Version: 6.2.2
Component: Media Keywords: reporter-feedback
Focuses: multisite Cc:

Description

Hello, after updating from WP 6.1.1 to 6.2.2 the new uploaded images start to apear "broken" on Media Library. If we refresh the page several time's we will see the image ok, but if we refresh it again it will be broken. We are running the WP in kubernetes, so we have several pod's. This behaviour means the uploaded image is no longer been replicated to all pod's. So it only exist's in one pod.
After reverting to 6.1.1 all is ok.

Change History (12)

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


15 months ago

#2 @antpb
15 months ago

  • Keywords reporter-feedback added
  • Milestone changed from Awaiting Review to 6.4

@joedolson mentioned #57557 and #57375 being candidates for the source of this issue. I'd like to know what your filesystem looks like before and after the uploads happen. Wondering if the logic in the linked tickets is dependent on the state of the filesystem and since in a unique configuration like the k8s described, maybe these functions need to account pods.

Would it be possible to show the file structure in the different states before and after upload?

( props @joedolson )

#3 follow-up: @vitorgandra
15 months ago

Hi @antpb,
I printed the '/var/www/html/app/uploads' directory contents.
Before upload:
array:2 [

0 => "."
1 => ".."

]

After upload dog1.jpeg:
array:5 [

0 => "."
1 => ".."
2 => "dog1-10-150x150.jpeg"
3 => "dog1-10-400x250.jpeg"
4 => "dog1-10.jpeg"

]

We are using Delicious Brains WP Offload Media plugin.
In the 6.1.1 version the plugin offloads immediately to the bucket (maybe uses the same pod).
But in the 6.2.2 the plugin does not find the file:
"file_get_contents(https://xxxxxxx/app/uploads/josh.webp): Failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found"
The "xxxxxx" is our domain.

Last edited 15 months ago by vitorgandra (previous) (diff)

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


14 months ago

#5 in reply to: ↑ 3 @ianmjones
14 months ago

Hey @vitorgandra, Ian here, a developer on the WP Offload Media team.

This error ...

Replying to vitorgandra:

"file_get_contents(https://xxxxxxx/app/uploads/josh.webp): Failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found"
The "xxxxxx" is our domain.

... is a bit strange, would not expect WP Offload Media to be accessing a URL with file_get_contents().

What version of WP Offload Media are you currently using?

Have you raised a support request via the plugin's Support tab? (if so, I might be able to find it and dig a bit deeper if you give me some clues)

#6 @vitorgandra
14 months ago

Hello @ianmjones,
we are using Version 3.2.4 | By Delicious Brains

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


13 months ago

#8 @antpb
13 months ago

  • Milestone changed from 6.4 to 6.5

Moving this to 6.5 as we verify the cause.

#9 @antpb
13 months ago

  • Milestone changed from 6.5 to Future Release

actually, marking awaiting review. we'll move it into a milestone if it is a valid core issue.

Last edited 13 months ago by antpb (previous) (diff)

#10 @antpb
13 months ago

  • Milestone changed from Future Release to Awaiting Review

#11 @vitorgandra
7 months ago

  • Resolution set to worksforme
  • Status changed from new to closed

With the 6.5 version i found that if i remove this lines from our code:

add_image_size('same@2x', 100, 100, false);
add_image_size('same@1x', 100, 100, false);

All is working now.

#12 @desrosj
4 months ago

  • Keywords needs-patch removed
  • Milestone Awaiting Review deleted

@antpb Were you ever able to take a look and dig in here? Closing seems fine, but wanted to make sure there were no additional findings of what could cause this.

Note: See TracTickets for help on using tickets.