Hello Vladimir,

You may go to your joomla backend > easy social > applications > look for User — Links ( as shown in this screenshot http://screencast.com/t/fzBqgBbW ) > stream > set display thumbnails as "YES" as shown in this screenshot http://screencast.com/t/JXLHORZXQKIl .

If the problem still persist could you please provide your joomla backend access as well as your FTP access in order for us to rectify the issue and the screenshot of the issue that you are having.

Regards
Kheng Wei

Oh thanks Ooi Kheng Wei, it was already set to yes, but it seem to retrieve only images which can be found on that page - including site logo, banners etc, but not from Intro Image and Full Text Image fields from the database.

Hello vladimir,

In easy social if you share a link with multiple images you can select which image to include them in the easy social status update shown here in this screenshot http://screencast.com/t/Agc65cQW7ljq . But the image must be of specific size for formatting purposes, if the image is to large then it will not be retrieved.

Regards
Kheng Wei

This problem happens too often. Is there a way to make it ensure that an image is picked. Because 80% of shared links on our site have a white box... or could we potentially make it import the big images that it is set to not import? I have a VPS with pleeeenty of space and I use Ngx_Pagespeed to automatically compress images.

Hello Jannik,

There's actually no way to actually determine this unfortunately unless we try to fetch every image and store it on your site. Even if you have plenty of space, it's going to get filled up too quickly.

Hmm what if it was set up to fetch every image, and then used a cron job to delete the images that ultimately weren't used?

If that isn't possible, then maybe make it choose image number two. Because seriously, I keep getting complaints from members saying the thumbnails when sharing articles are broken.

Hello Jannik,

Hm, this is going to be too tedious and the data integrity might not be there What if there are 2 users sharing the same links but they use a different image?

Yeah I understand the dilemma. However, there must be a solution, because the vast majority of shared links show up with a white box. I constantly get complaints/bug reports from users saying the thumbnails are broken. What is it that stops it from fetching the pic? Is there a way of adjusting the criteria to increase the chances of a pic being imported?

Perhaps we can find an alternative in the future but as of now, we will not be adding anymore features into 1.3 because all these are just slowing our development timeline.

I really hope we can, because right now I just tried to share an article on my site and the first three images don't load. But if I try to share that article on other products and sites (Tested a bunch) it does load. So the criteria which limits what images are imported in EasySocial is clearly broken. Is there no way to hack it to increase file/imagesize of accepted upload if that is what is limiting it?

What is the URL that you are trying to share? There are times when these source sites has some optimizer that messes the source of these images.

Well this example is one where the first 2-3 images don't work: http://www.entrepreneur.com/article/235855 and I have tested it on other sites and it imports the thumbnail fine, but in EasySocial it does not.

but it happens veeery often, literally 9 out of 10 things I want to share.

I never looked into this and im not sure if its altready in use, but if not, you should really use OpenGraph instead the custom fetching solution
https://developers.facebook.com/tools/debug/

Hello Jannik Laursen,

Sorry for late reply to this,
We have checked how the stream retrieve data process when you insert the link. It seems like the first image we get this data ( http://b.scorecardresearch.com/p?c1=2&c2=9564200&cv=2.0&cj=1 ) the site is responding us with different data.
We will look into this and see is it got a better way to retrieve correct data from the site respond to us.

Yeah, please do what you can, because thumbnails for shared article links is the bug report/complaint that I get most often by our sites beta testers.

With open graph tags, most sites would only specify a single image. We could always test the width / height of the image before we try to use the image but it depends on whether or not the hosting provider would enable allow_url_fopen. I have added some hacks in our image processing for links so that if your hosting provider supports allow_url_fopen, it will first check the sizes of the images it finds and if it has a width / height that's lesser than 50px, it wouldn't use it.

Not sure I understood that fully, but if it means that the fix somehow requires allow_url_fopen, it should not be a problem for me, as I have full root access.

Yeah, in short, if your server supports allow_url_fopen we can be a little more funky where we can check the size of images before deciding whether or not to use it. The problem with the link that you tried to share is not really because the image is missing but the size of the image is actually 1x1 pixels. Hence, you think that's it's just a blank image.

ah cool. Now, question for you. You say the image is 1x1, but why when I share it in our teams Podio stream (Free project manager at podio.com) it works? Also note, that this happens too often for 1x1 pixel images to be the culprit. As when I share the articles on other social sites or sites with streams, they are able to fetch the correct image.

If you want to get into more technical terms, what our scripts does is that it will crawl every single <img> tag it finds. The crawler wouldn't know if this image is a separator/ placeholder or just a blank image. All it knows, is that there are images.

Why it worked in Podio is probably because they control their hosting environment. Not many hosting providers supports allow_url_fopen and we will need to download the entire image to actually check the width / height of each images.

With this new hack added in the next release, it will check if your server supports allow_url_fopen and if it does, it will check the size of the image.

Ah that explanation I understood. Perfect, I look forward to getting my hands on it and testing it, allow_url_fopen is already enabled in my setup

Hello Jannik,

The enhancements is actually included in 1.2.20

Ah sweet, I much appreciate it!

You are most welcome

hmm, it isn't working I tried various articles incl. new ones like http://thenextweb.com/socialmedia/2014/07/23/get-lost-reliance-digital-maps-lead-us-mentally-astray/

still no luck getting a thumbnail. Do I have to do anything special?

Hm, this is a different problem altogether Their first image is http://cdn1.tnwcdn.com/assets/images/transparent.png

Again, I ask, why is it that on other sites I can share that article with the correct thumbnail then?

(Not trying to be annoying, but 9 out of 10 things I share on EasySocial have a white box instead of an image for thumbnail, but when I share them on other sites there is no problem... I am just trying to get to the buttom of what is causing this bug)

Please post all the links that you are trying to share which results in a blank image. You can't really compare us with them because they have a dedicated machine that is processing and crawling all urls. If you want us to build this, would you be willing to pay for such services?

Well, to be honest, 90% of articles and things shared on my site have resulted with a white box. Very rarely does it display an image, and when it does it is usually not the right one. A bit of random testing would make you realize very quickly how broken the thumbnail feature is.

and don't get me wrong, I am not trying to compare you to other sites. But when pretty much every article shared on our site has a broken thumbnail there is a problem... and by testing the sharing of those articles on other sites, I know that it is possible to get them to display the right image, by using a different method.

Now, I fail to believe that a site like Podio has a dedicated machine crawling the web. They are just a Project Manager, not a Social Network or Search Engine with a web crawler. (I could be wrong however)

Now when you say pay for such services, what do you mean?

(P.S. I will test this new version a bit more, but I wonder if there is a way to make a default thumbnail show up if no thumbnail is found or something, to avoid the white boxes?)

Here is another one that shows up in an interesting way: http://mashable.com/2014/07/24/foreplay-internet/

The second picture is the correct one, but the first one is not (First one is just white, but different dimensions).

Maybe increase the required size of image? So that it avoids those white space images. That could maybe fix the last 2-3 links that I shared in this thread?

Mark wrote:
With open graph tags, most sites would only specify a single image.

This might be true, but it will always return a proper image, which in most cases, is better than no image at all, or transparent 1x1px placeholder for that matter.
Take a look at Jannik's example on facebook
https://www.dropbox.com/s/n7bizwfjf83jia4/Screenshot%202014-07-25%2010.23.19.png

yeah, Darko is right, see that is the correct image! OpenGraph seems to be much more accurate than ES.

Not to mention your direct competition is utilizing og tags and it works in a better way
From the link @Jannik posted, ES found 8 images, with first and last being blank ones.
The other system with og: tags, found 6 images, no blank ones.

Default state on ES - blank image
Default state on system with og: - proper image

You can try anytime on the demo sites.

From experience I can tell that my BETA testers don't realize that they can change the image, they just complain that the thumbnail is broken. So I much prefer the concept of Open Graph where you just have the one correct image, than 8 irrelevant/broken images.

P.S. I recommend you consider treating this as a high priority bug, rather than a "Feature". As sharing articles is stereotypically one of the most fundamental and most used features on any social networking site... and if 80-90% of articles shared show up with a broken or irrelevant image there is a problem. Darko has been very kind to share some comparative research between using crawl every single <img> tag vs. Open Graph. It would seem that Open Graph is a much more reliable, accurate and simple way of solving this problem, than a dedicated crawler machine.

We actually do scan through open graph image tags Just that we give higher precendence to image tags because not every single site knows and uses open graph tags. We'll see if we can reverse this

Ah sweet! Much appreciated Mark!

Okay, managed to play around with this and we'll be reversing the ordering. Oembed tags are respected first before opengraph tags and lastly, normal images on the page will be the last This way, everyone is happy.

Ah excellent, I am excited for the changes! Thank you very much for listening to feedback and coming with a solution!

You are most welcome