App for Cloudflare® Pro 1.8.3

[Nergiza]

I'm confused about the command to run:

wp app-for-cf migrate-media --processes=20

triggers a warning that says moving "from filesystem to filesystem"? What's the command supposed to move to R2?


Also stating '--local-to-r2' doesn't change anything


There is an inconsistency and the messages should be more clear to state if the migration is being done to R2 or the local filesystem.
--------------------------
On the other hand, I get the following errors after running the command:

 

[digitalpoint]

The from/to being the same is a purely cosmetic thing that was fixed already for the next version (purely cosmetic though, no underlying functionality is affected).

Does the actual moving of media work?

As far as Elementor notices, that looks like something unrelated (specifically some malformed class methods in Elementor). I’m guessing you just never see them because notices are suppressed normally when using the web version of WordPress. That became a deprecation notice in PHP 8. Are you using the latest version of Elementor?

 

[Nergiza]

The process has ended and there are still broken images:



The migrate windows shows these stats:


The file was indeed uploaded to R2 but it seems your plugin didn't update the file path to r2. Instead, it removed the file but Wordpress is trying to load it from the filesystem (but it has been already removed):

 

[Nergiza]

Are you using the latest version of Elementor?

Yes, 3.20.4 version

 

[Nergiza]

In fact, I see none of the image paths were replaced by the External data URL. They are still pointing to the file system and to make it worse some images were removed but some others not

 

[digitalpoint]

The 15 media that didn’t get moved could be because there’s an issue with them to begin with. Usually this is because the local files that are supposed to be moved are missing for whatever reason (nothing to actually move when it tries). The short version is if it’s unable to find the file that’s supposed to be moved, it will skip the attempt to migrate the file.

For the Elementor thing, you may want to report it to them. The issue exists within their shortcode.php file the notice lists (on line 99). Would be easy enough to fix, but that doesn’t really solve it going forward (next time you updated Elementor it would revert back to the issue). It still works, but doing it how that method is doing it was deprecated in PHP 8, so you will get a notice about that when using PHP 8. And you just don’t see the deprecation notice in WordPress via web because normally it hides notices. Either way, it’s “only” a notice… whatever it’s trying to do is still functioning, just not how PHP wants it done in version 8.

 

[Nergiza]

In fact, I see none of the image paths were replaced by the External data URL. They are still pointing to the file system and to make it worse some images were removed but some others not

Can you check this @digitalpoint ? The site is https://nergiza.com/ and CloudFlare cache was already purged

 

[digitalpoint]

In fact, I see none of the image paths were replaced by the External data URL. They are still pointing to the file system and to make it worse some images were removed but some others not

If the images were added to posts via the media block, the URLs should update automatically. If it was some other method, they wouldn’t.

It’s going to be a good idea to create a redirect rule to handle cases where they weren’t done with the media block. See this thread for how to do that:

Redirecting old WordPress media URLs to new URLs after migrating media to R2

For sites that migrate existing media to R2, it makes sense in most cases to redirect the old URL to the new URL. You are able to do it easily with a single Cloudflare Redirect Rule (in your Cloudflare dashboard under Rules -> Redirect Rules -> Create Rule) like so: Rule name Redirect local...

appforcf.com

 

[Nergiza]

The 15 media that didn’t get moved could be because there’s an issue with them to begin with. Usually this is because the local files that are supposed to be moved are missing for whatever reason (nothing to actually move when it tries). The short version is if it’s unable to find the file that’s supposed to be moved, it will skip the attempt to migrate the file.

I find necessary to have a log to know what media couldn't be moved

 

[digitalpoint]

I find necessary to have a log to know what media couldn't be moved

Ya, it’s already on the to-do list. I do wish WordPress had a central logging system like other frameworks/platforms, but they don’t, so it’s a lot more involved. But it’s coming regardless.

 

[Nergiza]

It’s going to be a good idea to create a redirect rule to handle cases where they weren’t doing with the media block. See this thread for how to do that:

