Skip to content

Custom AVATAR_URL and bookstack:refresh-avatar result in default user_avatar.png #5868

@lukoerfer

Description

@lukoerfer

Attempted Debugging

  • I have read the debugging page

Searched GitHub Issues

  • I have searched GitHub for the issue.

Describe the Scenario

We want to customize the avatars of our users in our BookStack instance to a solution hosted in our internal network. We found a small project that provides a web server configuration to serve some prepared images in a similar way as the Gravatar API. After setting up the web server we changed the variable AVATAR_URL in the .env file of our BookStack instance to the URL of this web server, so it basically looks like this:

AVATAR_URL=https://avatars.mycompany.com/avatar/${hash}?s=${size}&d=identicon

Afterwards, we try to refresh the avatars of our users by calling the following command:

php artisan bookstack:refresh-avatar --email=user@mycompany.com -f

In the output of the command it shows that BookStack is trying to fetch an avatar image from avatars.mycompany.com and the command finishes successfully and without an error message.

However, the avatar image that we can fetch from the address using the browser does not show in BookStack. Instead for all users with a mail address that we pass to the command above the avatar image in BookStack changes the avatar image changes from the colorful generated image to the default avatar image {BASE_URL}/user_avatar.png. So it seems like the command has an effect, but BookStack is not able to process the image provided by the web server and therefor falls back to the default image. Are there any hidden requirements to the images provided via the AVATAR_URL?

When changing the AVATAR_URL so that no images are provided via the URL, the command bookstack:refresh-avatar actually shows some error message that the image could not be fetched. In this case, the avatar image remains the colorful generated image.

Exact BookStack Version

v25.07.3

Log Content


Hosting Environment

We first encountered this issue in an older version of BookStack that was running on PHP 8.1.
Since we wanted to make sure that the issue is not already fixed in a newer version of BookStack, we updated our instance to the newest version v25.07.3 and also updated PHP to version 8.3, which was necessary because BookStack v25.02 and higher requires at least PHP 8.2.
We installed (and updated) BookStack manually using Git on a virtual machine based on Ubuntu 22.04 and with an Apache2 proxy.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions