[DigitalPoint] App for Cloudflare®

[DigitalPoint] App for Cloudflare® 1.8.2

No permission to download
Overview FAQ Updates (51) Reviews (18) History Discussion
digitalpoint said:
There's probably not a lot I can do about 5xx errors (those are server-side errors on Cloudflare's side). The API library I built does retry once if it gets a 5xx error, but it gives up if it gets it again.

That's (hopefully) something transient/temporary on Cloudflare's side. In all the testing and data migration I've done, I've only received a single 5xx error (which is what prompted me to have it transparently try again). Maybe something going on with Cloudflare's side because it's a new bucket somehow? Not sure to be honest. Is it something that's still happening?
Click to expand...
I've created a new API token, which appears to have sorted it, even though it has the same permissions on it. The only difference is the original one had IP filtering enabled, but this one doesn't. No idea if that's what sorted it, or if it was indeed an error on their side.
 
MattW said:
I've created a new API token, which appears to have sorted it, even though it has the same permissions on it. The only difference is the original one had IP filtering enabled, but this one doesn't. No idea if that's what sorted it, or if it was indeed an error on their side.
Click to expand...
Well by definition a 5xx error is a server-side error (and with it coming from *.r2.cloudflarestorage.com, that's a server on Cloudflare's side. Cloudflare is pretty good at giving correct HTTP response codes, so I'd trust it's really a 5xx error. 4xx are client-side errors (errors caused by the HTTP client... things like requesting a URL that doesn't exist, the client not having the right permissions, etc). 5xx are errors caused by the server (with nothing the client can do about it... which is why the library I made only retries if it gets a 5xx error... no point in retrying a 4xx error, because that's an issue on this end so a retry will yield the same result).

So can't really say what the underlying backend server issue was, but it's safe to say that there would really be nothing you or I could do about it since it's a 5xx error.
 
Tracy Perry said:
Taken care of WELL before the add-on was installed. Not a neophyte in installing add-ons and checking instructions before doing so. ;)

View attachment 279520


The point being I don't use the R2 features.... but when I install the latest add-on version I have problems... revert to the prior version and those issues become non-existent. And they appear to be directly related to serving of images (which the R2 function would involve). It was to the point I could not upload images and attach into a post Could that have been a setting I missed... yep.... but if so, that needs to be detailed in the documentaiton.
Click to expand...
Looked at your backtrace a little closer and the best I can tell, the error you got is happening before the add-on even gets enabled. The process that unzips the archive is what failed (specifically when it goes through and makes sure the files were written that were supposed to be written, it sees that Setup.php wasn't written [for whatever reason] and fails there). I don't have a lot of experience with the admin function that installs addons (I don't allow my web server to have write permission to the file system), but I'm pretty sure it's been working for everyone that does use it..

Do you have a test environment/site you could test doing it again by chance? If the addon installation process simply can't write files as part of what it does, maybe it was a temporary server/quota issue somehow? Not sure, but the point where you get the error is before the new version even gets installed (the issue is that it can't be installed for whatever reason). Assuming the DigitalPoint/Cloudflare directory is writable by the web server "user", the only other thing I can think of is the server operating system blocked the files from being written for some reason.
 
Should we add 2 different buckets?

For example, I created a bucket named "erdi". Do I need to create a data/ folder in it? Or is it necessary to move existing files to the bucket without creating the data/ folder?

I created a single bucket and created data and internal_data folders in it, it didn't work like this :(
 
The add-on uses 2 different buckets. A public one (for data) and a private one (for internal_data/attachments). You don't need to create a bucket manually (the add-on can do it for you). You also don't need to put anything in the bucket, certainly not a "folder" (there are no actual folders in a bucket, just objects with a unique name). Some interfaces will try to show virtual directories based on existing object names, but there's no actual folder anywhere.

Once you have a bucket (either one you made or the add-on made), you will want to move existing files to it (there's a CLI command to do it or plenty of utilities out there like rclone that will do it if you have a ton of data to move).

Again... forget about the concept of folders... buckets have no folders, so you don't need to worry about creating any.
 
So ya, you use it for other stuff already... so that site will cost you $0.24/month (already used your free 10GB). Still not a bad price imo.
 
MattW said:
Yeah, I’ve been using it for 3 sites already. It’s not a bad price at all TBH.
Click to expand...
Will be interesting to see how your class A/class B operations look going forward (they obviously are higher because of the process that moves all the new objects into them). I've done some optimization in the R2 adapter I made as well as with the cache rule you applied with the add-on, so operations going forward should be fairly minimal.
 
Any concern with this error?

"2023/01/06 16:11:48 ERROR : image_cache/87/87485-143c1cf2ebef4f5ab30726b4541b3861.data: Failed to copy: failed to open source object: open /home/********/public_html/internal_data/image_cache/87/87485-143c1cf2ebef4f5ab30726b4541b3861.data: no such file or directory"
 
digitalpoint said:
It should not do anything with R2 unless you actually enable it, so something else is going on. Are you using any fsAdapters defined in your config.php? If so, which?
Click to expand...
No external adapters configured.... only "extra" is using Memcached.
 
digitalpoint said:
But one thing to maybe check is if you have a different add-on that might be altering the XF\FsMounts in a non-standard (not backwardly compatible) way
Click to expand...
The only thing that references XF\FSMounts when in development mode is the Snogs flags add-on that @Ozzy47 took over... not a coder, so hopefully he'll see this and take a look at it to confirm.
Like I said, when I regressed back to 1.3.0, everything worked fine. I'll try upgrading again and seeing if I continue to have the issue since I have a good backup now.
 
You must log in or register to reply here.

Similar threads

N
[DigitalPoint] App for Cloudflare® - FRENCH translation
Replies
8
Views
822
Ozzy47
Ozzy47
digitalpoint
App for Cloudflare (appforcf.com)
Replies
12
Views
1K
securedme
securedme
Top Bottom