Linkedin member profile request failing - plugins

I need to use the member profile plugin from LinkedIn for a project. So I generated my personal "code" at https://developer.linkedin.com/plugins/member-profile . Which gives me the following standard code sample
<script src="//platform.linkedin.com/in.js" type="text/javascript"></script>
<script type="IN/MemberProfile" data-id="https://www.linkedin.com/in/myname" data-format="inline"></script>
Where "myname" is obviously replaced with the name at which my public LinkedIn profile is found.
My problem is that there is nothing showing, after inspecting the resulting html at a couple of frames deep there is only a hidden div with the following content:
<h2>
Your Request Could not be Completed.
</h2>
I have checked all my privacy settings on LinkedIn and they are configured to make sure all information is publicly available and there should be no reason to let this plugin fail. I even checked with a colleague and we compared settings, the settings were the same but his plugin worked and mine did not.
Does anyone know what is causing this problem? Is there a setting we are missing, which is detrimental to this plugin?
(fyi, the plugin is running from a server so there is no problem to actually get the script)

The question was asked several times here (as the LinkedIn support is unwilling to help and redirect here where developers seldom answer questions)
See this question
Linkedin Member Profile Plugin not working for some profiles
One month after it was asked (yes one month!!!), a LinkedIn dev answered:
"The problem is under investigation. Several profiles still work fine, so there isn't a systemic issue with the plugin itself, but rather with certain profiles in particular."
Note that the number of particular profiles seem to be huge, because 9 out of 10 profiles I try fail.
Nothing has changed since then...
This is not the only bug in LinkedIn which is litteraly ruining my experience with it.
I used to love LinkedIn, but the way their support is treating customers (yes I am not only a user but also a customer because I pay for ads...) + the fact that they just can't seem to detect/fix their bug is making me become very bitter about them.
So all you can do is to cross fingers and hope that somewhere, someone will finally care about this and fix the bug...

Related

Facebook comment plugin doesn't work at all

I inserted the facebook code where required and absolutely nothing happens or shows up. Using dreamweaver cs6 and in live view or when testing in ANY browser, nothing shows up. It's a blank box. ANy thoughts? I read somewhere that the website must be made into an application of facebook? Is this something?
Specifically, after activating the plugin and properly connecting the plugin to the facebook app,which does work and has been used extensively before hand, comments simply fail to load. There is no comment box, no past comments pull in either (note the app has historical comments already).
In the plugin settings area on the right side of the screen where the comments check box exists, there is a read more link that takes you to the facebook developers page where it discusses adding the facebook comments iframe.
If there is some other location where comment settings might also exist (past the three fields that require the 2 keys and the app name) I could not find them and this was not referenced in the plugin setup.

Wrong Joomla links on facebook

friend asked me to help him out with his Joomla website. Here is the problem. He turned off Plugin System Cache and in Global Config he turned off cache in Cache settings and when he posts links on his articles on Facebook everything is fine. He needed to turn on those caches due to website crashes but now when he links article on Facebook Article name is something random from site and not actual article name. He tried Facebook Debug option and this was error
More Than One OG URL Specified:
Object at URL 'http://www.madbarz.com/news/614-not-your-average-mamas-workout' of type
'website' is invalid because it specifies multiple 'og:url' values:
http://www.madbarz.com/news/614-not-your-average-mamas-workout,
http://www.madbarz.com/news/565-hannibal-for-king-compilation,
http://www.madbarz.com/add-team.
Obviously the "post to facebook" code is being cached once instead of once per page.
This most likely depends on it being added as a module (as opposed to a plugin, which would cause no trouble), and the module doesn't take into account proper caching techniques.
Since having page caching and global cache on is desirable, you may be able to get around this just setting the module's cache to "Do not cache": it will still be cached by the system page cache, but that cache is built once per each page so you'll be fine.
The multiple headers could be an issue generated by the same cause.
If this still doesn't solve the issue, look into the module's code; here you can find some info on setting up a module to cache correctly: http://www.fasterjoomla.com/joomla-dev/programmare-un-modulo-joomla-per-utilizzare-la-cache
The reason the site crashes with cache turned off should be studied: it's not normal and you don't want to run a site under those conditions, it's not safe. There could be something really really wrong and you might end up wasting months to build linkbacks only to find they all become invalid at some point.

Do Facebook Like Buttons require an App ID?