Redirecting old WordPress media URLs to new URLs after migrating media to R2

For sites that migrate existing media to R2, it makes sense in most cases to redirect the old URL to the new URL. You are able to do it easily with a single Cloudflare Redirect Rule (in your Cloudflare dashboard under Rules -> Redirect Rules -> Create Rule) like so: Rule name Redirect local...

appforcf.com

Thanks, this definitely worked. Is there any reason why certain images were removed but some others not?

 

[digitalpoint]

Thanks, this definitely worked. Is there any reason why certain images were removed but some others not?

It really just comes down to if people use the media block to add images to posts or not. It’s pretty common to not do it that way (I’m guilty of it myself). Some plugins inject images there own way, other times authors just use HTML to add <img /> tags. But ya… usually it’s themes or plugins people use to build pages (they don’t always use media tags since you can do more/have more flexibility doing it how you want exactly).

 

[Nergiza]

It really just comes down to if people use the media block to add images to posts or not.

Yeah could be great to add to the documentation some SQL query to replace the old media urls by the external data url. In fact, some option could be added to the plugin to scan all the occurrences and offer a way to mass replace them like the Post/Replace XenForo addon.

 

[digitalpoint]

Yeah could be great to add to the documentation some SQL query to replace the old media urls by the external data url. In fact, some option could be added to the plugin to scan all the occurrences and offer a way to mass replace them like the Post/Replace XenForo addon.

Ya… we’ll see. The other issue is other sites (you may or may not own) could have referenced the original URL as well, so it’s always going to make sense to do the redirect even if it’s just to pick up “strays”.

 

[Nergiza]

@digitalpoint I'm having another issue, I'm uploading media through the media page (https://nergiza.com/wp-admin/media-new.php) but the links are all broken like https://media.nergiza.com/rsz_166666.gif?1713192300

The error log shows the following:

 

[digitalpoint]

Does that rsz_166666.gif object exist in the R2 bucket if you browse/search for it in the R2 dashboard?

 

[Nergiza]

Does that rsz_166666.gif object exist in the R2 bucket if you browse/search for it in the R2 dashboard?

yes, it does:

 

[Nergiza]

Edit:
What happened is I created a bucket for testing and I forgot to remove the DNS record so when I created the new bucket using the plugin the DNS record was still pointing to the old bucket. The plugin should check that or at least return if the record already exists because it was never modified to point to the new bucket.

Now the record is pointing to the new bucket so images are loading fine

 

[digitalpoint]

Ya that’s what I was just going to say (the issue that the screenshot didn’t have a public URL).

At one point the system did try to automatically fix issues like that, but it was causing more problems that it was solving (there are times where someone doesn’t want a domain reassigned to the bucket for whatever reason). Or an issue where a user picked an already existing subdomain (used for a normal site, not an R2 bucket), which becomes problematic when we try to automatically figure out what the user meant and would *actually* want to do.

So for now it attempts to make whatever config changes are requested, but doesn’t go outside that or try to work out a course of action if the config change failed for whatever reason.

Certainly open to ideas, but so far, just doing nothing in those cases seems like the safest thing to do.

 

[Nergiza]

Ya that’s what I was just going to say (the issue that the screenshot didn’t have a public URL).

At one point the system did try to automatically fix issues like that, but it was causing more problems that it was solving (there are times where someone doesn’t want a domain reassigned to the bucket for whatever reason). Or an issue where a user picked an already existing subdomain (used for a normal site, not an R2 bucket), which becomes problematic when we try to automatically figure out what the user meant and would *actually* want to do.

So for now it attempts to make whatever config changes are requested, but doesn’t go outside that or try to work out a course of action if the config change failed for whatever reason.

Certainly open to ideas, but so far, just doing nothing in those cases seems like the safest thing to do.

I think checking the DNS record already exists would be a good idea. Apart from that and the other things I already mentioned I think the plugin works great