-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Description
Modules let you generate image fields, which are filled by the application users. It's not enough.
In case of favicons, the application users can upload only one single favicon type.
We need to make the rest of the generating in the background.
For that, we need a new file object for favicons. In that way when this file is updated, all favicons are regenerated.
This feature needs modifications in TableFiles arhitecture.
The new FileFavicon::class would be a singular file, not a group. The difference would be that you can, optionally, specify a certain file name you want to receive.
Generated files needed:
- android-chrome-192x192.png
- android-chrome-512x512.png
- apple-touch-icon.png
- favicon-16x16.png
- favicon-32x32.png
- favicon.ico
- site.webmanifest
- this needs another storage location, a general one;
- it will be decided later.
So the names would be hardcoded. For this file type, the Arshwell user shouldn't be able to rename the files.
Note: this task is also related to #20, so we should finish that one first. Because some logic can affect also the proposed logic for favicons.
Note: this task is part of the milestone named Improve file storage management.
Example
use Arshwell\Monolith\FileStorage\AbstractFile;
class Logo
{
const FILES = [
'favicon_site' => [
'type' => AbstractFile::TYPE_FAVICON,
// ...
]
];
}use Arshwell\Monolith\FileStorage\FileFavicon;
$favicon = new FileFavicon(..., ..., 'favicon_site');
/**
* Update will not generate one single file anymore. But all needed files.
* It should also generate the site.webmanifest file.
*/
$favicon->update(...);
/**
* With a 3rd param it would be an idea to look for a certain filename.
*/
$favicon->url(..., ..., 'favicon-32x32.png');Arshwell Version
0.*