You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The changes introduced in #216 cause multiple breaking-changes for avatars not stored in the media library (no media_id).
If the avatar has been previously set with Simple_Local_Avatars::assign_new_user_avatar( $url, $user_id ) – or via a third party – and is not stored in the media library, the following breaking changes occur:
The rating system is bypassed when the requested size exists. This allows for X/R-rated avatars to be displayed on a G-rated site
If a requested image size does not exist, and the image is stored in the uploads directory, it will no longer be dynamically generated
If a requested image size does not exist, and the image is not stored in the uploads directory/or dynamic resizing is turned off or fails, the full-size image is not returned
I was originally going to submit a PR to fix item 3, which is the bug I first found. But the more I reviewed the changes, the more fundamental issues I found with the newly-introduced changes (also #245). I'd strongly consider rolling back #216 👍
Steps to Reproduce
For bug 1
In v2.7.5 use $simple_local_avatars->assign_new_user_avatar( $url, $user_id ) to assign an image stored in the uploads directory (but not the media library)
Go to the associated user profile and set the rating to R
Go to Settings -> Discussions and ensure the site rating is set to G
Leave a comment on a post as the user. The avatar will show the fallback in the comment.
Upgrade to v2.7.6 and view the comment. The rated R avatar will be showing.
For bug 2
In v2.7.5 use $simple_local_avatars->assign_new_user_avatar( $url, $user_id ) to assign an image stored in the uploads directory (but not the media library)
View the user profile (lets call this User A) and see the fallback avatar
Leave a comment on a post as the user. A resized version of the avatar will show
Upgrade to 2.7.6 and repeat the above steps with a separate user (User B)
User A will have their avatar showing in the comments, while User B will have the fallback avatar
For bug 3
In v2.7.6 use $simple_local_avatars->assign_new_user_avatar( $url, $user_id ) to assign an image stored in the uploads directory (but not the media library)
View the user profile and see the fallback avatar
Screenshots, screen recording, code snippet
No response
Environment information
No response
WordPress information
No response
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
Describe the bug
The changes introduced in #216 cause multiple breaking-changes for avatars not stored in the media library (no
media_id
).If the avatar has been previously set with
Simple_Local_Avatars::assign_new_user_avatar( $url, $user_id )
– or via a third party – and is not stored in the media library, the following breaking changes occur:I was originally going to submit a PR to fix item 3, which is the bug I first found. But the more I reviewed the changes, the more fundamental issues I found with the newly-introduced changes (also #245). I'd strongly consider rolling back #216 👍
Steps to Reproduce
For bug 1
$simple_local_avatars->assign_new_user_avatar( $url, $user_id )
to assign an image stored in theuploads
directory (but not the media library)For bug 2
$simple_local_avatars->assign_new_user_avatar( $url, $user_id )
to assign an image stored in theuploads
directory (but not the media library)For bug 3
$simple_local_avatars->assign_new_user_avatar( $url, $user_id )
to assign an image stored in theuploads
directory (but not the media library)Screenshots, screen recording, code snippet
No response
Environment information
No response
WordPress information
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: