![[DigitalPoint] App for Cloudflare®](/community/data/resource_icons/8/8750.jpg?1692633961){kind=icon}
[DigitalPoint] App for Cloudflare® 1.8.8
- Thread starter digitalpoint
- Start date
TPerry
Well-known member
Taken care of WELL before the add-on was installed. Not a neophyte in installing add-ons and checking instructions before doing so.
The point being I don't use the R2 features.... but when I install the latest add-on version I have problems... revert to the prior version and those issues become non-existent. And they appear to be directly related to serving of images (which the R2 function would involve). It was to the point I could not upload images and attach into a post Could that have been a setting I missed... yep.... but if so, that needs to be detailed in the documentaiton.
Last edited:
MattW
Well-known member
Not sure if this is something really obvious missing, but the bucket that was created by the addon for the data directory, is showing an error on the avatars.
Domain access was automatically configured:
But Public Access wasn't. Should that have automatically been set to Allows as well? I've since enabled it, but it's still showing the above error.
If I remove the cache buster string on the end, it loads:
However, the original R2 setup I did using the XenForo addon works:
Domain access was automatically configured:
But Public Access wasn't. Should that have automatically been set to Allows as well? I've since enabled it, but it's still showing the above error.
If I remove the cache buster string on the end, it loads:
However, the original R2 setup I did using the XenForo addon works:
digitalpoint
Well-known member
It should not do anything with R2 unless you actually enable it, so something else is going on. Are you using any fsAdapters defined in your config.php? If so, which?
digitalpoint
Well-known member
The config looks okay, can you confirm the paths of the objects in your bucket are correct?
If you change the cache busting string (rather than remove it), does it work? Wondering if it’s a caching issue itself.
MattW
Well-known member
Everything looked OK. I've deleted everything, and I've started it again. Just re-copying over the /data/ directory from the old bucket and will re-test.
digitalpoint
Well-known member
Want to send me a screenshot of some of the files in going into the data bucket (can send privately)? The file listing I in Cloudflare interface would work. If you are moving them the same way as the first time, I suspect it’s not going to be any different than the first time.
MattW
Well-known member
digitalpoint
Well-known member
Maybe it's working? I manually checked the URL you gave before where it would work without the cache busting and not work with, and it seems to be working both ways at this point:
Only thing I can think of is maybe it was requested initially before it was there, cached on Cloudflare's side and then subsequent try for that exact URL (with the same cache busting string that was cached), was served from cache. If that was the case it probably would have been as simple as updating the cache busting string by editing a CSS file or in the admin (just adding a space would do it).
Only thing I can think of is maybe it was requested initially before it was there, cached on Cloudflare's side and then subsequent try for that exact URL (with the same cache busting string that was cached), was served from cache. If that was the case it probably would have been as simple as updating the cache busting string by editing a CSS file or in the admin (just adding a space would do it).
MattW
Well-known member
Yeah, it does appear to be working now. I did also notice another issue, which might have been compounding it. I previously had the lscache plugin installed, which was disabled, but still had the caching settings in .htaccess (only noticed when I could see broken images as a guest, but then working when logged in). I've removed all that, and also purged all the cache with Cloudflare.
Just putting the internal_data/ folder into R2 now.
Just putting the internal_data/ folder into R2 now.
digitalpoint
Well-known member
It's not an API issue. The worst that would happen if someone didn't update their API permissions would be if you tried to use something that required permissions you didn't have, you would get an error about insufficient permissions. So no... you did not do something wrong even if you didn't give it the new permissions.Taken care of WELL before the add-on was installed. Not a neophyte in installing add-ons and checking instructions before doing so.
View attachment 279520
The point being I don't use the R2 features.... but when I install the latest add-on version I have problems... revert to the prior version and those issues become non-existent. And they appear to be directly related to serving of images (which the R2 function would involve). It was to the point I could not upload images and attach into a post Could that have been a setting I missed... yep.... but if so, that needs to be detailed in the documentaiton.
I've been looking at the error you received, and on the surface it looks like a normal permissions issue in the file system where the web server "user" didn't have write permissions (appears to just be during the install process). That being said, I'll assume it's not simply a coincidence and look at other possibilities.
One major change in particular with 1.4 is it adds the ability to have "sub-adapters" in XenForo's filesystem (allows just a certain folder to optionally be stored in it's own adapter). So even if it's not being used (if you didn't enable R2), the underlying functionality is available. I believe I implemented in a backwardly compatible way (and I haven't seen anyone else run into issues using R2 or not). But one thing to maybe check is if you have a different add-on that might be altering the
XF\FsMounts in a non-standard (not backwardly compatible) way. If you have development enabled in your admin, and you check Development -> Class extensions, do you have any addons that extend the XF\FsMounts class by chance? If you don't have development enabled, can you think of any add-on you might have that does anything with the filesystem or filesystem adapters?
digitalpoint
Well-known member
Honestly, I don't know what lscache, but the public subdomain for R2 (data.z22se.co.uk) isn't going to do anything on your server, so pretty sure an addon or .htaccess it couldn't affect anything on that subdomain. That subdomain is served exclusively by Cloudflare. You could unplug your server or blow up your data center and that subdomain would still work.
digitalpoint
Well-known member
Augh... gross. Fixed on this end for the next version (doesn't make much sense to push out a new version just for that).
(I have done both writing and programming so know whereof I speak. Sadly.)
MattW
Well-known member
Unmaintained - LiteSpeed Cache for XF2 - Community
Developed by LiteSpeed Technologies - the LiteSpeed Cache Plugin for XenForo 2 (LSCXF2) is a PHP-based plugin that communicates with your installation of LiteSpeed Web Server(LSWS) and its built-in page cache, LSCache. Because LSCache is built...
xenforo.com
It's working after removing that and purging the cache.
Chromaniac
Well-known member
just wondering if image_cache folder should be on r2 as well. maybe not because there are not many http only images to worry about 
. noticed the errors in backend because the folder did not have proper permissions once i moved the data back from old r2 bucket to local server 
. noticed the errors in backend because the folder did not have proper permissions once i moved the data back from old r2 bucket to local server
MattW
Well-known member
Although, I'm now getting flooded with these errors:
The file being called exists in R2
Code:
GuzzleHttp\Exception\ServerException: Server error: `HEAD https://REMOVED.r2.cloudflarestorage.com/z22se-attachments/attachments/275/275044-e67803dd3cbfaf83d3906f37b872112a.data` resulted in a `500 Internal Server Error` response src/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113
Generated by: Unknown account January 6, 2023 at 5:12 PM
Stack trace
#0 src/vendor/guzzlehttp/guzzle/src/Middleware.php(65): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response))
#1 src/vendor/guzzlehttp/promises/src/Promise.php(204): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response))
#2 src/vendor/guzzlehttp/promises/src/Promise.php(153): GuzzleHttp\Promise\Promise::callHandler(1, Object(GuzzleHttp\Psr7\Response), NULL)
#3 src/vendor/guzzlehttp/promises/src/TaskQueue.php(48): GuzzleHttp\Promise\Promise::GuzzleHttp\Promise\{closure}()
#4 src/vendor/guzzlehttp/promises/src/Promise.php(248): GuzzleHttp\Promise\TaskQueue->run(true)
#5 src/vendor/guzzlehttp/promises/src/Promise.php(224): GuzzleHttp\Promise\Promise->invokeWaitFn()
#6 src/vendor/guzzlehttp/promises/src/Promise.php(269): GuzzleHttp\Promise\Promise->waitIfPending()
#7 src/vendor/guzzlehttp/promises/src/Promise.php(226): GuzzleHttp\Promise\Promise->invokeWaitList()
#8 src/vendor/guzzlehttp/promises/src/Promise.php(62): GuzzleHttp\Promise\Promise->waitIfPending()
#9 src/vendor/guzzlehttp/guzzle/src/Client.php(182): GuzzleHttp\Promise\Promise->wait()
#10 src/vendor/guzzlehttp/guzzle/src/Client.php(95): GuzzleHttp\Client->request('head', 'https://f1d5fd5...', Array)
#11 src/addons/DigitalPoint/Cloudflare/Api.php(863): GuzzleHttp\Client->__call('head', Array)
#12 src/addons/DigitalPoint/Cloudflare/Api.php(766): DigitalPoint\Cloudflare\Api->makeRequest('head', 'attachments/275...', Array, true, 'z22se-attachmen...')
#13 src/addons/DigitalPoint/Cloudflare/League/Flysystem/Adapter/R2.php(146): DigitalPoint\Cloudflare\Api->headR2Object('z22se-attachmen...', 'attachments/275...')
#14 src/addons/DigitalPoint/Cloudflare/League/Flysystem/Adapter/R2.php(71): DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2->getMetadata('attachments/275...')
#15 src/vendor/league/flysystem/src/Filesystem.php(57): DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2->has('attachments/275...')
#16 [internal function]: League\Flysystem\Filesystem->has('attachments/275...', Array)
#17 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(431): call_user_func_array('parent::has', Array)
#18 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(395): League\Flysystem\EventableFilesystem\EventableFilesystem->callFilesystemMethod('has', Array)
#19 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(128): League\Flysystem\EventableFilesystem\EventableFilesystem->delegateMethodCall('has', Array)
#20 src/vendor/league/flysystem/src/MountManager.php(313): League\Flysystem\EventableFilesystem\EventableFilesystem->has('attachments/275...')
#21 src/XF/Entity/AttachmentData.php(228): League\Flysystem\MountManager->has('attachments/275...')
#22 src/XF/ControllerPlugin/Attachment.php(9): XF\Entity\AttachmentData->isDataAvailable()
#23 src/XF/Pub/Controller/Attachment.php(45): XF\ControllerPlugin\Attachment->displayAttachment(Object(XFMG\XF\Entity\Attachment))
#24 src/XF/Mvc/Dispatcher.php(352): XF\Pub\Controller\Attachment->actionIndex(Object(XF\Mvc\ParameterBag))
#25 src/XF/Mvc/Dispatcher.php(259): XF\Mvc\Dispatcher->dispatchClass('XF:Attachment', 'Index', Object(XF\Mvc\RouteMatch), Object(XF\Pub\Controller\Attachment), NULL)
#26 src/XF/Mvc/Dispatcher.php(115): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(XF\Pub\Controller\Attachment), NULL)
#27 src/XF/Mvc/Dispatcher.php(57): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#28 src/XF/App.php(2353): XF\Mvc\Dispatcher->run()
#29 src/XF.php(524): XF\App->run()
#30 index.php(20): XF::runApp('XF\\Pub\\App')
#31 {main}
Request state
array(4) {
["url"] => string(61) "/attachments/acdn-z22se-com_userpix_1125_cdr_500_1-jpg.19474/"
["referrer"] => bool(false)
["_GET"] => array(0) {
}
["_POST"] => array(0) {
}
}The file being called exists in R2
digitalpoint
Well-known member
It's one of the subfolders I was on the fence about. Here's why...just wondering if image_cache folder should be on r2 as well. maybe not because there are not many http only images to worry about
In theory, the image cache could be read/written to a lot, but the files are short lived, which means someone could run up their billable events quickly in Cloudflare (someone pops in 10 images to a post and now every time that post is viewed, you get +10 class A operations). To me, it would make more sense if it was in the data folder vs. the private internal_data folder (every read is done by the XenForo application and it's not going to be cached at the edge). Putting internal_data/image_cache doesn't really save time/latency because XenForo serves it, so the end-user's http request would still go through XenForo, which in turn would fetch it from R2 on the backend). Kind of the same logic for me for oembed_cache (short lived cache that is in the private internal_data folder).
That being said... I've built the system in a way where someone could put whatever folders (or all of internal_data) into R2 via XenForo's standard config.php changes for filesystem adapters if they really wanted.
digitalpoint
Well-known member
There's probably not a lot I can do about 5xx errors (those are server-side errors on Cloudflare's side). The API library I built does retry once if it gets a 5xx error, but it gives up if it gets it again.
That's (hopefully) something transient/temporary on Cloudflare's side. In all the testing and data migration I've done, I've only received a single 5xx error (which is what prompted me to have it transparently try again). Maybe something going on with Cloudflare's side because it's a new bucket somehow? Not sure to be honest. Is it something that's still happening?
