WordPress avatar missing from comments: restore the profile photo

Check which avatar is missing and where

Your WordPress profile shows the correct photo. Yet your comment below a post displays a silhouette. Other comments do not all behave the same way. This difference is a better starting point than a general avatar-service failure: the profile photo, post-author photo and comment photo may be requested by three different components. The comment itself may be fully published and readable. Its status and moderation behavior do not reveal where its image comes from.

Record exactly what you see. A silhouette or generated figure is a fallback image. An empty frame, broken-image icon or image disappearing at one width instead suggests a loading or layout problem. If no image location exists for any comments, check display settings and the template rendering the list. If only some portraits are replaced, start by comparing identities and sources. Choosing a new default avatar may change everyone's silhouette without repairing any portrait.

Work on a copy and compare three cases: an affected comment, a comment displaying the correct avatar and, if your site accepts them, a guest comment that should remain without a custom portrait. Record the post, comment number in private notes, display type and test time. Do not include email addresses or full avatar URLs in a screenshot for sharing. A URL may contain an identifier derived from the address or a service token. When a portrait is deliberately local, an external request may itself indicate that the correct source was not selected.

• Image visible in the profile but a silhouette in one specific comment: check the account linked to that comment and its image source.
• No portraits and no image locations in comments: check the general option and comment template.
• Correct image requested but loading fails or the frame is hidden: check the browser and image delivery before changing a profile.

Route 1: check settings and the identity used by the comment

This route suits native WordPress avatars or cases where you do not know which plugin supplies them. In Réglages > Discussion, find the Avatars section. Record the display option, maximum rating and default avatar. In the native implementation, the display option can prevent get_avatar() from producing an image. A builder or plugin may have its own settings. Do not change the rating to permit images you do not want to display: first check with its owner whether the test portrait meets site rules.

For Gravatar avatars, identity depends on the address associated with the request. In the archived WordPress core, when a comment is linked to a valid account, the avatar function uses that account's address. If it does not correspond to a valid account, it may use the address saved with the comment. The display name is not this key. An old guest comment may therefore display the default while the same author has a portrait in their profile or a later comment submitted while logged in. A comment's editing interface may show its name and address; those values do not prove that it is linked to an account.

You do not need to change the WordPress account address to choose an avatar. An address change also affects communications and may trigger confirmation. If a custom avatar is wanted for the existing address, its owner can check the association through their chosen service, or the team can use the site's existing local system. If only historical guest comments are affected, the fallback avatar may be expected behavior.

1. In Réglages > Discussion, record the three initial values. If avatars are disabled and display is wanted, enable only that option on the copy, save and reload a page with a known template. If silhouettes already existed, do not toggle a global setting to try to repair one user.
2. In Commentaires, open the control comment with Modifier to verify which entry it is, without saving changes. In Comptes > Profil (or Utilisateurs > Profil, depending on the translation), privately check the account used and relevant address. For someone else, ask them to make this comparison themselves; do not use their account for the test.
3. On the copy, compare two test comments: one from a test account and one as a guest if that route is allowed. Do not reuse a third party's address. Compare with an old comment instead of editing its address or reassigning it to obtain an image.
4. Reload in a logged-out view. The account's comment should use the expected portrait if the provider has an eligible image for that identity. The comment without a portrait should retain the intended default. If you temporarily enabled display for diagnosis, restore the recorded value and check the return to the previous state.

Identify the rendered source before changing the profile

On the copy, inspect the comment image and profile image in separate tabs. The first may come from an avatar plugin, Avatar block, classic template or review widget that does not share WordPress comment settings. A local portrait in the profile does not prove that the widget calls the same function. First compare the hosts delivering images and corresponding rows in Network. In a grid or component providing several sizes, the browser may use a resource different from the one in the main attribute.

If the response is a valid image but the rendered portrait is a silhouette, check source selection, identity and parameters before calling it a network failure. In a Gravatar URL, d indicates a configured fallback; it does not prove the fallback was used. In contrast, f=y explicitly requests the default. In that case, find the setting, template or filter producing this option before blaming the person's address. HTTP 200 demonstrates that a response arrives; it does not prove that it contains the expected photo.

When the browser reports a blocked request or an image without decoded dimensions, compare with another browser or logged-out test profile. Check the network row and precise error. A 404 for a local image calls for locating the file or size used. A security-policy block calls for reviewing the rule with its owner according to site policy. Deliberate blocking of a third-party service must not be lifted for all visitors following a simple diagnosis.

Read images with the browser console

The inspector suffices for one image. To compare several rows without copying their addresses, the script below reads images carrying the native avatar class or located inside an Avatar block. It sends no requests and changes nothing on the page. The host column exposes the hostname but no path, identifier, raw parameter or email. Keep results on the copy if an internal host must not be disclosed.

Open the control page, scroll to comments so lazy-loaded images can load, then open Outils de développement > Console. After reading the code, run it on the comment page, then in the profile tab. Numbers indicate recognized images' order on the page; the admin bar may add a row. If the table is empty while a photo is visible, inspect the element manually: the theme may use another class or a background image. If the browser blocks console pasting, use the inspector instead of disabling that warning.

A decoded: true row proves that an image is decoded, not that it is the expected portrait. If pending remains true, wait for loading before concluding. If both values are false, open Network to find the cause. layoutBox: false indicates no layout rectangle; a true value does not guarantee the image is perceptible, for example if a rule makes it transparent. For Gravatar, compare forcedDefault with the image actually visible. Another web URL may come from a site-local file, CDN or third-party provider: the table does not distinguish these possibilities.

