These links don't work perfectly:
View attachment 293187
They lead to
https://dash.cloudflare.com/numbers/r2/overview/buckets/my-bucket and there's some API errors displayed on this page.
When I'm viewing my bucket from the dash the proper URL has
default instead of
overview :
https://dash.cloudflare.com/numbers/r2/default/buckets/my-bucket
Ya, the new location in Cloudflare has already been updated for the next version (was just a change on Cloudflare's side). I can't control if they change existing URLs in their dashboard, I can only update them as they happen.
Also not sure if all those 0's for internal data bucket is a bad sign, it shows 1K Class A operations on CF's side. But it looks fine after I re-enabled the bucket in the future (see below).
Also, I had a problem in my XF code_cache that made all the phrases not finish compiling.
View attachment 293189
Can't really fix that with anything on this end. The phrase and template rebuilding phase of addon installation is done by XenForo core. So if it failed for whatever reason, it's still XenForo core that needs to actually do it one way or another. Why it failed might be worrisome if it's happening to you a lot, but whatever that reason is is outside the scope of any addon itself. Maybe the addon didn't get fully installed somehow and was missing the phrase xml file... but then why would some phrases be there and not others? Not really sure.
After I fixed my problem I tried to rebuild the addon but it didnt fix so I had to uninstall the addon then install it again. (What a great opportunity to remake the API Key : ) ) And now when Im in R2, I can't automatically configure because the subdomain exists already. Maybe it can just prompt to delete and recreate in this page. Thats what I ended up doing so that it can just do its thing.
View attachment 293191
Well, it
does say, "This subdomain should not already exist."... So if it's an existing bucket that already has the subdomain attached that you want attached to it, you don't need to tell it to configure the public subdomain (uncheck the box to do it since it's already done). But even then if you
do do it, it won't break anything, it will just let you know the domain was already in use when it tried to create that subdomain (it won't try to undo everything else... so it should still all work fine if you ignore the message).
As far as trying to handle a subdomain already in use error in a different way, I'm not really sure you would want to. What if you tried to assign a subdomain that was simply in use by some other part of your site... would you
really want us to go in and delete that DNS entry that was already there and replace it?
In my opinion, doing what it does (telling you it needs to not already be in use, letting you know if it was already in use, but still doing all the other parts and not halting the process if it was in use) is probably still the best approach. Then
you can decide what to do about it (if anything) rather than rely on a one-size fits all action to take if it was in use. Like what if you put the root of your domain in there and simply forgot the subdomain... it wouldn't seem like a great idea to mess with your DNS, delete the apex record for your domain for the normal site and replace it with the URL of an R2 bucket.
Thank you so much for making this. R2 feels so much lighter than S3, there's a simple the bucket's public or it's not. My entire forum installation feels much lighter now thanks to the simplicity of your cloudflare addon.
Yep, no worries...
Definitely if someone's not using cloudflare they are probably doing it wrong.
Ya, I'd agree with that... in fact, I'm pretty sure I said exactly that a few times regarding Cloudflare.
![[DigitalPoint] App for Cloudflare®](/community/data/resource_icons/8/8750.jpg?1692633961){kind=icon}
appforcf.com
