[DigitalPoint] App for Cloudflare®

[DigitalPoint] App for Cloudflare® 1.8.2

No permission to download
Will have to check when I get back to a computer, but probably that method is 2.2 only. I guess disable guest page caching for the moment.
 
Any tool that supports S3 that supports it should be able to. Maybe rclone? Not sure if it supports mass delete, but I feel like it should.
 
Thanks.

Is there a way the Cloudflare add-on prevents style archive export (XML works fine)?

When it's enabled I get the following error when I try to export:

ErrorException: [E_WARNING] Undefined array key "type" in src/XF/Service/Style/ArchiveExport.php at line 117
  1. XF::handlePhpError() in src/XF/Service/Style/ArchiveExport.php at line 117
  2. XF\Service\Style\ArchiveExport->prepareFilesToCopy() in src/XF/Service/Style/ArchiveExport.php at line 219
  3. XF\Service\Style\ArchiveExport->build() in src/XF/Admin/Controller/Style.php at line 502
  4. XF\Admin\Controller\Style->actionExportArchive() in src/XF/Mvc/Dispatcher.php at line 352
  5. XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 259
  6. XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 115
  7. XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 57
  8. XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2483
  9. XF\App->run() in src/XF.php at line 524
  10. XF::runApp() in admin.php at line 13
 
I can’t think of a reason why it would. You get no error when the addon is disabled?
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.
 
Last edited:
If you open the DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2.php file and change the getMetadata() to this:
PHP:
public function getMetadata($path)
{
    return array_merge(['path' => $path, 'type' => 'file'], $this->getApiClass()->headR2Object($this->getBucketByPathPrefix(), $path));
}

Does that fix it for you (I don't have any exportable styles with external assets to test it on).
 
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.
Just an update to confirm that yes the assets load and it does look like it was a temporary issue with Cloudflare.
 
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. :)
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? :whistle:
 
This addon and Lazy Loader by Xon doing something funky, or? canEdgeCache is CF related?

  • ErrorException: Template error: [E_USER_WARNING] Method canEdgeCache is not callable on the given object (SV\LazyImageLoader\XF\Template\Templater)
  • src/XF/Template/Templater.php:1187

Stack trace​

#0 [internal function]: XF\Template\Templater->handleTemplateError(512, '[E_USER_WARNING...', '/home/boardga1/...', 1187)
#1 src/XF/Template/Templater.php(1187): trigger_error('Method canEdgeC...', 512)
#2 internal_data/code_cache/templates/l1/s0/public/helper_js_global.php(277): XF\Template\Templater->method(Object(SV\LazyImageLoader\XF\Template\Templater), 'canEdgeCache', Array)
#3 src/XF/Template/Templater.php(825): XF\Template\Templater->{closure}(Object(SV\LazyImageLoader\XF\Template\Templater), Array, NULL)
#4 internal_data/code_cache/templates/l1/s0/admin/helper_js_global.php(12): XF\Template\Templater->callMacro('helper_js_globa...', 'body', Array, Array)
#5 src/XF/Template/Templater.php(825): XF\Template\Templater->{closure}(Object(SV\LazyImageLoader\XF\Template\Templater), Array, NULL)
#6 internal_data/code_cache/templates/l1/s0/admin/PAGE_RUN_JOB.php(76): XF\Template\Templater->callMacro('helper_js_globa...', 'body', Array, Array)
#7 src/XF/Template/Templater.php(1652): XF\Template\Templater->{closure}(Object(SV\LazyImageLoader\XF\Template\Templater), Array, NULL)
#8 src/addons/MaZ/AUN/XF/Template/Templater.php(38): XF\Template\Templater->renderTemplate('PAGE_RUN_JOB', Array, true, NULL)
#9 src/XF/Admin/App.php(259): MaZ\AUN\XF\Template\Templater->renderTemplate('admin:PAGE_RUN_...', Array)
#10 src/XF/App.php(2281): XF\Admin\App->renderPageHtml('




<form acti...', Array, Object(XF\Mvc\Reply\View), Object(Nulumia\XFOptimize\XF\Mvc\Renderer\Html))
#11 src/XF/Admin/App.php(138): XF\App->renderPage('




<form acti...', Object(XF\Mvc\Reply\View), Object(Nulumia\XFOptimize\XF\Mvc\Renderer\Html))
#12 src/XF/Mvc/Dispatcher.php(404): XF\Admin\App->renderPage('




<form acti...', Object(XF\Mvc\Reply\View), Object(Nulumia\XFOptimize\XF\Mvc\Renderer\Html))
#13 src/XF/Mvc/Dispatcher.php(60): XF\Mvc\Dispatcher->render(Object(XF\Mvc\Reply\View), 'html')
#14 src/XF/App.php(2483): XF\Mvc\Dispatcher->run()
#15 src/XF.php(524): XF\App->run()
#16 admin.php(13): XF::runApp('XF\\Admin\\App')
#17 {main}

Request state​

array(4) {
["url"] => string(24) "/admin.php?tools/run-job"
["referrer"] => string(56) "/admin.php?tools/run-job"
["_GET"] => array(1) {
["tools/run-job"] => string(0) ""
}
["_POST"] => array(3) {
["_xfRedirect"] => string(93) "/admin.php?add-ons/install-from-archive-complete&batch_id=273"
["_xfToken"] => string(8) ""
["only_ids"] => string(5) ""
}
}
 
The latest version (1.5.4.2) should have resolved that.

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)
 
@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?
 
@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?
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).

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.
 
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).

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.
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 sync
 
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.
 
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.
is /internal_data/xfmg supposed to be a valid XF folder?

For some reason when I moved data/* to the R2 "data" bucket, xfmg was in DATA not INTERNAL_DATA

Now I am actually kinda confused here.

When I check internal_data locally I see:

addon_batch code_cache image_cache install-lock.php keys sitemaps
attachments file_check index.html js_cache oembed_cache temp
 
If you don't have an internal_data/xfmg folder, you don't need to do anything.

Now I'm wondering if that new option is even needed if XFMG doesn't store anything in internal_data. Honestly I was just going off what some users told me because I don't use XFMG or have a license for it myself.

Although this post implies it should be there (maybe):


This one too:


Either way, if YOU don't have anything in internal_data/xfmg, nothing you need to move. Definitely don't move data to internal_data.
 
Top Bottom