Chris2
Active member
2.1.2what version of XF are you using?
2.1.2what version of XF are you using?
So ya, I confirmed that method started being a thing in XF 2.2. I've changed the code on this end to no longer use it so it will be part of the next version. Alternately, you can upgrade to XF 2.2.2.1.2
To be more specific, it gives me an error the moment R2 for /data/ is enabled (the /data/ bucket serves files fine across the board). No errors if the /data bucket is disabled.I can’t think of a reason why it would. You get no error when the addon is disabled?
DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2.php
file and change the getMetadata() to this:public function getMetadata($path)
{
return array_merge(['path' => $path, 'type' => 'file'], $this->getApiClass()->headR2Object($this->getBucketByPathPrefix(), $path));
}
Just an update to confirm that yes the assets load and it does look like it was a temporary issue with Cloudflare.If you click on one of those you should be able to see the URL that someone was at to trigger it. If you visit one of those URLs, are you able to generate a new error or are things back to normal/working as expected?
Might be the same issue someone saw yesterday that cleared itself up: https://xenforo.com/community/threads/digitalpoint-app-for-cloudflare®.206176/post-1611157
But ya that's definitely a 5xx error coming from a Cloudflare server. I suspect it will work itself on it's own if it hasn't already, because like I said... a 5xx error means there's nothing different we can do on our side but the server is having an issue. 4xx errors are the ones we are able to change something to change the outcome.
Thanks. Hopefully the next version will be around the corner. Will upgrade to 2.2 one of these days, just so many moving parts that could break… Btw, is it simple to implement the code change to make the method work with 2.1.2?So ya, I confirmed that method started being a thing in XF 2.2. I've changed the code on this end to no longer use it so it will be part of the next version. Alternately, you can upgrade to XF 2.2.![]()
Don't assume template method is callable (fixes issue where XenForo addon installation process would give a temporary error when template modifications were enabled but class extensions are not yet)
The UI will let you select the same internal_data bucket if you want (if your stuff is already there, that's going to be the simple thing to do).@digitalpoint I see there is now an option to put xfmg in its own bucket. Previously this was hosted on the internal_data data.* bucket. Is it advisable to give it its own bucket for some reason?
It actually will only let me choose the attachments bucket and not the data* bucket, presumably because that has its own subdomain. Not sure, but the option is greyed out. No issue, will just move that to its own bucket using rclone syncThe UI will let you select the same internal_data bucket if you want (if your stuff is already there, that's going to be the simple thing to do).
The only upside to splitting it into it's own bucket would be if you wanted to see usage stats for just XFMG files (usage reporting is for buckets as a whole so there's no way to break the usage down if attachments and XFMG are in the same bucket). Beyond breaking down usage, there's no reason/need to be in a different bucket.
is /internal_data/xfmg supposed to be a valid XF folder?Are you sure you are looking at the right bucket? If there are xfmg files in the data bucket, you don't need to change anything. The interface only applies to internal_data/xfmg. Definitely don't move stuff from data to internal_data.
data = files intended for public access.
internal_data = files NOT intended for public access.
You can't move files between the data filesystem and internal_data filesystem (well you can, but it will break XenForo).
The interface doesn't let you select the data bucket for internal_data buckets (or vice versa) to prevent users from exposing their private (internal_data) files in an area that is used for public access (the data bucket/subdomain). For example if you were to be "lazy" and just use the same bucket for data and internal_data, you just exposed all your internal_data to the public (attachments, email DKIM private keys, etc.) Very bad.
We use essential cookies to make this site work, and optional cookies to enhance your experience.