(() => {
  const images = document.querySelectorAll("img.avatar, .wp-block-avatar img");

  console.table(Array.from(images, (img, index) => {
    const candidate = img.currentSrc || img.getAttribute("src");
    let url = null;
    if (candidate) {
      try { url = new URL(candidate, document.baseURI); } catch {}
    }

    const web = url && ["http:", "https:"].includes(url.protocol);
    const host = web ? url.hostname : "—";
    const gravatar = !!web && (
      host === "gravatar.com" || host.endsWith(".gravatar.com")
    ) && url.pathname.startsWith("/avatar/");

    return {
      image: index + 1,
      host,
      type: gravatar ? "Gravatar" : web ? "autre URL web" : "autre source",
      defaultParameter: gravatar && ["d", "default"].some(
        name => url.searchParams.has(name)
      ),
      forcedDefault: gravatar && ["f", "forcedefault"].some(
        name => url.searchParams.getAll(name).includes("y")
      ),
      decoded: img.naturalWidth > 0,
      pending: !img.complete,
      layoutBox: img.getClientRects().length > 0
    };
  }));
})();

Route 2: check the template displaying comments

If one site view succeeds and another fails, identify what renders that view. In a block theme, open Apparence > Éditeur > Modèles and choose the template actually assigned to the control post. List View distinguishes an Avatar inside the comment template from an Avatar beside the post author's name. The native block uses comment context when present. The same block outside that context may target the post author or selected user. Comparing their images makes sense only after identifying both people involved.

In a classic theme, find the comment file actually loaded on the copy, generally comments.php, and any custom callback passed to wp_list_comments(). A callback may ignore the received comment, use the post author or generate its own silhouette. Give the maintainer the component and both controls: they can restore the get_avatar() call for the current comment in the child theme. Compare before editing a file: if a review plugin displays the component, changing comments.php will not affect its template. To roll back a theme correction, restore only the modified file's previous version on the copy.

1. On the copy, identify the post's template in post settings, then open it in the Site Editor. In List View, find the Comments block, then the structure repeated for each comment.
2. If the intended position is empty, add an Avatar block inside the Comment Template, near the commenter's name. If a static image occupies that position, retain a copy in your notes before replacing it. Do not change the author's Avatar elsewhere in the template.
3. Save the template on the copy and open the post with two comments from different users. Avatars should follow each comment. Also check a post using another template before extending the correction.
4. To undo, remove only the added block or restore the previous block in its original location. Then check that comment names, dates and text have not moved.

Route 3: check the existing local provider

This approach helps when the site has chosen local images and the profile shows an image that does not reach comments. Simple Local Avatars is one example: it adds an avatar field to the profile and relies on WordPress avatar functions. It cannot force an independent widget to call those functions or give a guest comment an account's local photo when the comment is not linked to that account. The official link helps verify the plugin's behavior if the site already uses it. Adding a second provider may make diagnosis less clear.

1. In Extensions > Extensions installées, record the active provider and version. On the copy, check in Comptes > Profil that the control account still has a local avatar. In Réglages > Discussion, also record any local-avatar settings added by the plugin and the Gravatar fallback policy.
2. If the local file is missing, reselect a control image you own in the plugin's profile field. Do not change the account address or external-service fallback policy to try to repair one image.
3. On the copy, compare the profile, a comment linked to this account and a comment without a local avatar. If the profile serves the local file but the linked comment still requests a Gravatar, compare with the native block or standard theme in an isolated test. If only the widget retains the silhouette, find its setting or report the incompatibility to its maintainer.
4. Restore the previous photo and initial values if the test is inconclusive. Check avatars on other comments, especially those that should keep the default. Do not delete the old image from the media library while it may be used elsewhere.

Verify the result without changing other comments

In a logged-out view, reload the control post and identify the comment by its text. Check the intended portrait, then another correct comment and a guest who should retain the fallback. Compare with the logged-in view, especially if the admin bar or theme preview already displays the account portrait. Look at a second post to check that a template change does not extend to locations that did not need it.

If an old view persists, first compare the rendered document or exact resource. A cached page may still contain the old source even though the profile file changed correctly. Purge only what serves this view if comparison justifies it, then repeat the same tests. Keep results as anonymized cases: local portrait, external portrait or expected fallback. The problem is resolved when the correct people have the correct image, without broadening moderation, rating or external-provider rules.

Set up a local avatar with the free plugin

If the site truly wants local portraits and has no equivalent provider, install Simple Local Avatars through Plugins > Add New Plugin, checking that the author is 10up. Activate it on the copy, then open the dummy account's profile and find the new Avatar field. Choose a staging image, set its rating if requested and save the profile. Upload permissions and the restriction option under Settings > Discussion determine which accounts can choose an image: do not broaden every role merely for a test.

Add a comment while logged into this account, then view it while logged out. Compare its portrait with the profile and a guest comment. The widget must use WordPress avatar functions to benefit from the local provider. If the plugin affects only the profile, return to the comment template instead of installing a second one.

Keep the site's intended Gravatar fallback policy. At the end of staging checks, restore the old image or remove the dummy portrait. Deactivating the plugin removes its intervention in rendering; it does not mean every uploaded file has been deleted.