Pull Request resolves #48061 .

• I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.

Summary of Changes

Memcached can't list its own keys, so Joomla tracks cached items in a single permanent -index entry. store() append a new index record on every write (including every time a module's cache was regenerated after expiry), so the index grew unbounded. Once it passes Memcached's 1 MB item-size limit, index writes were silently dropped, and any items cached afterward were no longer tracked.

Clearing the cache does not work: The admin Clear Cache list and delete (getAll() / clean()) only act on the index. The untracked items are basically invisible, so they can't be removed

Only restarting Memcached helps because it is a full flush, which wipes everything regardless of the index.

Testing Instructions

This is hard to test since you need to hit the Memcached index limit. For example we have thousands of articles in our website, combined with a short cache time you should be able to exhaust the index space at some point to exhibit the bug.
If you are sure that the index is exhausted change a setting in one of your cache modules, then clear the Joomla cache manually.
You will notice that the module will not exhibit the changed setting, at least not until the normal caching time expires, no matter how many times you clear the cache.

Actual result BEFORE applying this Pull Request

Cached entries when using memcached won't be properly cleared on cache purge.

Expected result AFTER applying this Pull Request

Cached entries will be properly purged.

I also took the liberty to remove the (Experimental) tag on Memcached .- it has been there for 14 years.

Link to documentations

Please select:

• Documentation link for guide.joomla.org:

• No documentation changes for guide.joomla.org needed

• Pull Request link for manual.joomla.org:

• No documentation changes for manual.joomla.org needed