[Bug]: Single letter avatars in Nextcloud 24 have become all white icons in Nextcloud 25 on Alpine Linux with imagemagick installed #34755
Comments
e-caste
added
0. Needs triage
|
Update: it's not the exact same image, each image is slightly different. 4 examples:
Looks like the avatar generation process completes, but does not work correctly. Is there any |
|
Dark avatars (same URL but adding
They are slightly different like the white ones, but still wrong since they don't have the foreground letter. |
|
I am also having this issue when upgrading to Nextcloud 25. |
|
I have the same issue. Here an example image for darkmode.
|
|
All the icons are white and not distinguishable. Maps sometimes displays an error message and if that appears i cannot remove that white modal window. Did you guys miss integration testing before launching 25? |
|
Same issue with text avatars since upgrading to 25 RC3, can’t find any solution. |
|
The reason is that the icons are white on a transparent background which has a white background. If i change the background color for |
PVince81
added
1. to develop
|
Can't reproduce The related change is likely #33752 but the code doesn't look problematic, any idea what could cause this @CarlSchwan? |
|
Commenting out https://github.com/nextcloud/server/blob/v25.0.0/lib/private/Avatar/Avatar.php#L136 seems to produce the same results as in #34755 (comment) so this seems like an issue with fonts Could you provide your |
|
I have tried a few things and it seems to be a problem with ImageMagick. For me, the problem can be solved quite easily if I don't have the image converted to a PNG. For this I disabled the following line: https://github.com/nextcloud/server/blob/v25.0.0/lib/private/Avatar/Avatar.php#L138 My result: If you search the internet there are always many different problems with ImageMagick and SVGs. |
|
@szaimen if the function returning |
|
Ah right, thanks! |
|
i saw lately that a user on Mac had the grey background and the icons were visible. i use Ubuntu and another user had Windows - both having a white background with no icons displayed. |
|
Not resolved in NC 25.0.1 |
|
Can everyone confirmed they have imagick enabled? You can check that with the admin settings page |
|
I really don't understand the nextcloud modus operandi. This is not fixed. Unless an admin finds this thread, then reads @schleyk's comment, and then comes up with a way of accomplishing this in a reasonable manner, he will wonder until nextcloud v99. A proper fix means nextcloud informs the admin of the problem and offers to regenerate all relevant avatars. It's just a small, inconsequential bug, but the way this lingers more than half a year, across a (broken) v26, and still isn't proper, all while adding buzzwords upon buzzwords in marketing, is maddening. Since that's not going to happen judging from the record-breaking breakage since owncloud days, here's a script for admins who want to get this over with: #!/usr/bin/env bash
# run from data/appdata_xxx/avatar folder
set -euo pipefail
while read -r folder
do
if [[ -f "${folder}/generated" ]]; then
rm -rf "${folder}"
fi
done <<<"$(find . ! -path . -type d)"Thankfully the 'generated' file exists, so you don't have to manually fuck around. This leaves user-uploaded avatars alone. Even this is not a 'fix'. On the next login, nc will generate only one of the required files. The small one in the upper right won't be regenerated until the user attempts to change his name. There doesn't seem to be an occ command that would trigger it, so you have to tell the users who care to edit their name for a second.
Neither files:scan-app-data nor changing the user's name back and forth via occ regenerate both, before anyone wastes time trying. It has to be inside the user's own account panel. For reference, the files that need to exist: |
|
I think the issue got closed mainly because the merge request mentions "Fix #34755" as a trigger keyword and GitHub automates on that. I agree though, I did mention in my post that I had to clear the avatar cache, otherwise Nextcloud will just continue to use the broken avatar renders until a user change triggers a rerender. I was acting on a from-scratch test setup so I was able to just wipe everything instead of selectively. I propose that this issue is reopened and the reuse of broken avatars be solved before closing it again. The solution can range anywhere from directly having a check in the code for avatars that are known to be generated with faulty code and automatically rerendering or notifying the admin based on this (some flag in the database similar to |
|
@szaimen This is still a problem, as users reported that the avatars are not regenerated. |
|
The problems is technically solved (at least for new users). After updating people need to regenerate the avatars. |
|
Yes, but how can they do that? As far as I understand the server just caches the avatars and the cache would need to cleared to fix this. |
|
A migration step could be added that checks if imagick rsvg is present and clean all avatars in appdata once. But I dont feel capable to implement that. |
|
After running the migration step, cleaning the browser cache will automatically regenerate the avatars. |
|
Telling all users to just clear their browser cache is not an option. We need some solution for this. |
|
This wont work as the migration step is missing as well. |
|
I adapted @elandorr's script because it would delete the whole folder breaking the avatar generation process instead of only deleting the pngs: #!/bin/bash
set -euxo pipefail
while read -r folder
do
if [[ -f "${folder}/generated" ]]; then
rm "${folder}"/*.png
fi
done <<<"$(find . ! -path . -type d)" |
|
@provokateurin For the record: that wasn't necessary here. It creates the folders just fine. Just not when you want it. @ the previous comments: NC could 'cache-bust' these no problem; write a few lines to regen, add a timestamp to the request. In a later update, this 'one-use-code' could be removed, but who am I kidding, it's 2023, who cares. If it weren't a multi-million $ business, I'd fix it... But really, it's just avatars. Be happy, if your core works, and don't update too soon lest you challenge the beast. |
|
@szaimen I found https://github.com/nextcloud/server/blob/master/lib/private/Repair/ClearGeneratedAvatarCache.php that already clears the avatar cache given a version. If we bump this version to the currently released version it should regenerated all avatars right? We would have to backport it to 25 and 26 to fix it everywhere, right? |
|
I am not sure if this works. In the end the repair job comes here and runs only one time iirc: server/lib/private/Avatar/AvatarManager.php Line 161 in 53957cf |
|
To my understanding it selects the users that have a generated avatar and just deletes their whole avatar folder. Afterwards it sets the generated value to false. I assume this will cause the avatar to be regenerated? I mean at that point they have no avatar anymore, so the server should create one for them, right? |
|
I think the clearcache only runs once for each user globally since it sets the value for each user to false at the end of the job, no? server/lib/private/Avatar/AvatarManager.php Line 169 in 53957cf |
|
But maybe I am wrong? |
|
Judging from server/lib/private/Avatar/UserAvatar.php Line 252 in 53957cf |
|
Ah that makes sense then. So it will run whenever the maintenance:repair is executed? In that case, what is missing then? Only clearing the avatars in the browser cache? |
|
Wouldn't the avatars in the browser cache get invalidated once the avatars on the server are regenerated since they will have a different etag? Not sure how this works. I think to fix it we just need to adapt the job to run when upgrading from any of the currently supported versions so that on the next release all generated avatars are cleared. |
|
Based on my testing it looks like there is some version applied. However not sure how and when it gets increased. The link looks like this: |
|
You guys could use setDisplayName to look for clues. If a user changes his name in settings, it reliably recreates both/all pics. increaseCacheBuster also sounds related. |
|
The ?v= parameter comes from server/lib/private/Avatar/UserAvatar.php Lines 194 to 195 in d946256 |
provokateurin
added
2. developing
Bug description
Before updating to Nextcloud 25, some of my cloud users had letter avatars (e.g. an A on a colorful background if the name was Abcde). Now all avatars have this white image (512x512):
I have:
imagemagick(I'm using this Dockerfile)occ preview:reset-rendered-texts(this command was introduced with this commit, but is there any opposite command to regenerate the avatars?),occ preview:generate-all,occ preview:pre-generate, andocc preview:repairocc files:scan --all,occ files:scan-app-data,occ files:repair-treeSteps to reproduce
Expected behavior
The text avatars are shown correctly.
Installation method
Community Docker image
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Nginx
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 22.2.3 to 23.0.1)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
{ "system": { "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ ***REMOVED SENSITIVE VALUE*** ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "pgsql", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbtableprefix": "oc_", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "log_type": "file", "logfile": "\/var\/log\/nextcloud\/nextcloud.log", "loglevel": "2", "mail_smtpmode": "sendmail", "remember_login_cookie_lifetime": "7200", "log_rotate_size": "10485760", "trashbin_retention_obligation": "auto, 180", "versions_retention_obligation": "auto, 365", "simpleSignUpLink.shown": "false", "memcache.local": "\\OC\\Memcache\\APCu", "memcache.locking": "\\OC\\Memcache\\Redis", "filelocking.enabled": true, "redis": { "host": "***REMOVED SENSITIVE VALUE***", "password": "***REMOVED SENSITIVE VALUE***", "port": ***REMOVED SENSITIVE VALUE*** }, "logtimezone": "Europe\/Rome", "htaccess.RewriteBase": "\/", "enable_previews": true, "enabledPreviewProviders": { "11": "OC\\Preview\\PNG", "12": "OC\\Preview\\JPEG", "13": "OC\\Preview\\GIF", "14": "OC\\Preview\\BMP", "15": "OC\\Preview\\MarkDown", "16": "OC\\Preview\\MP3", "17": "OC\\Preview\\TXT", "18": "OC\\Preview\\Movie" }, "preview_max_x": "2048", "preview_max_y": "2048", "jpeg_quality": "60", "maintenance": false, "app_install_overwrite": [ "drawio", "end_to_end_encryption", "files_external_dropbox", "unsplash", "groupfolders", "onlyoffice", "twofactor_webauthn", "breezedark", "deck", "fulltextsearch" ], "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***", "overwriteprotocol": "https", "apps_paths": [ { "path": "\/var\/www\/html\/apps", "url": "\/apps", "writable": false }, { "path": "\/var\/www\/html\/custom_apps", "url": "\/custom_apps", "writable": true } ], "default_phone_region": "IT", "instanceid": "***REMOVED SENSITIVE VALUE***", "theme": "", "version": "25.0.0.18", "mail_sendmailmode": "pipe", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_domain": "***REMOVED SENSITIVE VALUE***", "memcache.distributed": "\\OC\\Memcache\\Redis", "updater.secret": "***REMOVED SENSITIVE VALUE***", "data-fingerprint": "***REMOVED SENSITIVE VALUE***" } }List of activated Apps
Nextcloud Signing status
Nextcloud Logs
No response
Additional info
The white text avatar is downloaded from Nextcloud Talk iOS and Nextcloud Talk web independently. I can also check the avatar picture by going to https://my.cloud.tld/index.php/avatar//96.
The text was updated successfully, but these errors were encountered: