[cr1st1an]

The idea here is that WordPress will still host and transform the images (could have many stacked plugins as a pipeline) but the plugin will rewrite the final image's URL to be served by Cloudflare. So you can benefit of whatever pipeline you have in the server, and let the plugin use cloudflare at the edge.

[weird-eye-issue]

That is what Cloudflare already does by caching images

[cr1st1an]

Right. The target user is not using Cloudflare nameservers.

[razingeden]

so i could. say.

have a squid proxy on a $5 unmetered vps, referring to WP as a content-origin and then just use this to rewrite the image URL without using cloudflare at all?

(also possible with an apache directive but , doing it in WP could be useful)

and could you not .. just do the same for your $2.99 customers so you dont get a surprise $2000 bill or find yourself told by cloudflare that its time to pay up?

although if youre allowing uploads youre not in control of youd really need something like sightengine (or to roll your own) sooner or later to make sure no CSAM uploads and then theyll just get you in fees that way.

otherwise one person who does that might get your account canned and take every single blog using this service out

thats why id be a proponent of steering them to sign up and use their own CF R2 bucket , or self hosted minio (s3), or other s3 provider… or the squid thing for technical users who dont like cloudflare and its ilk. then theyre responsible for what they upload and host.

most wordpress static site plugins will configure the s3 hosting.

i just am not familiar with any that would easily let me plug in my own base URL for images. they probably exist… and if not then good job for tackling it. at the moment im going about this a different way and it works? but i wouldnt know how to go about packaging and shipping this up in a way thats accessible for everyone.

maybe a crude squid.conf generator you put your real wp url and your new cdn url into. but then youll want https on it too

i do know a lot of people would love to have “cdn” features without taxing the i/o and bandwidth on wordpress but who ALSO dont want to get cloudflare into their hosting for one reason or another. (im not there yet but i get it.)

the hug of death on stock wordpress is real which is why im already doing this in practice. with extra steps. (specifically a cloudflare rewrite rule for /wp-uploads/* to the alternate base URL which could also be done in vhost directives)

imo WP needs a third option under site URL and admin URL , for the base image URL.

[cr1st1an]

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.

[razingeden]

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.

[cr1st1an]

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.

[razingeden]

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.

[cr1st1an]

If you run into anything or have thoughts later on, feel free to reach out: inbox [at] cris.mx