Avatar Rendering Upon Fresh Install

Found this after a fresh install and have a fix for it with some updated logic. I will post the details here, with the fix. If you would like I can create an issue, then the PR as the fix.

Issue:

Avatar Regression on Fresh Installs

Problem:
After cloning main, running docker compose up, migrating, and creating the default admin account, the navbar avatar on / appears broken and the console logs Cannot read properties of null (reading '0'). Loading /admincp/ produces a 500 trace in misago/users/templatetags/misago_avatars.py. Every code path assumes user.avatars is a populated list, but fresh accounts have avatars = None, so both Django and React crash.

Fix outline:
1. misago/users/templatetags/misago_avatars.py – short-circuit to the blank avatar when user.avatars is falsy to keep templates safe.
2. misago/users/views/avatarserver.py – treat user.avatars or []; if the list is empty, immediately redirect to blank_avatar.
3. frontend/src/components/avatar.js – ensure getSrc only resolves thumbnails when user.avatars is a non-empty array, and make resolveAvatarForSize fall back to the blank placeholder when nothing exists.
4. Rebuild the frontend bundle so browsers receive the hardened component.

Verification:
Fresh install → login as admin → navbar avatar now renders (real image after thumbnails are generated, otherwise blank placeholder). /admincp/ loads without errors, and direct requests to /media/avatars/...png succeed.

Let me know if you would like me to create an issue then a PR. This seems to have fixed it for me. The logic is sound.

After some conversations in Discord here is what I posted there. This is technically a bug in the new main release branch:

Misago avatar regression recap (Nov 29, 2025)

main branch
Fresh docker compose up -d in Misago/.
Visit http://localhost:8000/ -> immediate 500.

Logs show IndexError: list index out of range from misago/users/templatetags/misago_avatars.py and misago/users/views/avatarserver.py because user.avatars is empty out-of-the-box.

Running dynamic.set_avatar(user) in Django shell regenerates an avatar and the site recovers, so the code needs guards/tests to handle empty avatar lists rather than assuming at least one entry.

0.39 branch

docker compose up -d in Misago-0.39/ works fine out of the box; fixtures populate user.avatars.

To reproduce the crash I manually cleared avatars via Django shell:
from misago.users.models import User
user = User.objects.get(username="admin")
user.avatars = []
user.save(update_fields=["avatars"])

After saving [], the same 500s and stack traces appear until I regenerate avatars with:
from misago.users.avatars import dynamic
dynamic.set_avatar(user)

So 0.39 is stable for normal installs; the bug only surfaces when avatars data is empty (e.g., manual edits or corrupted rows).

Current state
Both stacks are up, avatars regenerated, homepage returns HTTP 200 (verified via Invoke-WebRequest http://localhost:8000/ -UseBasicParsing).
Logs clean post-regeneration.

Next steps
Guard the avatar template tag and avatar server to fall back to the default silhouette when user.avatars is empty.
Add regression tests covering users without avatars.
Decide whether fixtures should always seed avatars or rely solely on the above fix.