[Critical] Lack of Cache Configuration in Avatar Package

[therezor]

Problem

The avatar package has a major problem with caching. It caches the generated avatars forever and does not provide any way to configure or disable the cache. This is bad practice and creates serious issues for developers.

Key Issues:

1. Cache Forever:
   The package caches avatars indefinitely. This means if you change settings like colors, the changes will not take effect because the old cached version is always used.

2. No Cache Control:
   There is no option to:

   • Set cache duration.
   • Disable the cache.

3. Bad Cache Keys:
   The cache keys do not have a prefix, which makes it hard to manage or flush specific cache entries. This can cause conflicts with other parts of the application.

Example Code

I used the following code to generate an avatar:

$logo = Avatar::create('Example')
    ->setDimension(256)
    ->setFontSize(122)
    ->setShape('square')
    ->setBackground('#333333')
    ->setForeground('#FFFFFF')
    ->toBase64();

What I Expected:

The avatar should have a background color of #333333 and a foreground color of #FFFFFF.

What Happened:

The changes to the colors did not work because the result was cached forever, with no way to flush or disable the cache.

Why This Is a Big Problem

• Caching Forever Is Bad Practice:
  Developers need control over the cache. Caching forever without any configuration option makes the package unreliable.

• Cache Key Issues:
  Cache keys without a prefix make it hard to clear the cache, especially when using multiple packages with the same caching system.

Suggested Fixes

1. Add Cache Configuration:

   • Allow developers to:
     • Set cache duration (e.g., in seconds, minutes, or hours).
     • Disable caching completely if needed.

2. Add Cache Key Prefix:

   • Use a unique prefix for cache keys (e.g., avatar_) to make them easier to manage.

[therezor]

I've studied package code and found that cache is used only for base64.
Why do we even need that? It can cause potential issues, so I suggest drop caching as it will remove complexity. If caching needed developer can implement as he wants.

This issue also is related to:
#131
#19
#149

[uyab]

Droping cache will cause breaking changes. I suggest to make cache more configurable.

[therezor]

Droping cache will cause breaking changes. I suggest to make cache more configurable.

it will, but take in account that current implementation is broken. Can be in next major version release