[DigitalPoint] App for Cloudflare® 1.8.2

[emiya]

Was literally just building the release with the fix. Grab 1.6.2.1... it should be safe to manually rerun the Cron entry for "Record daily statistics" to rebuild yesterday's data.

But it only affects data from yesterday, right? The other days are gone I suppose? And the error with the undefinied $siteKey is fixed?

 

[digitalpoint]

But it only affects data from yesterday, right?

Ya, running the cron manually will only rebuild yesterday.

The other days are gone I suppose?

XenForo does have a tool to rebuild historical statistics, however there's no date range for that tool (it will literally rebuild everything from the first day the site was live). Seems pretty strange to me that the tool XenForo gives you doesn't have a date range. I've made some changes to the addon's stats handler to support historical rebuilds when requested. I'll send you the new version to test via conversation, along with a line of code you can add to XenForo to not have XenForo's stat rebuild tool go from the beginning of time.

And the error with the undefinied $siteKey is fixed?

Yes it is.

 

[Shuya]

Hi,

Not sure if anyone else is getting this when hitting the Download backup button in Tools.

ErrorException: [E_WARNING] foreach() argument must be of type array|object, string given in src/addons/DigitalPoint/Cloudflare/Repository/Advanced/Cloudflare.php at line 1033

1. XF::handlePhpError() in src/addons/DigitalPoint/Cloudflare/Repository/Advanced/Cloudflare.php at line 1033
2. DigitalPoint\Cloudflare\Repository\Advanced\Cloudflare->processBackupResults() in src/addons/DigitalPoint/Cloudflare/Repository/Advanced/Cloudflare.php at line 981
3. DigitalPoint\Cloudflare\Repository\Advanced\Cloudflare->getBackup() in src/addons/DigitalPoint/Cloudflare/Admin/Controller/Cloudflare.php at line 1179
4. DigitalPoint\Cloudflare\Admin\Controller\Cloudflare->actionBackupDownload() in src/XF/Mvc/Dispatcher.php at line 352
5. XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 259
6. XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 115
7. XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 57
8. XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2483
9. XF\App->run() in src/XF.php at line 524
10. XF::runApp() in admin.php at line 13

 

[digitalpoint]

Ya... that's my fault. The last minor version migrated Firewall API usage the new Ruleset API (the Firewall API is being deprecated by Cloudflare), and I forgot about the settings backup part. It's been fixed and part of the next version now.

 

[digitalpoint]

digitalpoint updated [DigitalPoint] App for Cloudflare® with a new update entry:

Added some sanity checks

