Using https version of profile image

This branch is no longer supported. If this issue is still relevant feel free to reactivate it against relevant version.

Reopening for current release.

I've tried manually updating the record to use https://si0.twimg.com instead of http://a0.twimg.com but that only solves the problem until the next cron run where it gets flipped back to the http version.

Here's a patch against 7.x-5.8 that forces https for the profile image and background url.

Probably could be done better on the views part to enable people to choose from http or https, but I don't think https for profile images is a bad thing for people running http sites

Solved the problem for me, thanks!

I don't think this wants an extra field - there's no harm in using SSL for the image by default? Let's just change the existing references to https and drop the http values.

(+1 for a hook_update_N() to replace existing values.)

See also #2239041: Restrict Twitter API calls to SSL.

OK, I see that Twitter returns http URLs for images, but that the https versions of those URLs appear to work.

I still think just using SSL is the simplest approach ... any reason NOT to just rewrite the URLs when we store them, so they're always https?

Hi everyone,

I have rerolled the patch as it was not applying due to whitespace errors on the latest build.

Sorry for the duplicate post, but the first patch is still buggy. Here's a better version!

After further testing, I was notcing some PHP errors come up if the user hasn't set their background_image in twitter. Rolled a new patch to fix this. Also updated patch name to comply with drupal patch naming standards.

I've tested updating the profile_image_url to be a protocol-relative URL (ie, //pbs.twimg.com) instead of http:// or https:// and it works great. Any reason we wouldn't go that route instead of forced https?

That makes sense to me mrP. I don't see any reason we need to store BOTH the http and https URLs, which it looks like the previous patch is doing.

Only issue would be if we were retrieving the //images.twitter.com URL from PHP - we'd need to test if protocol relative uses a sane default in that case, IF we ever try to retrieve the image for that purpose (image styles?)

I had the patch in #3 working for a while but then images stopped displaying and now none of the patches in this issue work for me. All of them result in a blank image source: <img src=""> at least in the Views "formatter tweet" field. (Unfortunately I don't know what changed between the time that the images displayed and when they stopped.)

Is anyone else seeing this problem?

Using the dev version and no patch, I can see images hosted on http://pbs.twimg.com (bizarrely, with one exception) but not ones on http://a0.twimg.com.

I found that if I changed the profile_image_url in the twitter_account table, it worked correctly. I change it from:
http://pbs.twimg.com/profile_images/123456/some_name.jpg
to
//pbs.twimg.com/profile_images/123456/some_name.jpg

This seems to work as a stopgap solution. Any progress on a real patch?

Hi everyone, this could be the easiest fix. Just removed the http: from the views handler so that the profile picture URL is protocol-relative.

Triggering the testbot.

Triggering the testbot.

I can't get this patch to apply on the latest dev (7.x-5.8+20-dev). First, it can't find the file, because sites/all/modules/twitter is hardcoded into the patch and in my case it should be sites/all/modules/contrib/twitter. But once I account for that, I get a "malformed patch" error.

So I ended up trying to do it by hand, but the patch doesn't cleanly match up with the latest dev. My best guess was to put the new line at line 56 like this:

  /**
   * Processes the message through the selected options.
   */
  function render($values) {
    $value = $values->{$this->field_alias};
+   $value = str_replace("http:", "", $value);
    if (!empty($this->options['link_urls'])) {
      $filter = new stdClass;

I don't know yet whether this was the right place to put it and if so whether it has solved the problem, but I'll report back when I do. But in the meantime, it looks like this patch needs to be rerolled.

@brightbold, the -p (prefix) parameter to patch specifies the number of directories to ignore (for git-style patches this is -p1 to remove the a/ b/ prefixes).

For the patch above, you can use -p5 to apply the patch from the twitter directory. (If that works, you can submit the reroll!)

Thanks @xurizaemon! I didn't know about -p5 so that's helpful.

Rerolled.

Would be nice to have this. It triggers errors on https sites otherwise..

Needed to reroll the patch.

Committed to all three branches. Thanks everyone!

Don't know if this is necessary but twitter_status.tpl.php is still fetching the http:// url from database and displaying it without any string replacement. One could just copy the template to a new theme and modify it. Anyways here is a diff:

diff --git a/twitter_status.tpl.php b/twitter_status.tpl.php
index 7262430..f1e2409 100644
--- a/twitter_status.tpl.php
+++ b/twitter_status.tpl.php
@@ -8,7 +8,7 @@
 <div class="twitter-status clearfix">
   <div class="avatar">
     <a href="https://twitter.com/<?php print $author->screen_name; ?>" title="<?php print $author->name; ?>">
-      <img src="<?php print $author->profile_image_url; ?>" alt="<?php print $author->name; ?>" />
+      <img src="<?php print str_replace('http:', '', $author->profile_image_url); ?>" alt="<?php print $author->name; ?>" />
     </a>
   </div>

Though, I think it should be fixed when saved to database in the first place. It's kinda strange to handle data that is not in the correct format and then correct it with code every time it is used.

Why not use HTTPS always? The profile_banner_url seems to use HTTPS by default.

Whatever Social Media module you are using just make sure you use the https version of the user profile image from the Twitter API result
i.e.
Instead of
$user_image_url = $item->user->profile_image_url;
use
$user_image_url = $item->user->profile_image_url_https;