[DigitalPoint] App for Cloudflare®

[DigitalPoint] App for Cloudflare® 1.9.1.1

No permission to download
Overview FAQ Updates (63) Reviews (22) History Discussion
securedme said:
While I understand all images/attachments added by users are being stored in R2 in the future, what about those images used for styling the forum, such as node images which were stored in /data/assets/node-images/, should I also move these images to R2 and change all links referring to these files in extra.less or I just leave it as it is?

Also what about avatar images? While user uploaded avatars can make use of the R2 storage, but there's an add-on 'Avatar Gallery' that recognize all icons I uploaded in /data/gallery_avatars/ folder and have them displayed for users to choose. It also also categorization of the avatar by various sub-folders, e.g. /data/gallery_avatars/man and /data/gallery_avatars/woman .

Should I upload them all to R2 and change the URL of images in the templates of this add-on? (not sure whether it works)

These are just two examples that I can think of.

I'm now actually starting everything from a new server. So it might be a good thing for this. But still I need a good planning.
Click to expand...
Anything that uses XenForo’s abstracted file system will work fine. So anything built into XF itself will work (for example styling assets).

Third party addons will also work fine as long as they were done “properly” and do reads/writes via the abstracted filesystem in XenForo’s core.

securedme said:
A few more questions:

1) When users are to upload images/attachments to my forum, they're still using my server's bandwidth, right? So I need to limit the Maximum attachment file size for saving bandwidth and (maybe) my servers memory, right? And this will be the only reason I set size limit to uploading files?
Click to expand...
Yes, uploading things go to your server initially and then your server transfers them to R2.

securedme said:
2) Once uploaded, the images/attachments are stored in CF's R2 (by the magic behind), so visitors loading those files later won't have any impact to my server's loading, because they're not using my server's bandwidth, processing power nor memory, right?
Click to expand...
Things in the public data folder (for example avatar and attachment thumbnails) are served directly from R2 (no server bandwidth is taken).

Things in the private internal_data folder are normally passed through the server (server does permission checks to see if the user is allowed to view them, then passes it through if they can). Can use presigned URLs to have the user fetch attachments direct from R2.

securedme said:
3) Will files/images stored in R2 load slower than before when they were stored in my server because they're physically closer to users?
Click to expand...
Not sure why they would load slower being closer to the user, but ya… things in the public data folder (like avatars) will typically load faster.

securedme said:
4) Currently I'm using @truonglv 's Image Optimizer which does a great job in compressing images. After using R2, do I still need such kind of add-on? I guess no?


Thanks.
Click to expand...
No idea, never used it. R2 doesn’t compress anything, so if you are trying to alter by compression, you’d still use it I guess…
 
digitalpoint said:
Anything that uses XenForo’s abstracted file system will work fine. So anything built into XF itself will work (for example styling assets).

Third party addons will also work fine as long as they were done “properly” and do reads/writes via the abstracted filesystem in XenForo’s core.
Click to expand...

You mean for the two examples given, node images and images for avatar gallery add-on, I'd better leave them in server and use them locally?

So avatar images (A) uploaded by users will be moved to R2 while those images (B) used by Avatar Gallery (which were uploaded by me) better stay in the server?

1701442003758.webp

digitalpoint said:
Things in the private internal_data folder are normally passed through the server (server does permission checks to see if the user is allowed to view them, then passes it through if they can). Can use presigned URLs to have the user fetch attachments direct from R2.
Click to expand...

I enabled token auth for attachments.

1701442393998.webp

I vaguely understand what it does by its description. So it's a better choice over presigned URLs for this purpose? Any downside for this method?

digitalpoint said:
Not sure why they would load slower being closer to the user, but ya… things in the public data folder (like avatars) will typically load faster.
Click to expand...

I mean my server is closer to my place (target market), images should be loaded quicker than those from R2 (I have no idea where their servers are)?

Many thanks for your reply!
 
securedme said:
You mean for the two examples given, node images and images for avatar gallery add-on, I'd better leave them in server and use them locally?

So avatar images (A) uploaded by users will be moved to R2 while those images (B) used by Avatar Gallery (which were uploaded by me) better stay in the server?

View attachment 294676
Click to expand...
I don’t know anything about any addon I didn’t write, so I can’t really speak about the best way to use them. If an addon uses XenForo’s abstracted filesystem, it will be compatible with R2. Any addon that isn’t using XenForo’s abstracted filesystem is doing it wrong and the author needs to revisit it. I’d think those addons are probably using the abstracted filesystem as they should, but again… I didn’t write them, so no clue.

securedme said:
I enabled token auth for attachments.

View attachment 294677

I vaguely understand what it does by its description. So it's a better choice over presigned URLs for this purpose? Any downside for this method?
Click to expand...
Token auth is a better option than presigned URLs if it’s available to you (you need the zone to be on a paid Cloudflare plan for it to be available).

securedme said:
I mean my server is closer to my place (target market), images should be loaded quicker than those from R2 (I have no idea where their servers are)?

Many thanks for your reply!
Click to expand...
Cloudflare probably has data centers in your target market. You can see the exact cities that Cloudflare has data centers in here:

www.cloudflare.com

Cloudflare Global Network | Data Center Locations

Exceptional performance, security and reliability for the modern enterprise, with a vast global network spanning hundreds of cities in 100+ countries.
www.cloudflare.com www.cloudflare.com
 
jb-net said:
Wouldn't this rule:

also cache the /service_worker.js?
What happens if a new version of xenforo with an updated service_worker gets released?
Click to expand...
Yep… if are going to use a rule to cache .js files, probably just want to do it within the /js/ folder if you are worried about caching JavaScript outside of that folder.
 
@digitalpoint have you had any reports of this error?

Code: 
Fatal error: Declaration of XFCloud\XF\FsMounts::getFsAdapters(array $config) must be compatible with
DigitalPoint\Cloudflare\XF\FsMounts::getFsAdapters(array $config, $allowAdaptersNotInConfig = true) in
/var/www/live/src/addons/XFCloud/XF/FsMounts.php on line 78

We've just had a Cloud customer report a 500 error, and debug shows that.
 
Paul B said:
@digitalpoint have you had any reports of this error?

Code: 
Fatal error: Declaration of XFCloud\XF\FsMounts::getFsAdapters(array $config) must be compatible with
DigitalPoint\Cloudflare\XF\FsMounts::getFsAdapters(array $config, $allowAdaptersNotInConfig = true) in
/var/www/live/src/addons/XFCloud/XF/FsMounts.php on line 78

We've just had a Cloud customer report a 500 error, and debug shows that.
Click to expand...
I haven't, but it looks like you guys are using a FsMounts class in the XFCloud addon that (maybe) isn't compatible with XF\FsMounts (the default FsMounts class in XenForo)... which is going to be problematic for anything extending the FsMounts class if the FsMounts class that replaces the default one isn't compatible with the default FsMount class.
 
Yeah, I've advised the customer to disable the add-on for now and we'll take a look into making things compatible.

Just wasn't sure whether it had come up before now.
 
Paul B said:
Yeah, I've advised the customer to disable the add-on for now and we'll take a look into making things compatible.

Just wasn't sure whether it had come up before now.
Click to expand...
Actually wait... not an issue on your end. I did add an extra param to the getFsAdapters method to optionally allow injecting adapter config info outside of the config.php file (allows having a GUI to configure adapters like R2 or whatever else).

Normally it's only referenced in itself (only within the DigitalPoint\Cloudflare\XF\FsMounts class). I think the issue is XFCloud addon is also trying to extend the getFsAdapters method within the FsMount class, but in a different way/for a different reason. Not sure there's really going to be a way around it (at least that I can think of). If I make my class backwardly compatible with XenForo's default method, you lose the ability to configure abstracted filesystems via admin control panel.

Tl;DR: it's what allows abstracted filesystem configuration without needing to muck with config.php.
 
Paul B said:
Yeah, I've advised the customer to disable the add-on for now and we'll take a look into making things compatible.

Just wasn't sure whether it had come up before now.
Click to expand...
Okay dug around some more... getFsAdapters isn't a standard XenForo method at all. So the issue here is that XFCloud addon and my addon have both coincidentally added a method named getFsAdapters, but each doing different things (that method isn't being extended). Easy enough to fix by one (or both addons) simply picking a different method name.
 
digitalpoint updated [DigitalPoint] App for Cloudflare® with a new update entry:

Better presigned URLs

  • Presigned URLs forcibly set Content-Type and Content-Disposition HTTP response headers (fixes situation where something like rclone set incorrect content type for the object in the R2 bucket)
  • Cloudflare statistics charts on admin dashboard dynamically resize properly when resizing window
  • Added ability for individual API calls to ignore multiple error codes instead of just one
  • Changed FsMounts::getFsAdapters method name to FsMounts::getDpFsAdapters to...
Click to expand...

Read the rest of this update entry...
 
You must log in or register to reply here.

Similar threads

D
[DigitalPoint] App for Cloudflare® - FRENCH translation [Deleted]
Replies
9
Views
874
Ozzy47
Ozzy47
digitalpoint
App for Cloudflare (appforcf.com)
Replies
12
Views
1K
securedme
securedme
Back
Top Bottom