• Better handling of stats rebuilding when rebuilding all stats for the site (from cache rebuild)
• Check if Cloudflare account ID is missing when generating R2 bucket URL and add a server error log if that's the case (if an API token has insufficient permissions, you could end up with a missing account ID, which would in turn make R2 functions not work).
• Backup option works properly again with Firewall rules (forgot to convert that to the new Ruleset API that the firewall uses...

Read the rest of this update entry...

 

[Ivancas]

@digitalpoint how can I refer to the path of the new data folder (which would be to the R2 bucket) in the templates?
Certain addons use {{ base_url($fthread.image) }} for example so given the case the data folder is stored in R2 the base_url won't work on this case.

 

[digitalpoint]

I don't know what {{ base_url($fthread.image) }} is, but it looks like it's not using XenForo's abstracted file system/paths, which is a big no-no. You can't even be sure a XenForo installation is using the local data directory, that's simply the default. A site could choose to use mysupercool/data/folder/for/stuff if they wanted. So if that addon is hard-coding the external data URL portion to anything, they are doing it wrong.

They may want to look at how "normal" things like avatars and attachment thumbnails are referenced by XenForo, and go the same route. Look at the applyExternalDataUrl and applyExternalDataUrlPathed methods in \XF\App.

If the addon is using the abstracted file system to upload things (and it ends up on R2 or whatever other filesystem you are using), it seems really strange they wouldn't also use the proper methods given for generating URLs.

TL;DR
If a third-party addon isn't following XenForo's standard abstracted file system conventions, there's not going to be anything we can do on this end.

 

[Forsaken]

I don't know what {{ base_url($fthread.image) }} is, but it looks like it's not using XenForo's abstracted file system/paths, which is a big no-no. You can't even be sure a XenForo installation is using the local data directory, that's simply the default. A site could choose to use mysupercool/data/folder/for/stuff if they wanted. So if that addon is hard-coding the external data URL portion to anything, they are doing it wrong.

They may want to look at how "normal" things like avatars and attachment thumbnails are referenced by XenForo, and go the same route. Look at the applyExternalDataUrl and applyExternalDataUrlPathed methods in \XF\App.

If the addon is using the abstracted file system to upload things (and it ends up on R2 or whatever other filesystem you are using), it seems really strange they wouldn't also use the proper methods given for generating URLs.

TL;DR
If a third-party addon isn't following XenForo's standard abstracted file system conventions, there's not going to be anything we can do on this end.

If an add-on isn't following XenForo standards, they should just be stoned and then quartered.

 

[Ivancas]

If an add-on isn't following XenForo standards, they should just be stoned and then quartered.

@XDinc is the dev of https://xenforo.com/community/resources/xtr-featured-threads.6834/ which is the addon not following the standards as digitalpoint stated

 

[TPerry]

If an add-on isn't following XenForo standards, they should just be stoned and then quartered.

And those quarters scattered to the 4 points of the compass!

 

[Mouth]

Only $1.68 USD for 121 GB storage for the month of Apr
Class A/B file operations all within the free tier.

 

[digitalpoint]

View attachment 285470

Only $1.68 USD for 121 GB storage for the month of Apr
Class A/B file operations all within the free tier.

Seems reasonable.

 

[Mouth]

Seems reasonable.

I was previously paying $12.50 /mth for 125 GB block/volume storage attached to my server, so yeah I rather think so

 

[digitalpoint]

I was previously paying $12.50 /mth for 125 GB block/volume storage attached to my server, so yeah I rather think so

Just out of curiosity, what did you see for monthly total on class A/class B operations? Wondering if anyone is even getting remotely close to the free limit on operations or not...

 

[Mouth]

Just out of curiosity, what did you see for monthly total on class A/class B operations? Wondering if anyone is even getting remotely close to the free limit on operations or not...

CF Metrics only gives you 7 days. 2 buckets ...



So that calcs to approx. 8.1 K class A ( 1 million max free) and 1.9 million class B (10 million max free) per month. Well within file operations free tiers.

 

[digitalpoint]

To help get your class B operations down, are you using the rule that R2 offers to setup for you for the public subdomain? Would look something like this:



Also is the Argo Tiered Cache option enabled?

 

[Mouth]

are you using the rule that R2 offers to setup for you for the public subdomain?

Also is the Argo Tiered Cache option enabled?

Yes, both are active as per your screenshots.

 

[digitalpoint]

Yes, both are active as per your screenshots.

Okay, so I'm guessing most of your class B operations are coming from users viewing full size image attachments. Those aren't cached because they go through the application (XenForo) to do permission check for each request.

I've actually been tossing around the idea of added an optional pre-defined rule to cache attachments, but haven't gone that far yet.

The upside:

• Attachments delivered faster to users since they have the potential to be fetched from Cloudflare's cache
• Less class B operations (a cache hit doesn't count towards R2 operations)

The downside:

• No permission checking when a user fetches an attachment (wouldn't work well for sites that allow different users to view or not view attachments based on their user groups)
• Attachment view counter wouldn't +1 if it was fetched from Cloudflare's cache

There's nothing stopping someone from setting that up on their own as it is, this would just be a pre-defined rule it adds (similar to the other cache rules it can add... any of them are able to be added by a user manually if they wanted).

 

[Ivancas]

CF Metrics only gives you 7 days. 2 buckets ...

View attachment 285474View attachment 285475

So that calcs to approx. 8.1 K class A ( 1 million max free) and 1.9 million class B (10 million max free) per month. Well within file operations free tiers.

How do you see those stats? Do you have a link?

 

[digitalpoint]

In Cloudflare dashboard -> R2 -> {your bucket} -> Metrics