use unique name for cache folder

[Grotax]

• Resolves: Some feeds stopped being updated by cron #2325

Summary

We had multiple reports now of shared hoster environments where the updating of some feeds fail because they can't write to the temp directory.

One possible issue is that they can't write to /tmp at all (which is the default nextcloud uses).
Or that they can write to /tmp but for some reason the hoster allows all users to share /tmp.

This PR changes that in using the instance ID of Nextcloud a unique identifier that is stable.

Example from my dev instance:

root@31fa29494eed:/var/www/html# ls -l /tmp/news-oc2iqvwq927d/cache/
total 12
drwxr-x--- 2 www-data www-data 4096 Aug 22 16:50 feedFavicon
drwxr-x--- 2 www-data www-data 4096 Aug 22 16:42 feedLogo
drwxr-x--- 4 www-data www-data 4096 Aug 22 16:42 purifier

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Changelog entry added for all important changes.

[Grotax]

depends on #2328 since that required similar changes

[anoymouserver]

Sounds reasonable to use the instance ID for the name of the temp folder.

Since you use it in multiple places, have you thought about creating a utility for it so you don't always have to duplicate the code? (get paths, join and create them)

What I don't quite understand ... what is the cache of logos/favicons for, when each one is in the DB with the original URL and is also loaded by the clients by it?

[Grotax]

Favicon I'm not sure the library uses that cache without asking and will create a directoy on it's own if we don't provide one.

Logo, is because you said we should check the image if it actually is usable for new and if not we should fall back to the favicon. For example if the file is actually an image and if it is square I think.
And the cache is there so that we don't need to repeat that check every time.
We check for the local file, check the timestamp and ask the server if the file has changed since timestamp.
#1164 (comment)

Since you use it in multiple places, have you thought about creating a utility for it so you don't always have to duplicate the code? (get paths, join and create them)

Yea I will check that.

[anoymouserver]

Favicon I'm not sure the library uses that cache without asking and will create a directoy on it's own if we don't provide one.

I've looked through the code and it's caching the urls after followed redirections and, if used, the actual image file.
Your change improves and unifies the cache location, as it's currently cluttering the /tmp/ itself with url<md5> files. 👍
This obsoletes the global configuration here:

news/lib/AppInfo/Application.php

Line 143 in 17f0fc7

$favicon->cache(['dir' => $c->get(ITempManager::class)->getTempBaseDir()]);

Logo, is because you said we should check the image if it actually is usable for new and if not we should fall back to the favicon.

Interesting, I've forgot about this one 😄
As you've said the cache dir is used to allow checking the actual file and it isn't downloaded again if there is no change (as long as the remote server respects If-Modified-Since). The actual check result (size comparison, ..) isn't cached.

[SMillerDev]

I think this should also be suggested upstream as the default because we can't be the only app running into this.

[Grotax]

Favicon I'm not sure the library uses that cache without asking and will create a directoy on it's own if we don't provide one.

I've looked through the code and it's caching the urls after followed redirections and, if used, the actual image file.
Your change improves and unifies the cache location, as it's currently cluttering the /tmp/ itself with url<md5> files. 👍
This obsoletes the global configuration here:

news/lib/AppInfo/Application.php

Line 143 in 17f0fc7

$favicon->cache(['dir' => $c->get(ITempManager::class)->getTempBaseDir()]);

Logo, is because you said we should check the image if it actually is usable for new and if not we should fall back to the favicon.

Interesting, I've forgot about this one 😄
As you've said the cache dir is used to allow checking the actual file and it isn't downloaded again if there is no change (as long as the remote server respects If-Modified-Since). The actual check result (size comparison, ..) isn't cached.

Ah I didn't see the global config, makes more sense to adjust it there I think.