Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save avatars of "Followers" Block locally #647

Closed
jaschaurbach opened this issue Jan 10, 2024 · 6 comments
Closed

Save avatars of "Followers" Block locally #647

jaschaurbach opened this issue Jan 10, 2024 · 6 comments

Comments

@jaschaurbach
Copy link

What

The avatars of the users in the Followers block are not saved within WordPress but are loaded every time from the instance.

I would love to have them cached locally and only update every now and then.

Why

Because I think this is the right thing to do with data from other instances. Not hitting every time the other instances when someone opens my blog is quite nice

How

No response

@janboddez
Copy link
Contributor

Possibly related (at least in spirit :-P) to #568.

But also, I share the feeling. In fact, I already do store commenter's avatars locally, using a custom code snippet (which can be seen near the top of my "add-on mu-plugin").

Now, I'm obviously not expecting anyone to use my code there (which relies on the presence of another plugin to work, by the way). But, who knows, someone might feel inspired. ;-)

I may look into extending my "solution" to followers' avatars.

There's also other plugins for that do this sort of thing, I think, for "regular" commenters; no clue if they can somehow be leveraged to do something like this.

@jaschaurbach
Copy link
Author

For the avatars in the comments (regardless from whe3re they are coming) Avatar Privacy does the job very good.

Unfortnuatly it does not detect the avatars in the follow block.

@jaschaurbach
Copy link
Author

Maybe it is a good idea to reuse the code for storing avatars you wrote for the webmention plugin @pfefferle?

@janboddez
Copy link
Contributor

janboddez commented Jan 17, 2024

Had a quick look in the database and I don't think the avatars are stored anywhere, but rather that the icon.url property which is stored in the postmeta table is used for rendering the block (and the follower avatars in WP-Admin).

At least for comments, we can hook into one of WordPress' core hooks and store avatars anywhere (and retrieve them, again using a hook, later on).

For these followers, maybe the best way would be to make the Follower::get_icon_url() method filterable? Then we could (write a plugin to) store the corresponding avatar locally and return its URL if the file exists (or save the local URL in postmeta and fetch it from there), overwriting the "default" URL returned by the plugin.

(Of course avatars would have to be updated every once in a while. What I currently do, for comment avatars, is check whether they're over a month old, and update them if so, even if nothing's changed.)

Another way would be to override the block's render function (seeing as it is a dynamic block). But that's more complicated; you'd need to get the URLs from the block's original output HTML. And it would only work for the block, not elsewhere (like inside WP-Admin).

Not saying this is how is should be done; just generating ideas of how one could attempt to make it work with what we have right now.

@Menrath
Copy link
Contributor

Menrath commented Jan 19, 2024

From my point of view this is also a privacy issue. I think this is also related to #622 I also almost started working on this weeks ago.

Copy link

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions github-actions bot added the Stale label May 27, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants