• This plugin works very nicely on posts and pages loading on http. Thank you!

    Unfortunately, it’s causing a problem when posts or pages (or admin pages) load on https. It seems that this plugin has hardcoded all uploaded avatars to load using http, which then causes “mixed content” warnings.

    Would it be possible for you to modify the code so that avatars load on https when SSL is set for that particular post or page?

    https://wordpress.org/plugins/basic-user-avatars/

Viewing 9 replies - 1 through 9 (of 9 total)
  • Plugin Author Jared Atchison

    (@jaredatch)

    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.

    Plugin Author Jared Atchison

    (@jaredatch)

    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!

    Plugin Author Jared Atchison

    (@jaredatch)

    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.

    Plugin Author Jared Atchison

    (@jaredatch)

Viewing 9 replies - 1 through 9 (of 9 total)

The topic ‘Problem with SSL’ is closed to new replies.