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.
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).