App for Cloudflare® Pro 1.9.2

[fassbinder]

hi,
In some posts the image is not available.
ex: https://ondeir.com.br/noticias/pref...doacao-do-patrimonio-para-canela-pelo-estado/

when analyzing I see that the URL is referenced as if the image were on the server. strange that when editing it is there...(see image)

This has happened in other posts...any ideas on how to fix it?

 

[digitalpoint]

Is it only certain media images? There is some internal logic to determine if a srcset URL should be transformed or not. It goes through this (in this order):

• Is there a R2 media bucket set
• Is there an external URL set for the bucket (the public domain)
• Is the image flagged as being in R2
• Is there meta data for the image
• Does the requested size variation (width) exist (as defined by the metadata)

If it's a specific image, it's possible that WordPress' internal record for the media is mucked (specifically the metadata). If the metadata record is missing or corrupt, it's not going to know about any size variations that exist. You can check the media metadata record by looking in the wp_postmeta table, and searching for meta_key = '_wp_attachment_metadata' AND post_id = xxxx (xxxx = the item number in the URL when you click on the media).

 

[fassbinder]

I found 3 recent cases.
analyzing the wp_postmeta table iI saw that it considered the image as "jpeg" when it was actually webp.
Even editing the file and changing it, it didn't work. I had to delete it and upload the image again.
Did I do something wrong when editing or is this the solution?

 

[digitalpoint]

The file type as registered in the metadata isn't something the plugin needs to look at in order to generate the srcset URLs, so it wouldn't be that. That being said, it does seem strange that file type in the metadata was incorrect, but then correct when you reuploaded. Makes me wonder if you have some other plugin installed (or maybe previously installed) that could be playing around with media metadata for some reason and causing problems with it somehow. 🤔

 

[fassbinder]

reviewing on previous dates I saw dozens of errors... is there any practical way to correct them?

 

[fassbinder]

The file type as registered in the metadata isn't something the plugin needs to look at in order to generate the srcset URLs, so it wouldn't be that. That being said, it does seem strange that file type in the metadata was incorrect, but then correct when you reuploaded. Makes me wonder if you have some other plugin installed (or maybe previously installed) that could be playing around with media metadata for some reason and causing problems with it somehow.

It's the only image plugin I use: https://wordpress-org.translate.goog/plugins/webp-uploads/

It seems that the App for Cloudflare is not compatible with https://br.wordpress.org/plugins/performance-lab/ (there was already a previous error https://appforcf.com/threads/media-library-error.51/)

suggest making this clear in the plugin description...it may affect other users.

 

[digitalpoint]

If you have multiple plugins doing image transforms when an image is being uploaded, it's probably best to pick one and use just that. For example if you have a plugin you like that is already doing WebP transformations, there's no need to transform it again with the option in the App for Cloudflare plugin (it's already been transformed by the other plugin).

In theory, it shouldn't cause a problem but I can't really speak for how third-party plugins do things internally (for example if a third-party plugin does a transformation and as part of that, moves images somewhere unique to that plugin, rather than the expected location where WordPress uploaded files are), it will be a problem if you want that image to also go to R2 (if something moves the source image, this plugin isn't going to know where it was moved to... it will just be "missing").

If images you are reuploading seem to be fine/working as expected, I'd suspect a third-party plugin that is going in and altering images after the fact (like a cron task or something). If images are already in R2 and a different plugin is going in to make changes to images, but it doesn't know how to retrieve from/upload back to R2, I could see it being a problem if that plugin doesn't gracefully stop what it's trying to do when it can't download/upload. For example maybe it can download the image (since it's a public URL, makes changes, but then fails when it tries up upload back to R2, but then it also makes metadata changes to that media). It's hard to say exactly what's going on, but there's nothing in *this* plugin that alters images after-the-fact... and it appears that might be what's happening if freshly uploaded images are fine, but then they "break" down the road somehow.

 

[fassbinder]

Hi,
After reanalyzing and checking the files, I believe the problem is not with the performance-lab plugin (it was already installed). I noticed that the error occurs on some dates (if it were the plugin, it would occur on all dates).

Is there a way to return the R2 images to the server?

I was thinking of transferring them via FTP, but is there a quick way to adjust the URL to its original form?

 

[digitalpoint]

You can move individual media to/from R2 by clicking on it in the Media browser, then at the bottom hit the Edit more details link.

If it’s a situation where the media’s metadata is corrupt somehow, moving it back to local isn’t going to fix it because the plugin doesn’t alter/edit metadata. But maybe that’s not the issue?

 

[fassbinder]

You can move individual media to/from R2 by clicking on it in the Media browser, then at the bottom hit the Edit more details link.

If it’s a situation where the media’s metadata is corrupt somehow, moving it back to local isn’t going to fix it because the plugin doesn’t alter/edit metadata. But maybe that’s not the issue?

I have more than 5 thousand images... doing them one by one is not feasible.
I want to move all of them to the local server, uninstall the R2 plugin and adjust the errors (if necessary, use R2 again later),

 

[digitalpoint]

The R2 settings page has the Migrate existing media button. That lets you go both directions (from local to R2, but also from R2 back to local).

Can also do it with WP-CLI (both directions).

 

[fassbinder]

that is, it will take forever (WP-CLI is not within my reach).
Is there no way to download via FTP and some command to adjust the urls to the default?

 

[digitalpoint]

You could use any tool that supports the standard S3 protocol to download/delete/upload, etc. in bulk. The one I see most people using is rclone. It has a lot of options (because it can do a lot of stuff).

I haven't personally used it because I've never needed to move things around a bucket in bulk, so I can't be a ton of help with specific commands or options, but it's here:

Rclone

Rclone syncs your files to cloud storage: Google Drive, S3, Swift, Dropbox, Google Cloud Storage, Azure, Box and many more.

rclone.org

On a side note, whatever is going on seems to be more than just renaming files though. There is no check to see if a file exists when it's generating the srcset URLs, so it would still generate it even if the file is missing or renamed.

 

[fassbinder]

I don't think I explained myself well... there's no problem in downloading the files (I already have them).
The question is, if I uninstall the plugin, what happens to the image URLs?
Do they go back to the default?
Or is there a procedure to restore the image URLs to the WP default?

 

[digitalpoint]

Uninstalling the plugin is the same as disabling R2 in settings (the site wouldn't know anything about R2). URLs would go back to WordPress default. But yes, if you are going to do that, you'll want to move the images back to the local filesystem first.

 

[fassbinder]

Uninstalling the plugin is the same as disabling R2 in settings (the site wouldn't know anything about R2). URLs would go back to WordPress default. But yes, if you are going to do that, you'll want to move the images back to the local filesystem first.

OK, thanks!