Avatar source has changed to Discourse servers on rebuild/update

AI-generated summary

After upgrading from Discourse 1.4b10 to 1.4.0.beta12, OnceWas noticed that letter avatars are now served from https://avatars.discourse.org instead of locally, which affects API responses and breaks avatar rendering in external systems like WordPress. sam and riking explain this is intentional — a performance optimization to reduce server CPU load by offloading avatar generation to a free, CDN-backed service. codinghorror confirms the motivation: excessive CPU usage from on-demand avatar rendering. OnceWas acknowledges the benefit and plans to adapt their code, but temporarily disables the service due to inconsistent avatar URL formats in the API: letter avatars return full URLs, while custom avatars return relative paths (e.g., /user_avatar/...). sam suggests a simple fix — prepend the domain if the URL starts with / — which OnceWas humorously admits was obvious after a long coding session.

I just rebuilt my development Discourse instance from 1.4b10 to v1.4.0.beta12, and the Discourse-generated letter avatars are now getting pulled from https://avatars.discourse.org. For example, the URL for my letter avatar for administrator is now https://avatars.discourse.org/letter/a/f9ae1b/32.png.

On my production server, which is on 1.4b9, the avatar URL is /letter_avatar/administrator/32/5_fcf819f9b3791cb8c87edf29c8984f83.png

My API calls to my 1.4b12 server also show the discrepancy in the avatar URLs:

...
["users"]=>
  array(2) {
    [0]=>
    object(stdClass)#630 (3) {
      ["id"]=>
      int(19)
      ["username"]=>
      string(13) "administrator"
      ["avatar_template"]=>
      string(56) "https://avatars.discourse.org/letter/a/f9ae1b/{size}.png"
    }
    [1]=>
    object(stdClass)#629 (3) {
      ["id"]=>
      int(-1)
      ["username"]=>
      string(6) "system"
      ["avatar_template"]=>
      string(52) "/user_avatar/ask.twobydev.com/system/{size}/17_1.png"
    }
  }
  ["user"]=>
  object(stdClass)#659 (29) {
    ["id"]=>
    int(19)
    ["username"]=>
    string(13) "administrator"
    ["avatar_template"]=>
    string(56) "https://avatars.discourse.org/letter/a/f9ae1b/{size}.png"
    ["name"]=>
    string(17) "Two by Fore Admin"
    ["last_posted_at"]=>
    string(24) "2015-08-20T16:57:57.794Z"
    ["last_seen_at"]=>
...

Seems odd - and definitely not ideal for all involved - if all my letter avatars are getting pulled from Discourse’s CDN.

1.4b12:

1.4b9:

It’s ideal, definitely ideal see

https://meta.discourse.org/t/optimizing-letter-avatar-rendering/33082

If you don’t like the new default disable it in your site settings

[quote=“sam, post:2, topic:33416”]
It’s ideal, definitely ideal see
[/quote]Yup - this is going to save your server a ton of CPU time…

Just caught up on the avatar discussion. Fascinating.

Thanks for the response, I’ll stick with the new avatar service, and modify the API handling in my code to work with the new URLs.

Yes the motivation was we noticed we were spending way too much CPU time generating avatars… the avatars.discourse.org is a free service behind CloudFlare CDN to speed up all Discourse instances.

I had to disable the service temporarily, at least until I can figure out a reliable way to parse the JSON returned by the /users/<USERNAME>.json API endpoint, to determine whether a user has provided their own avatar.

The value returned by $json->user->avatar_template is not in a consistent format. If the user has a letter avatar, the value is https://avatars.discourse.org/letter/r/7cd45c/{size}.png, but if the user has specified their own avatar, the format is /user_avatar/<SITENAME>/<USERNAME>/{size}/35_1.png.

I’ll need to figure out a way to determine when to append the domain name (we use the API to show avatars in Wordpress).

That is kind of trivial … if it starts with / prepend the domain name :slight_smile:

When you’ve been starting at a console screen for 12 hours, things seem less trivial :smile: