Hi
@AndyB
I know that this resource is deleted but I believe you still provide and recommend this add-on to your customers. Which is fine.
However, the add-on in its current form is not (and will not be) compatible with XenForo Cloud but as a more general point I'm highly confused by some of the design decisions.
Primarily my comments pertain to the following options:
The first path option is entirely redundant. You can establish the "board path" within XF itself using:
Code:
$boardPath = \XF::getRootDirectory();
Therefore this option should be removed and you should adjust the code to detect it automatically.
I'm also somewhat confused by the temporary path option. Why does it need to be outside of the document root? XF already has a system for managing temporary files and directories, and an appropriate parent directory for these to exist, specifically
internal_data/temp.
You can do something like this:
PHP:
$tempDir = \XF\Util\File::createTempDir();
$tempFile = \XF\Util\File::getTempFile();
// both of the above directories/files are *automatically* cleaned up at the end of the request
// ...
$response = $client->get($sourceLink, ['save_to' => $tempFile]);
// ...
$res = $zip->open($tempFile);
// ...
$zip->extractTo($tempDir);
$zip->close();
// you can then continue mostly as normal
$src = $tempDir . 'upload/src/addons/Andy/' . $addonTitle;
// etc...
This approach makes much more sense, is more compatible, automatically cleans up temporary files, and allows you to remove both of those redundant options making it easier for people to use.
I'm about to advise a XenForo Cloud customer that they can no longer use this add-on, so I hope you're able to accommodate these changes.
The advice in this post may be useful if you've taken similar approaches in other add-ons.
