[lancewillett]

Bug fix

JavaScript change in two avatar URL builders, plus QUnit tests.

When a site's avatar_default option is gravatar_default, o2 builds Gravatar URLs with d=gravatar_default. That is not a Gravatar default ID. WordPress core treats the value as the Gravatar logo and leaves d out (get_avatar_data() in wp-includes/link-template.php). o2 now does the same:

• getUserFor() in js/collections/users.js
• onBlurCommentorEmail() in js/views/comment.js

Other default values, such as identicon and mystery, still send d.

Rationale

o2 should send the same avatar URL WordPress core sends, rather than relying on Gravatar to accept a value it does not define. WordPress.com's two copies of o2 get the same change.

Testing this change

• npx grunt qunit passes. The two new tests in tests/qunit/avatars.js fail on master at the gravatar_default assertions.
• npx grunt lint passes.
• In a wp-env site with p2-breathe, o2 enabled and avatar_default set to gravatar_default, the o2-rendered avatars have no d. On master they end in ?d=gravatar_default.
• With avatar_default set to identicon, the avatars still end in ?d=identicon.

The logged-out comment form template adds &s= to the avatar URL. With gravatar_default it now renders https://gravatar.com/avatar/&s=32. Gravatar returns the same logo for it, at the default 80px instead of 32px, which the <img> width and height scale down.

Definition of done

• Both builders omit d for gravatar_default
• Other default values keep d
• New QUnit tests fail without the fix and pass with it
• CI green
• Reviewed

🤖 Generated with Claude Code

[bor0]

Looks good, matches core's get_avatar_data(). One small thing: logged-out-create-comment.php appends &s= to the URL, so with gravatar_default you get avatar/&s=32 and the 80px logo. With a real hash, <hash>&s=32 returns the Gravatar logo instead of the person's avatar, so it might be worth having the template choose ? or & now.