[DigitalPoint] App for Cloudflare®

[DigitalPoint] App for Cloudflare® 1.9.1.1

No permission to download
This addon doesn’t do anything to the file being uploaded. If anything (even a 0 byte file) is showing up in R2, the addon uploading it is using XenForo’s abstracted file system for uploading, but what is being uploaded is wrong. I don’t know anything about that addon, but maybe it’s trying to read what it’s going to upload (thumbnail data) without using the abstracted file system (like just assuming it’s in the local filesystem?)
 
So to add to the above, it seems some images are affected. I can upload .png files OK, and some jpeg files are still working as expected. I'm still trying to see if it's specific files (I was uploading through the Photos link on my macbook as they are images from my phone taken this weekend).
 
Ignore the above 🤦‍♂️

I've swapped from Imagick to GD and that's sorted the thumbnails. I'll see if I can figure why imagick has sh!t the bed.
 
Maybe they are too large for XenForo to generate thumbnails? Or a format that XenForo can’t generate thumbnails for? 🤷🏻‍♂️

If the images are very large, check your $config['maxImageResizePixelCount'] config option, but this addon isn’t going to affect that, it wouldn’t work for any way you are storing files in XenForo.
 
Maybe they are too large for XenForo to generate thumbnails? Or a format that XenForo can’t generate thumbnails for? 🤷🏻‍♂️

If the images are very large, check your $config['maxImageResizePixelCount'] config option, but this addon isn’t going to affect that, it wouldn’t work for any way you are storing files in XenForo.
No, they always worked before. Trying to see what's changed as to why they no longer work now. Even small ones don't generate a thumbnail image (but the full size image behind the thumbnail works).
 
I'm using R2 but I don't have the site even pointing to CloudFlare. R2 (because we're using Siteground DNS). It is working great because it uses my API token but XF cron jobs have stopped because "Oops! We ran into some problems. Cloudflare zone not found: forum.com"

So, the addon is looking for a CloudFlare zone even when I don't need it. Only R2 is enabled.
Can you make an exception so it won't affect anything?
 
The addon isn’t designed to use R2 without the domain being a Cloudflare zone. You could probably do it, but you will end up with errors anytime it looks for the zone (for example if you go to edit Cloudflare settings).

There aren’t any scheduled recurring cron tasks with the addon, so I’m curious what is being run exactly. If yoi are using the function to auto-block IPs for a certain period of time, it will try to unblock them in the future, but not sure how you would have blocked them without having a Cloudflare zone.

Honestly yoi are going to be better off (less problems) if you want to use R2 as a standalone thing without your domain in Cloudflare by using one of the generic AWS S3 filesystem adapters and uninstall this addon. It’s simply not intended for what you are trying to do.
 
'Record daily statistics' is the XF cron that triggers that error.
Is that the only thing causing you issues? I haven’t tested it on a zone that doesn’t use Cloudflare (I don’t have a domain that doesn’t use Cloudflare) so I’m having to think “in theory” here.
 
Ya… if it’s not causing any other issues, I could fairly easily handle it in the addon. Will have to give me a couple days though, as I don’t get back to a computer until Saturday.
 
no worries, thank you! Will wait for it
If you go into the DigitalPoint/Cloudflare/Stats/Cloudflare.php file, and change the getData method to this:

PHP:
    public function getData($start, $end)
    {
        $return = [];

        try {
            for ($timestamp = $start; $timestamp <= $end; $timestamp = $timestamp + 86400)
            {
                $stats = $this->app->repository('DigitalPoint\Cloudflare:Cloudflare')->getStats($timestamp);

                foreach ($stats as $name => $counter)
                {
                    $return[$name][$timestamp - $timestamp % 86400] = $counter;
                }
            }
        }
        catch(\Exception $e) {}
        
        return $return;
    }

...does that fix it for you? (just adding the try/catch there)
 
If you go into the DigitalPoint/Cloudflare/Stats/Cloudflare.php file, and change the getData method to this:

PHP:
    public function getData($start, $end)
    {
        $return = [];

        try {
            for ($timestamp = $start; $timestamp <= $end; $timestamp = $timestamp + 86400)
            {
                $stats = $this->app->repository('DigitalPoint\Cloudflare:Cloudflare')->getStats($timestamp);

                foreach ($stats as $name => $counter)
                {
                    $return[$name][$timestamp - $timestamp % 86400] = $counter;
                }
            }
        }
        catch(\Exception $e) {}
       
        return $return;
    }

...does that fix it for you? (just adding the try/catch there)
yup, that resolved the issue. The cron runs fine now
 
I just started testing the R2 feature of this add-on. We have DragonByte eCommerce installed and use SVG images for product icons, which are stored in \data\dbtechEcommerce\productIcons\0\.

Those SVG images do not get served from the Cloudflare bucket. The browser shows a broken image instead:
1691436437409.webp
If I change the SVG to a PNG, the new icon is displayed correctly.

In Cloudflare, I see the object type of PNGs defined as image/png, while that of SVGs is left undefined:

1691436906946.webp
 
Fundamentally it's down to SVG "images" being text files and various points in the request chain (Cloudflare as well as your browser) don't attempt to figure out that particular text file is really an image...

SVG "images" aren't really images at their core, they are text/XML files (you can open them in a text editor). R2 is nothing more than an object storage system that does not look at the filename (it's actually an object key, not a filename so it wouldn't be appropriate for Cloudflare to automatically set content-type based on the object key). It attempts to do it when it can based on the content of the object. But again... the content of SVG files are just text... and that's the problem.

That being said, if you want to work around it, you need to set the HTTP response Content-Type based on the object key/URL. You can do that if you want with Cloudflare's transform rules. See this post:

 
Back
Top Bottom