Define, “it”.I'd love to give users the ability to opt out of showing it to everyone but admins if they want.
Define, “it”.
Primarily the whole intent is that it’s viewed only by mods/admins. It’s not intended as a way for users to “show off” where they are located. Honestly, I’d remove the ability for normal users to see it.Ahh yes, my bad the Country Flag. Some users don't like the flag that's showing or just don't want people to know.
Primarily the whole intent is that it’s viewed only by mods/admins. It’s not intended as a way for users to “show off” where they are located. Honestly, I’d remove the ability for normal users to see it.
Basically it’s intended for the users that can see the underlying IP addresses of users (usually mods/admins).
Ya, it certainly can be done if you want, but there’s not a mechanism to hide it from certain users.We have a few sites with international users and it's super handy to show it. Just my 2c. though.
Just a dumb question about this - finally got around to trying this out in our test environment. We went with a separate bucket so we can easily purge the data and delete the bucket if it doesn't work out. Are we supposed to see this new bucket pop up in the R2 page of the addon, or will it be invisible in the ACP? Because I did not see it pop up when I added the config line.Yep, that should do it. You can go so far as to put all of internal_data into a single bucket, but there's a reason it doesn't work that way by default because there's folders in there that aren't really great candidates for cloud storage. Info on that over here.
You can use the same bucket you use for internal-data/attachments (if you want), but you don't have to. Any folder within internal_data can use the same bucket (not the case for the data bucket because it has different permissions designed for public access).
If you mean the stats, no… you wouldn’t see stats for things you added manually via config.php.Just a dumb question about this - finally got around to trying this out in our test environment. We went with a separate bucket so we can easily purge the data and delete the bucket if it doesn't work out. Are we supposed to see this new bucket pop up in the R2 page of the addon, or will it be invisible in the ACP? Because I did not see it pop up when I added the config line.
No idea, never seen it myself and I’m using R2.
is it exclusively that image?
Disabling the Presigned urls option solved all problems. Thanks a lot!Looks like you are trying to add an image by URL and that image is served with presigned URLs. Presigned URLs are only valid for the user they are given to (so the URL isn’t going to be valid for a user on a different IP address… like the server trying to fetch it).
Presigned URLs are also very short-lived. The error you got there says the URL expired.
Disable presigned URLs and it will probably work better for you.
I guess the code will be?
PHP:$config['fsAdapters']['internal-data/image_cache'] = function() { return \DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2::getAdapter('internal-data/image_cache', 'cf-bucket-name'); };
image_cache
folder on your local server to r2:your_bucket/image_cache
, unlike the data
and internal_data/attachments
links in the addon itself that expect to be in the root of those buckets as per the addon FAQ (or, y'know, without any directory prefix before the numbered folder prefixes, because "directories" don't technically exist in R2). I'm not sure why the inconsistency is there, but that threw me for a loop when I first tested it and old proxied images didn't work when I copied them over, but newly proxied ones did. It was only until I inspected the bucket in an S3 browser that I saw that XF had created a new "image_cache" directory inside the bucket.rclone copy /path/to/image_cache/ cloudflare:bucket/image_cache --progress --transfers=32 --checkers=32
We have no choice. Our VPS is limited to 80GB of storage - our image proxy needs to retain images indefinitely, and we amassed 15GB in just one day. We expect to be around 200GB total or ~2 million images. In order to get that amount of storage from our VPS provider, we would need to nearly quadruple our server costs to do so, or rely on our VPS provider's block storage which is nearly as expensive due to an unfavorable pricing structure. In our testing it's no slower than fetching the attachment images directly either.It’s also a terrible idea… just throwing that out there. The reason the addon doesn’t do it by default isn’t because it’s a bad idea, not because someone just didn’t think of it.
Imagine putting your browser cache off your computer and thousands of miles away on a remote server. That’s effectively what you are doing there. The cache will end up being slower than not having a cache. But if that’s something you are going for, for whatever reason.. have at it.![]()
Because we've lost over a million historical images linked to our site over the 15 years we've been around, including some that were so popular in our early days we still regularly get complains and requests to "fix" them. We're tired of relying on random external image hosts that our members use for various reasons, that then change policies and delete the images over time, causing our member's comics and screenshot runs to be lost forever, often without the original author's knowledge. And don't get me started on the number of people who still think Discord is a good place to host images with the current 24 hour limit on their URLs, that's a whole other restoration project we need to get moving on before they start purging images for good there too...And frankly I personally am just sick of seeing this all over the forum when I browse old threads:Why does the image proxy need to retain forever? By definition right there, it’s no longer a “cache”.
We use essential cookies to make this site work, and optional cookies to enhance your experience.