Additional detail: the original/full-size media files still exist and load correctly from the offloaded storage.
The 404s appear to affect WordPress-generated intermediate sizes such as -1024x744.png, -1024x750.png, etc.
The frontend is still able to serve the media from the offload bucket, but the block editor requests these intermediate files using the website’s local uploads URL and receives 404s.
This started while the new metadata migration is running after the recent update. I have not regenerated thumbnails or modified the migration yet, to avoid interfering with it.
Could you confirm whether the migration temporarily changes/invalidates intermediate-size offload metadata or whether this indicates those sizes were not migrated into the new metadata table correctly?
Console:
“Failed to load resource: the server responded with a status of 404 ()
Lokis-new-form-One-Piece-1193-1024×744.png:1
Failed to load resource: the server responded with a status of 404 ()
Zoro-vs-Sommers-One-Piece-1193-1024×741.png:1
Failed to load resource: the server responded with a status of 404 ()
Gunko-Brook-One-Piece-1193-1024×750.png:1
Failed to load resource: the server responded with a status of 404 ()
Sanji-and-Killingham-1193-1024×744.png:1
Failed to load resource: the server responded with a status of 404 ()
Zoro-vs-Sommers-3-1024×754.png:1
Failed to load resource: the server responded with a status of 404 ()
Zoro-vs-Sommers-2-1024×750.png:1″
Each of this appear to be stored as from server but the primary image exist on s3 bucket.
Further testing confirms this also affects normal Image blocks, not just galleries. If I switch the Image block resolution to Full Size, the image loads correctly in the editor. Any generated/intermediate size such as Large/1024px returns 404.
So the original offloaded object exists and is accessible. The issue appears limited to intermediate WordPress image sizes and/or their offload metadata/URL rewriting during the migration.
Migration is currently at 20%
Update: The metadata migration has progressed from about 20% to about 79%, but the same post has continued showing broken intermediate-size images for over two days. In both regular Image blocks and galleries, selecting Full Size loads the image. Selecting Large/1024px makes the editor request a local uploads URL ending in a generated filename such as -1024x754.png, which returns 404.
I confirmed that one affected intermediate-size file, Zoro-vs-Sommers-3-1024x754.png, exists in the S3 bucket alongside its full-size image. The editor still requests that thumbnail from the local uploads URL rather than its offloaded URL.
Is this expected while the files-table migration is still running? Since the intermediate-size file exists in the bucket but the editor requests its local URL, should URL rewriting start working when that attachment’s migration batch completes?
