- Item seller digitalpoint
Migrate existing media R2
- Thread starter Carlos
- Start date
The option to manually move to/from R2 is under the
Normally for the moving in bulk, it will only not move something if there's an underlying issue with the media itself (for example the files that are expected to be in the local filesystem for movement can't be found... can't move something that doesn't exist).
With "only" 23 to move, maybe you will run across a specific one that isn't able to be moved and I can help figure out what's going on with that one.
Edit more details link.Normally for the moving in bulk, it will only not move something if there's an underlying issue with the media itself (for example the files that are expected to be in the local filesystem for movement can't be found... can't move something that doesn't exist).
With "only" 23 to move, maybe you will run across a specific one that isn't able to be moved and I can help figure out what's going on with that one.
If you move one manually does it also not move? Even if the primary image is there, WordPress stores a bunch of size variations and keeps track of those variations internally, so if that list of variations that WordPress internally keeps isn't matching up with the files in the filesystem (like some are missing), that's where it could be a problem. Say a media image was made up of 10 files (the original and 9 variations), but only 5 of those exist as expected, the addon will err on the side of not moving it to R2 since it's only partially available.
Can see you have WP-Optimize installed there... makes me wonder if it's doing something underneath it all like purging some of the variations, but then not updating WordPress' record about which variations should exist.
Depending on how database savvy you are, your
It's certainly a possibility that some addon or theme or server process tried cleaning up your image variations, but didn't update the database to reflect that (and now there's a discrepancy on what WordPress thinks should be there and what is actually there).
Can see you have WP-Optimize installed there... makes me wonder if it's doing something underneath it all like purging some of the variations, but then not updating WordPress' record about which variations should exist.
Depending on how database savvy you are, your
wp_postmeta table is going to have a list of the variations that WordPress thinks should exist. The post_id will match the media ID and the meta_key will be _wp_attachment_metadata. If some of the expected variations are missing in the filesystem (for whatever reason) it won't move the media since it can't move it in its entirety.It's certainly a possibility that some addon or theme or server process tried cleaning up your image variations, but didn't update the database to reflect that (and now there's a discrepancy on what WordPress thinks should be there and what is actually there).
Honestly, I don't know anything about third-party plugins and what they are/aren't doing. If they work as intended, it should be fine. It should only be an issue if they are deleting WordPress's image variations, but not updating the WordPress database to tell WordPress *about* those changes.
Are you looking in the actual filesystem for the file? If those are attachments you moved to R2, they aren't going to be in the local filesystem, which is what I'm guessing WP-Optimize is limited to. I really doubt WP-Optimize is going to know how to to fetch them from R2.
I do wish WordPress used an abstracted filesystem like some other platforms use so that filesystem storage changes are automatically universal, but unfortunately it does not. So moving stuff out of the local file system is going to cause problems for third-party plugins that rely on files being there (they now exist in your R2 bucket, not in the local upload folder).
I do wish WordPress used an abstracted filesystem like some other platforms use so that filesystem storage changes are automatically universal, but unfortunately it does not. So moving stuff out of the local file system is going to cause problems for third-party plugins that rely on files being there (they now exist in your R2 bucket, not in the local upload folder).
no files are actually in my upload folder in the file local system; its just not detecting the actual image. After clearing cloudflare cache, some images are now displayed properly and uploads seem to be showing pictures
I just uploaded a svg image and it uploaded but it shows blank when I click on the url It does show because it uploaded to R2 but when i link it to a header logo, it wont show
going directly to the link, the image does work fine
Adding it to the logo header wont show anything
Media libary show like this
I uploaded this image just now; there was no wp-optimize install I removed it before uploading it
I just uploaded a svg image and it uploaded but it shows blank when I click on the url It does show because it uploaded to R2 but when i link it to a header logo, it wont show
going directly to the link, the image does work fine
Adding it to the logo header wont show anything
Media libary show like this
I uploaded this image just now; there was no wp-optimize install I removed it before uploading it
If it's just SVG/SVGZ images that are causing an issue, check this thread:
appforcf.com
Specifically, SVGs are unique in that they aren't *really* a binary image format, internally they are actually just an XML formatted text file, so by default R2 will serve them up with a mime type of
Luckily, Cloudflare has a mechanism to set the mime type on them with their HTTP Response Transform Rules (see thread above).
Serving SVG / SVGZ images via R2
By default, Cloudflare R2 analyzes the object when it's uploaded to it's bucket and makes a determination about what the content type should be when that object is served. Normally this works fine, but SVG/SVGZ images are a little bit of an edge case because at the core they are actually...
appforcf.com
Specifically, SVGs are unique in that they aren't *really* a binary image format, internally they are actually just an XML formatted text file, so by default R2 will serve them up with a mime type of
application/xml, but for a browser to attempt to render them as an image, they need to have an image mime type.Luckily, Cloudflare has a mechanism to set the mime type on them with their HTTP Response Transform Rules (see thread above).
Do you have an image URL you could share from that page? Like if you right click one of the images to get the image URL?
Sure, here's the url of one image it just downloads.
Check your transform rule. It looks like content-type has a typo (should have seen it in your screenshot). It should be
image/svg+xml, but it's currently imagen/svg+xml (an extra "n" in there).