[DigitalPoint] App for Cloudflare®

[DigitalPoint] App for Cloudflare® 1.9.1.1

No permission to download
Overview FAQ Updates (63) Reviews (22) History Discussion
Thanks, you're right about stats deleted (my bad) but the bug is not really here, with you add-on active the rebuild process is stuck unless i abort it pressing the button Cancel. I can wait 10 minutes, the rebuild process can't start and it's stuck here:

1722432504366.webp

With your add-on disabled, all works fine.
 
Are you getting an error in your error log? If not, I’m guessing it’s just the speed thing with the API calls.

If it's an issue with it starting at 1970, you have a thread with a post_date of 0 or a user with a register_date of 0. When XenForo rebuilds stats, it looks to see when the oldest thread and registered user happened. Not so coincidentally, a timestamp of 0 is Jan 1, 1970. Once XenForo figures out how far back to look, then it will sequence through every day since then until today (about 20,000 days since Jan 1, 1970). So a full rebuild from 1970 to today will trigger 219,340 API calls to Cloudflare (11 for each day).

Anyway, not really sure what you are talking about for the error... but starting at 1970 is because of an erroneous timestamp in your user or thread table and since API calls aren't slowing it down, XenForo spins through it so fast you wouldn't even see it.
 
I have not error in my error log.
But as i wrote, the rebuild process works fine and it is executed in 10 seconds (800 posts, 13 users...) if your add-on is disabled. The process is stuck ad vitam aeternam if your add-on is enabled.
 
Old Nick said:
I have not error in my error log.
But as i wrote, the rebuild process works fine and it is executed in 10 seconds (800 posts, 13 users...) if your add-on is disabled. The process is stuck ad vitam aeternam if your add-on is enabled.
Click to expand...
Like I said, look for users or threads with erroneous register_date or post_date. If you can query the database directly, this will find them:

SQL: 
SELECT * FROM xf_user WHERE register_date < 100;
SELECT * from xf_thread WHERE post_date < 100;

If you can't do a query directly, you can search for users registered before a certain date in admin, and you can search for a thread posted before a certain date in advanced search. But the best way is direct query since that's not going to do any filtering that may happen in search results.

As soon as XenForo thinks a thread was posted or a user was registered in 1970, there are a LOT of days to process for stats. Normally that will still go fast, but if you need 1-2 seconds to generate stats for a day because of the API calls (the Cloudlfare stats), all of a sudden you added 12 hours to the rebuild.
 
But maybe there is an issue elsewhere, cause the rebuild process start from 1/1/1970 your add-on enabled or not.
 
Ya... that's really the underlying issue. When the addon does a full rebuild of stats, it goes from whatever start date XenForo is telling it to start at, so if it's told to start at 1970, it will do that... and that's going to take an insane amount of time since Cloudflare stats are generated from API calls.

As a test, I triggered a full rebuild on one of my sites and captured the timestamp that it started at, and it's as expected (doesn't universally start at 0 (1970)). In my test, it started at a timestamp of, 1686441600 (which is June 10, 2023... which is what it was supposed to be). Even that is going to be a long time... 422 days x 11 API calls per day = 4,642 API calls that need to be done to gather the stats for that period of time.

Another issue is Cloudflare API limits, so even if easy API call could run instantly, there's still an API rate limit of 300 GraqhQL queries per rolling 5 minute window. So doing 11 queries per day, there's a rate limit that would cap the speed at 27 days worth of data per 5 minutes. So even one year worth of data would take a minimum of 68 minutes due to API rate limits.

It probably does make sense to simply ignore stat rebuild requests for Cloudflare data because it's never going to be fast, and it will also never actually work unless it's less than 27 total days the site has been online.
 
I went ahead and made it so it ignores stat generation for ranges more than 1 day (will still generate daily stats, but not full rebuilds). Even in a best case scenario, it's just cumulatively too many API calls to be doing, you will hit API rate limit almost instantly (if it's more than 27 days).

If you want to test it, you can edit the DigitalPoint\Cloudflare\Stats\Cloudflare.php file, change this:

PHP: 
$return = [];

to this:

PHP: 
$return = [];

if ($end - $start > 86400)
{
    return $return;
}

Basically it will only generate stats if XenForo is requesting a range of 86400 seconds (1 day) or less. More than that is a full rebuild, so don't do it.
 
Do you plan to implement this on a future release?
For the moment, i don't need rebuilding daily stats, i rebuilt them just to check regarding the bug reported by JoyFreak.

But i can test your quick fix if you want.
 
Old Nick said:
Do you plan to implement this on a future release?
For the moment, i don't need rebuilding daily stats, i rebuilt them just to check regarding the bug reported by JoyFreak.

But i can test your quick fix if you want.
Click to expand...
Ya it’s already part of the next release. Just doesn’t make sense (for a lot of reasons… mainly because it’s impossible for anything more than 27 days due to API rate limits).
 
@digitalpoint by some reason these attachments are not displayed and a broken image is:
Code: 
test 1:
[ATTACH=full]57770[/ATTACH]
test 2:
[ATTACH type="full"]57770[/ATTACH]

However if I click on them they load fine. These were previously uploaded in vBulletin and I don't see the attachments thumbnails/files when I edit the post.

1723085152824.webp

Do you have any suggestions? Should I rebuild thumbnails?
 
digitalpoint said:
No idea… but if you are missing attachment thumbnails, sounds like a XenForo issue (maybe importer?), not so much a Cloudflare issue.
Click to expand...
Thanks
I'm also running the 1.8.4.1 version of your addon. I remember there was some of the versions which needed some new permissions to be set at CF end token. Could you please let me know if it's safe to upgrade?
 
Ivancas said:
Thanks
I'm also running the 1.8.4.1 version of your addon. I remember there was some of the versions which needed some new permissions to be set at CF end token. Could you please let me know if it's safe to upgrade?
Click to expand...
As long as your API token has the permissions needed, there’s nothing else you need to worry about.
 
digitalpoint said:
As long as your API token has the permissions needed, there’s nothing else you need to worry about.
Click to expand...
I remember the addon release notes saying a new permission was required. I'm trying to find which version was that one and what permission so I can update accordingly
 
You must log in or register to reply here.

Similar threads

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