Add Ability to Manually Edit and Upload Comment Avatars

[mgiannopoulos24]

Description

This PR adds the ability for administrators to manually edit the Avatar URL for a comment or upload a new avatar locally using the WordPress Media Library. Previously, this field was read-only and restricted only to comments created via the Webmention protocol.

Related issue

Issue #449

Changes

• includes/class-admin.php:
  • Updated enqueue_scripts to load the WordPress Media Library (wp_enqueue_media) on comment editing screens.
  • Added a save_comment method hooked to edit_comment to sanitize and save the avatar meta field when the metabox is submitted.
  • templates/webmention-edit-comment-form.php:
  • Moved the Avatar input field outside the if ( 'webmention' === ... ) check, making it available for all comment types.
  • Removed the disabled attribute to allow manual editing.
  • Added an Upload button and inline JavaScript to trigger the native WordPress Media Uploader modal.

Testing Instructions

1. Navigate to Comments in the WordPress Admin.
2. Click Edit on any comment (standard comment or Webmention).
3. Locate the Webmention Data metabox.
4. Verify that the Avatar field is editable and the Upload button is visible.
5. Enter a custom URL or use the Upload button to select an image from the Media Library.
6. Click Update.
7. Reload the page and verify the Avatar URL has persisted.

Showcase

• Original Comment without Avatar URL:

• Comment with updated Avatar URL:

• Another example but with an uploaded avatar:

---

Let me know your thoughts on this PR.

[dshanske]

The problem is it isn't uploading to the store, it is uploading to the media library, so this doesn't achieve the stated goal. You are also making it available for all comment tyhpes, which would interfere with other plugins that do avatar uploads.

The store is designed to store a unique avatar for each author URL, not for each comment URL, which makes me think.

[pfefferle]

The problem is it isn't uploading to the store, it is uploading to the media library

I agree with @dshanske here. I think we do not want to have avatars of remote users/sites in the media library.

[dshanske]

I'm working on a PR to the store class to add retrieval functionality directly from the store.

[mgiannopoulos24]

So should I close this?

[pfefferle]

I am not even sure if "manually uploading" is the right approach!? I would prefer something like "force update" to tell the plugin to receive a new avatar from the remote server.

[pfefferle]

With an image upload you can do too many bad things!?

[mgiannopoulos24]

I think i fixed it now. I did some tests with 3 test users and it seemed to work. Pushing now.

[mgiannopoulos24]

As requested now we have full access to the avatars through Tools panel.

We can still modify, refresh and cleanup orphan entries.

I also added the functionality to delete the avatar if we delete a user's comment.

Of course I have taken into consideration the fact that a user may have more than 1 comments, so if we delete one of them, his avatar will still remain untouched.

[dshanske]

@mgiannopoulos24 Don't want to discourage you here, we really appreciate the contributions. We are just figuring out exactly what makes sense.

We try to keep the plugin very basic on the plumbing and sometimes realize an idea violates that simplicity principle. @pfefferle has had to hold me back on features at times we both ultimately agreed should be separate.

[mgiannopoulos24]

Absolutely, no problem. I also want to thank you for your time.

[dshanske]

I am going to look and figure out more specific feedback. Right now, working on a complementary idea you inspired me to do @mgiannopoulos24

[dshanske]

Complimentary as in it would work with this.

[dshanske]

@mgiannopoulos24 If you look at #560 this is the idea your PR made me start pursuing, which is complimentary in the sense thinking about this again caused me to ask if we were doing the right thing by overwriting the original source URL for the image in the first place.

Assuming we merge that one, and that requires concurrence, it doesn't affect the idea of loading things into the avatar store manually, or refreshing or otherwise purging, but it is a change in where in the chain things go. Specifically it would now go Avatar Store(if enabled), followed by metadata stored URL(if present)....and then to the other fallbacks.

It means that if the store is enabled, then we should be manipulating the store, but if it isn't....

[dshanske]

@mgiannopoulos24 Reading your code, adding a function to retrieve an avatar from the store directly is something we both did, and I think that should stand. Yours is probably simpler than mine, which is probably a good thing as I was considering the possibility there might be deviation in the filenames, which there shouldn't be.

Deleting orphaned avatars also makes sense, but we shoudl do this based on $host and $author properties used to generate the URL.

[mgiannopoulos24]

Deleting orphaned avatars also makes sense, but we shoudl do this based on $host and $author properties used to generate the URL.

I will modify it when I can. If you have any other suggestions let me know!

[dshanske]

@mgiannopoulos24 I think maybe we should break this into separate PRs.

Specifically, the idea of an API endpoint for the avatar store should be explored to see what functionality we want in that as a separate issue.

You have a few bugfixes in here that I think should also be separate PRs, such as the inversion of the str_contains with gravatar.

[dshanske]

Would you be willing to submit the bug fixes and enhancements to functions to improve behavior separately? I'm going to open an issue to discuss what we might want in an avatar api endpoint.

[mgiannopoulos24]

I could try and break it to separate PR's okay.

[dshanske]

I could try and break it to separate PR's okay.

Just the bug fix part, and I've opened #565 to discuss how an API endpoint should behave.

And any thoughts on methodology for #559 so we can figure out how we want this to behave when finalized.