Thanks for the detailed reply. Let me try to clear up a few things, because I think we are talking about slightly different use cases.
The plugin is not trying to replace Cloudflare, Squid, Minio, or any other origin setup. It also is not an offloader. WordPress still stores the files and keeps whatever transformation pipeline you already use. The plugin only rewrites the final image URL so the request hits a Worker that fetches the file on demand and caches it in R2. That is the entire idea.
You could absolutely build something similar with Squid or Minio or a reverse proxy. There are many valid ways to do this if you are comfortable managing the infra yourself. The plugin exists for the large group of WordPress users who are not going to set up their own proxy, or Minio, or custom rewrite rules. They just want their existing images to load faster without touching their hosting stack.
On the managed plan, you are right that I need good safeguards. I agree that self hosted R2 or self hosted S3 makes the most sense for larger or more active sites. My plan is to encourage that path when usage grows so the shared bucket does not become a liability for anyone.
The idea of WordPress having a separate “base image URL” setting would actually solve a lot of problems. Until that exists, this plugin is basically trying to fill that gap for non technical users.
If you have suggestions on how to simplify the worker pattern further, or how you would package your Squid setup so it is accessible to others, I am definitely interested in hearing more.
it was an afterthought, but doing something like rsync’ing the wp-uploads directory to a remote http folder might be the most accessible/easy way for a less technical audience.
i think thats the first tack i took.
but then just using wordpress itself as the origin server made the fetch and availability immediate.
and then yeah if youre accomplishing that thing,and filling that gap in. that would be useful and i might give it a try!
ive gone about doing this, in effect, about five or six different ways and youre on the right track for something useful that, no, nobodys (exactly) offering yet. unless you want to go all static which begets other problems like no native comment functionality.
or, use an existing “static website generator” solely to mirror your wp-uploads on publication but then not actually use a static site ;)
youre pitching an in-between for the media. and there is one other plugin that will optimize cloudflare but there was some reason i rejected it. ( i think it irreparably broke the entire site on being disabled or uninstalled so if cloudflare was down and you wanted to just point DNS at your naked IP. you were going to be restoring your database.)
it would be super nice to be able to turn this on/off at will- as others have asked “what if cloudflare is down” , or what if your account gets sanctioned by CF—
well there you go, disable this plugin for an immediate workaround . no need to log into cloudflare or a linux shell to kill or edit my rewrite rules if i can just disable a plugin from the convenience of the wp-admin UI.
you already clarified that all the content is safe and intact locally!
i am not aware of other plugins that would make that part this easy.
Thanks for sharing all this. It is clear you have gone through several versions of solving this problem, and a lot of what you described is exactly what led me to build this plugin.
The “in-between” space you mentioned is what I am trying to make simple: keep WordPress as the origin, avoid all the static-site complexity, and still get CDN-level delivery without touching DNS.
And yes, the instant on/off switch is a big part of the design. A lot of people have been burned by setups where Cloudflare goes down or an account gets flagged and suddenly the whole site is tied to that infrastructure. Being able to disable a plugin in wp-admin and immediately fall back to local files feels like the right safety valve for most WordPress users.
I appreciate you taking the time to think it through. If you try it, I would be interested to hear where it fits (or doesn’t fit) with the approaches you have used before.
yeah ill look at this , i have a wp to deploy from scratch on my to-do list and can just test it there without breaking my existing kludge.
thank you for the replies and addl’ info.
The plugin is not trying to replace Cloudflare, Squid, Minio, or any other origin setup. It also is not an offloader. WordPress still stores the files and keeps whatever transformation pipeline you already use. The plugin only rewrites the final image URL so the request hits a Worker that fetches the file on demand and caches it in R2. That is the entire idea.
You could absolutely build something similar with Squid or Minio or a reverse proxy. There are many valid ways to do this if you are comfortable managing the infra yourself. The plugin exists for the large group of WordPress users who are not going to set up their own proxy, or Minio, or custom rewrite rules. They just want their existing images to load faster without touching their hosting stack.
On the managed plan, you are right that I need good safeguards. I agree that self hosted R2 or self hosted S3 makes the most sense for larger or more active sites. My plan is to encourage that path when usage grows so the shared bucket does not become a liability for anyone.
The idea of WordPress having a separate “base image URL” setting would actually solve a lot of problems. Until that exists, this plugin is basically trying to fill that gap for non technical users.
If you have suggestions on how to simplify the worker pattern further, or how you would package your Squid setup so it is accessible to others, I am definitely interested in hearing more.