When going to the set up pages for all the Social Plugins, they now provide example code using an APP ID.
http://developers.facebook.com/docs/plugins/
Is an APP ID now required for the Like Button and other plugins? What happens if an APP ID is not included when using the plugins?
I've checked the Facebook developer blog and read about the Like Button Migration. I haven't been able to find a straight answer for this either there or in the FB Like Reference.
Notice:
This is an old dated information, the official facebook's behaviors are changed.
Simply, the answer is No, just look at the following official Facebook resource.
Notice: To do it without need to the app id, you have to visit the above page when you are signed out from Facebook. Look at the following screen shot.
As semsem said, the simple answer is "no it is not required"... there are ways to get around having an appId associated with the "like" button. Here's my experience working with this. I'm not a Facebook or Open Graph expert, so YMMV.
Why we avoided using the appId on the button:
We're providing an service where we have one website (the engine, as it were) that provides a service distributing online courses to students (customers). Instructors (also customers) who what to use our service to disseminate courses to students can brand the site how they wish, and map their domain to their section of our website that serves those course(s).
As a simplified example: we serve from http://courses.example.com/instructor_name, but we want students to access the content through http://www.instructors-domain.com/. Any courses would be sub-directories off the base URL.
Associating the "like" button with our Facebook App disallows any cross domain shenanigans. While there are valid reasons for doing so, it doesn't work for where we're at in our company and product evolution. So we needed to find a workaround.
We wanted to allow folks to "like" a course, have the "story" point to the appropriate places on the net, as well as get some customization (e.g. "NAME likes an online course on FBAppName"). We basically achieved this. We lost some functionality which we deemed acceptable at this point in our evolution.
The short of it
I used the iframe version of the Facebook "like" button as dictated by the appropriate Facebook developer's page (for the link see semesm's answer for the link, I got no rep). I took their code snippet and manually removed the appId query string in the iframe's src.
In the "liked" page itself (which was the same page that had the "like" button) I used the Open Graph meta tags including specifying the appId. (These tags were specified: fb:app_id, og:type, og:url, og:site_name, og:title, og:description, og:image.)
The og:type was our custom type of the form 'namespace:app_custom_object_name'.
A failed approach
My first attempt was to use what I understand as the preferred method, the "HTML5" tab in the "Get Code" section of the developer's "like-button" page. I tried their method stripping the appId from the appropriate places. This method proved ineffectual.
If the domain doesn't match that in the Facebook App, there will be no "like" button.
If the domain does match, the "like" button will appear. However, it takes 3 clicks to actually "like" something. The first click changes the "thumbs-up Like" icon to a normal anchor with one word that didn't make obvious sense (I forgot what the word was). The second click will brings up the login/authorization window for using our app. The third actually bring up the modern fancy "like" box where you can type in a comment. I didn't find a way around this behavior.
Note that when I specified the appId in this approach on the appropriate domain, it worked as one would expect (though inconsistent with our desired behavior).
I did not try the other two options in the "Get Code" section of the "like-button" page.
Informed speculation and rumor
In my research around this, my overall impression is that requiring an appId is the way of the future for Facebook. Who knows if the old way will be depreciated, probably never, though I didn't find anything in the docs talking about this "legacy" behavior. This makes sense to me with their newer offerings and the advanced tracking that becomes available with this method.
I've seen suggestions that the "likes" used in this manner are akin to second-class citizens... treated as inferior in some respects. In my own experimentation I found the behavior of the fully specified appId (in the "like" button itself) to be different and more accessible and predictable (in terms of Open Graph queries and visibility on my limited Facebook tests) than the partially specified appId. (Again, I've found no solid documentation on this, and did not endeavor to full grok the differences.)
May this info help someone else along. Good luck!
So, I just tried the sємsєм method, as comments say: Facebook want you to login to get the code, and if you have an app, you have to choose one.
But if you don't, it gives you a code without any app reference.
So when you get a code – no matter any app you choose –, you just need to remove the appId parameter in the .js URL (&appId=##############), and you got (for the latest HTML5 code, 6th line):
js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";
The code for the div element does not change.
I simply use the URL code inside an iframe tag without an appID and it seams to work,
here is an example:
<iframe src="http://www.facebook.com/plugins/like.php?href=<%=request.original_url%>&width&layout=button_count&action=like&show_faces=false&share=false&height=35&appId=" frameBorder="0" width="150" height="25">
</iframe>
According to Facebook's Social Plugins FAQ
Web: If you are using Social Plugins on the web, you do not need to create a Facebook app for integrating a Social Plugin.
iOS/Android: If you are using Social Plugins within a iOS or Android app, you need to create a Facebook app and tie it to your app identifier.
It seems that the official answer is that they are only required for iOS/Android.

Domain blocked and no data scraped

I recently purchased the domain www.iacro.dk from UnoEuro and installed WordPress planning to integrate blogging with Facebook. However, I cannot even get to share a link to the domain.
When I try to share any link on my timeline, it gives the error "The content you're trying to share includes a link that's been blocked for being spammy or unsafe: iacro.dk". Searching, I came across Sucuri SiteCheck which showed that McAfee TrustedSource had marked the site as having malicious content. Strange considering that I just bought it, it contains nothing but WordPress and I can't find any previous history of ownership. But I got McAfee to reclassify it and it now shows up green at SiteCheck. However, now a few days later, Facebook still blocks it. Clicking the "let us know" link in the FB block dialog got me to a "Blocked from Adding Content" form that I submitted, but this just triggered a confirmation mail stating that individual issues are not processed.
I then noticed the same behavior as here and here: When I type in any iacro.dk link on my Timeline it generates a blank preview with "(No Title)". It doesn't matter if it's the front page, a htm document or even an image - nothing is returned. So I tried the debugger which returns the very generic "Error Parsing URL: Error parsing input URL, no data was scraped.". Searching on this site, a lot of people suggest that missing "og:" tags might cause no scraping. I installed a WP plugin for that and verified tag generation, but nothing changed. And since FB can't even scrape plain htm / jpg from the domain, I assume tags can be ruled out.
Here someone suggests 301 Redirects being a problem, but I haven't set up redirection - I don't even have a .htaccess file.
So, my questions are: Is this all because of the domain being marked as "spammy"? If so, how can I get the FB ban lifted? However, I have seen examples of other "spammy" sites where the preview is being generated just fine, e.g. http://dagbok.nu described in this question. So if the blacklist is not the only problem, what else is wrong?
This is driving me nuts so thanks a lot in advance!
I don't know the details, but it is a problem that facebook has with web sites hosted on shared servers, i.e. the server hosting your web site also hosts a number of other web sites.

Wordpress og:image shows up blank

I've been at this for almost 3 days straight and now I can't even think clearly anymore.
All I'm trying to do is to get my featured image thumbnail to appear when I paste the link in Facebook.
I'm using the Wordpress Facebook Open Graph protocol plugin which generates all the correct og meta properties.
My thumbnail images are 240x200px which respects the minimum requirements and also respects the 3:1 ratio
I've made sure there's no trailing slash at the end of my post URLs
When I use the Facebook Object Debugger, the only warning is in regards to my locale, but that shouldn't affect it.
Facebook appears to be pulling the right image, at least the URL is correct, but the image appears as a blank square
I've gone through pretty much every thread I could find in forums, but all the information available is about using the correct og tags, which I believe I'm already doing.
Thank you very very much for any help, I'm desperate!! :)
You can troubleshoot the OpenGraph meta tags with the Debugger https://developers.facebook.com/tools/debug - this can at least show if you're using the meta tags properly and if Facebook can 'read' the image.
I finally figured out that the root of my issue was the fact that I was using an addon domain (which is really a subdomain being redirected to the top level domain) and I read on eHow (of all places :) ) that Facebook has trouble pulling data from redirected domains.
Not sure if there was another way around it, but I simply ended up creating a seperate hosting account and everything is loading properly now.
one problem youre going to run into testing is that often the first time your page or post gets liked, fb keeps whatever img it finds in your meta tags or by searching your page. so, you'll keep changing your img meta tag and still it wont show the right pic. it's very anoying. One way to get around it is to change the slug of your post. now, it has a different url and to fb, it's a different page. The downside is you lose all the likes that go with your orig url. Not a problem with a new site.
I ended here googling another problem. Maybe this might help someone:
Please bear in mind that the facebook scraper works asynchronously and will need some time (during my tests around 10 minutes) to be able to display an image after seeing it for the first time.
For more information, here's a more thorough answer on a similar problem.
Indeed, as Andy Wibbels points out the FB debugger is a really handy tool.
I faced a similar issue with a server's og:image tag pointing to a secure subdomain which actually mirrors a CDN server,
<meta property="og:image" content="https://subdomain.pathToImage.jpg" />
<meta property="og:image_secure" content="https://subdomain.pathToImage.jpg" />
The FB debugging tool allows you to see the errors that FB encounters when trying to pull the image.
In my case the subdomain was not registered under the SSL certificate used by the HTTPS protocol. Hence FB was getting the following error,
Curl Error : SSL_CACERT SSL certificate problem: unable to get local issuer certificate