Avatars not showing up for JFBConnect users in JS 2.6

Miki,
We've done some testing with the newest JomSocial, but haven't run through everything. However, we haven't heard of any issues with JFBConnect with the newest JomSocial yet. Also, in the past for 2.0, 2.2, and 2.4, there haven't been any changes necessary.

Were all the avatars working fine before the upgrade to JomSocial 2.6? Did you change any settings with the avatars in JomSocial while you upgraded?

Also, I just added your subscription from the other account you have to this one so that it shows your subscribed under both.

Hope that helps, and let us know what else you can. We'll gladly do more testing, but not sure what would have changed during the update.

Thanks,
Alex

Miki,
Thanks for the information on the Amazon storage. JFBConnect hasn't ever stored the avatars using the JomSocial "Remote Storage" feature. We store them locally and instruct JomSocial to use those local avatars. The reason we've never used remote storage is because the local storage has worked fine and we simply haven't had any requests to support the remote storage.

We'll be doing tests with Remote Storage and how to implement it later today and tomorrow and try to make sure we have a solution going forward for properly storing the avatars remotely.

For the avatars you've lost, we'll be testing with JomSocial 2.4 using a hybrid of local and remote avatars, upgrading to 2.6, and determining what went wrong. We'll do everything we can to provide a solution as well. Please make sure you keep whatever backups you had before you upgraded to JomSocial 2.6 though, as we're not sure if avatars were deleted locally or the database was altered. One way or another though, you'll likely need information from the site before the upgrade.

Finally, you may also want to contact JomSocial. The situation of a site with both local and remote avatars should be something they handle normally. If you think about a site that used 'local' storage for a year before the site admin decides to implement Remote Storage, the scenario you're in is likely a common case scenario. JomSocial may already be aware of the issue of and have some ideas of how to fix it for users that weren't using JFBConnect, but still had a mix of local and remote avatars. I could be wrong on how JomSocial works underneath though, so that may not be true, but it's worth asking if they've heard of the problem.

We'll keep you posted on what we find,
Alex

Miki,
We've been testing more with the Remote Storage, and had a quick question. Can you verify that you're properly running the JomSocial cron job?

The cron job is what will scan for local avatars and uploads those images to Amazon's S3 storage. The URL to hit is usually:
With our testing (currently only on JS 2.4), the images from JFBConnect are properly being uploaded to Amazon after the cron job is run. My assumption is that, on JS 2.6, the cron job will do the same thing. Once run, those local avatars will be uploaded and become remote storage. It doesn't happen immediately, only when the cron is run... so once you do that, it will take care of the 'new' avatars that you mention are local instead of remote.

It doesn't explain the reason that images are missing from before the upgrade. Letting us know how often (or if) you run that cron job will help narrow things down though. We'll be testing more now with the actual upgrade to JS 2.6 to see if we can recreate the problem you're having.. it's looking likely that you may need to contact JomSocial. Again though, if we run into issues with the upgrade, we'll let you know what happens and if we have an easy way to fix it.

Thanks,
Alex

Alright.. last update for now.

We just upgraded our JomSocial 2.4 test site which had a mix of 1) normal user's created before remote storage was enabled, 2) normal user's created after remote storage was enabled, and 3) JFBConnect users.

After each user was created, the cron job was run, and the avatars were checked to make sure that all 3 were properly stored on Amazon.

Then, we upgraded to JomSocial v2.6. The avatars for all 3 users were still (correctly) being pulled from Amazon. Finally, we re-ran the cron job directly, and the output was as follows:

<messages>
<message>No videos pending for conversion.</message>
<message>No temporary videos to delete.</message>
<message>No files to transfer.</message>
<message>No Videos to transfer.</message>
<message>No avatars needed to be transferred</message>
<message>No avatars needed to be transferred</message>
<message>Removed Pending Invitation for Past Event</message>
</messages>

That indicates that JomSocial wasn't detecting any avatars that needed to be uploaded. Additionally, all the avatars that were uploaded from v2.4 were correct.

So, we can't recreate this problem. Can you check and let me know the following:
1) Was/is the cron job setup properly for JomSocial both in v2.4 and v2.6?
2) Can you find a user that created an account without JFBConnect on JS v2.4 and see if they're avatar is working? If not, it indicates it's not a JFBConnect issue.
3) Can you run the cron job manually on your site (just go to that URL, unless you have protection on it), and see if the 'new' JFBConnect avatars are properly uploaded to Amazon.

Before you do #3, you may want to make sure you have another backup, just in case the cron job has unexpected effects.

Please let us know how it goes,
Alex