The old cache is only replaced when the categories are requested, so
on instances that use a menu without categories the 170 KB app config
value stayed and was still loaded on every request. A post-migration
repair step clears it when the app is upgraded.
If cache-categories was stored with a type other than mixed or array,
for example set by hand with occ, the typed read throws. Treat that as
a missing cache so it is refreshed instead of breaking the menu and the
settings page.
A cache belongs in Nextcloud's memory cache rather than in the app
config. Use the distributed cache (e.g. Redis) with a one-week TTL when
one is available; Nextcloud falls back to the local cache (APCu) when
only that is configured. Without any memory cache the lazy app config
value stays as the fallback. A leftover app config value is removed
when the categories are stored in the memory cache, and saving the
settings clears both.
The cache held the category names in all 96 app store languages
(about 49 KB), while an instance typically uses one or two. Keep only
English, the default language and the languages users have set, as the
two-letter codes the lookup uses; on a Dutch instance this is about
1.3 KB.
A user who switches to a language that is not cached yet sees English
names until the cache is refreshed after a week, or right away when an
admin saves the settings. The README mentions this.
The app store category cache (cache-categories) held the name and
description of every category in every language, about 170 KB, stored
as a regular app config value. Nextcloud loads all regular values of
all apps on every request, so this one value was read on every page
load. It was only refreshed with the "remove cache" button.
- Keep only the category ids and names, store the cache as a lazy
value so it is only loaded when categories are needed, and refresh
it after a week.
- Only load the categories where they are used: the menus with
categories, and the app list when custom categories are set.
- Save all settings in one request to a new admin endpoint, which
accepts only known settings, then clears the category cache and
changes the stylesheet cache key. The settings page sent one request
per setting and reloaded right after; with Nextcloud's short-lived
local config cache, the reloaded page could show a half-saved
configuration, so a change sometimes had to be made twice.
🔧 Problem: The Side Menu app was calling OC\Server::getAvatarManager(), which no longer exists in Nextcloud 32.
✅ Fix:
Injected IAvatarManager using Nextcloud’s public API instead of accessing it via OC::$server.
Updated the constructor to accept IAvatarManager, IUserSession, INavigationManager, and IURLGenerator.
Replaced all direct calls to OC::$server->getAvatarManager() and similar with the injected services.
This makes the app compatible with Nextcloud 32 and avoids deprecated internal method calls.
Signed-off-by: AndyXheli <andyxheli@gmail.com>
The current change is currently filling the nextcloud logs up with the error:
`Undefined array key \"HTTP_USER_AGENT\" at /srv/www/nextcloud/apps/side_menu/lib/AppInfo/Application.php#109`
This adds a check to ensure the index exists before read it.