Good call. I don’t have a specific time line for a fix but this is something I will look into when I can.
Thread Starter
KTS915
(@kts915)
Thank you, Jared, for considering this.
Thread Starter
KTS915
(@kts915)
Jared,
It seems that the fundamental problem is a long-standing bug in WordPress: see this and the other tickets to which it refers.
I haven’t found that any of the workarounds mentioned there helps at all. But I have found that adding a couple of functions to functions.php seems to overcome the problem.
I took the inspiration from here, and came up with this:
function wpse_84046_upload_path( $path ) {
return 'wp-content/uploads';
}
add_filter( 'pre_option_upload_path', 'wpse_84046_upload_path' );
function wpse_84046_upload_path_url( $url ) {
return 'wp-content/uploads';
}
add_filter( 'pre_option_upload_path_url', 'wpse_84046_upload_path_url' );
Although it’s obviously still using the same uploads folder as before, some avatars may need to be re-uploaded after making this change. But, once that’s done, it all works with SSL (when that is set) without causing mixed content warnings.
I don’t know whether this is something you might integrate into the plugin.
Good find.
I’m thinking maybe the best thing as a short term fix is putting a filter in place, what when manually set to true, which forces HTTPS on the front end even if it’s through a less than ideal approach str_replace().
Thoughts?
Thread Starter
KTS915
(@kts915)
Jared,
You’re right that it’s a less than ideal approach, but I can’t think of anything better, given that the problem lies within WordPress itself.
I think that, if I were convinced that the next WordPress update would solve the problem, then I’d probably be inclined to suggest that you just wait it out.
But, because the fixes and workarounds suggested in the various Trac tickets don’t work for me, I am far from convinced. I think your proposed “short term fix” might actually turn out to be useful for quite a while!
Actually, I just realized there is already a filter in place (basic_user_avatar) that runs when the custom avatar is output http://cl.ly/image/0i2q032C1G0R
This isn’t an elegant approach, but I’d probably just run whatever checks you see fit for your use case (is_ssl, is_admin, whatever) then do the string replace when necessary via that filter. Hopefully that will work for now. Let me know.
Thread Starter
KTS915
(@kts915)
OK, that makes sense. Thanks!
Hi,
I’ve found this solution, and it works :
in init.php on line 186 add set_url_scheme() around the $local_avatars[$size] like that :
$avatar = "<img alt='" . esc_attr( $alt ) . "' src='" . <strong>set_url_scheme(</strong>$local_avatars[$size]<strong>)</strong> . "' class='avatar avatar-{$size}{$author_class} photo' height='{$size}' width='{$size}' />";
it adds http or https depending on the is_ssl() value.