I have placed the facebook like button on a website, and the weirdest thing is happening, every page on the site shows the same count for the number of people liking the site (~ 760), except the home page, the home page shows 18 people only.
for the life of me I cannot figure out what's causing this.
All pages are using the same open graph meta tags, and the facebook snippet is inserted by a user control (same on every page).
Anyone has any ideas where I can even start to debug?
The site is canvaspop.com
http://www.facebook.com/plugins/like.php?href=http://www.canvaspop.com/default.aspx&layout=button_count&show_faces=false&width=130&action=like&font=arial&colorscheme=light&height=21
Looking at the DOM and XHR Responses that data is coming directly from facebook without any problems.
to be perfectly honest, I would not rely too much on data coming from facebook, the amount load they have and there forever changing CDN, there's bound to be issues with the balance loader, that data as its the root of your domain may be coming from a cached result to decrease laod.
you can image the % of content delivered to homepage's rather then inner site pages, because users usually go on a site and then go off.
just wait it out and see if the results get updated. if it does not then go to the Developers Support areas and ask a member of the community or team!
Install fiddler, and look at the request sent to facebook on the homepage vs the other pages.
Related
I have started to experience a really strange problem with Facebook link scraping/caching which seems random in nature.
On brand new posts when I go to check: https://developers.facebook.com/tools/debug/ with my new URL I get a message saying 'Cannot scrape: URL blocked'
We have literally been sharing URL's to Facebook for YEARS with no problem whatsoever. All open graph tags are present and working fine.
What is really weird is if I just manually press the 'scrape again' button it grabs all the bits properly and says everything is fine. It's always just the first attempt.
I have also tried manually calling the scrap API instead of letting Facebook do it when someone shares the URL for the first time and still sometimes (not always) it returns empty (just 'id' and 'url' returned) indicating the URL was blocked.
What's going on here it's driving me mad? We are nowhere near our API limits if maybe that was the issue...
Why would it say blocked first go on the debug page then literally 2 seconds later you press 'scrape again' and it works fine.
Just to note sometimes when it says blocked it still shows maybe the image in the link preview but no title or description. It's like it's grabbed some tags but then given up. Very strange...
I have checked our access logs and I can see 'Facebot' accessing our site fine.
Hope someone can help, I am really hoping this is some weird Facebook bug as I can't see any change in our code base that would effect this.
Facebook does not return anything helpful when this happens even with the API. I have no way in contacting Facebook direct either. If we are somehow getting blocked I would love to know why and fix that issue. But it's impossible to debug at the moment.
Just to note I have 3 sites all running the same code base (WordPress environment). They are all experiencing this issue. All been running fine for many years.
Cheers
This was to do with rate limiting that was not visible in the Facebook APP dashboard. Helpful...
Full details here: https://developers.facebook.com/bugs/232343637174087/
Solution for your problem: You can use Facebook image button after adding link on Facebook news feed, like shown in iamge
second thing upload image on othe site and give the image path to your website and then put it on your news feed, you can get definitely positive result using this two methods.
also refer this image
thanks hope this two will work for your problem
I hope someone can help - please bear with the explanation! I have 5 years of gallery photos, published here: https://www.girlsfly2.ca/past_events.html (redirects to https://www.girlsfly2.ca/past_events_2016.html).
Two main plugins are implemented - Packery bin-packs the photos into a gallery arrangement, LightGallery allows for individual slide-show and Facebook (and other social media) share.
The desired behavior is that a visitor is able to share a photo they like on their FB timeline - a preview of that specific photo, along with whatever comments they choose to make. Then, if one of their friends is interested by the photo, they can click on the photo - which is actually a link - and visit the source.
The initial problem I had was that FB would preview the source page, and not the individual photo. This is because the LG plugin uses a hash plugin to generate a "page" for sharing. The developer suggested a workaround was to pass an html link for each photo through the plugin, which worked and the photo previewed correctly.
This created a new problem in that when one clicked on the return link from FB one landed on the individual photo, with no way to navigate back to the main gallery since nothing else was loaded. This creates a frustration for the user, if they wanted to find out what the photo, and our initiative is all about.
The developer told me what I wanted was only possible if I created a complete HTML page for each photo (approximately 400 of them!). I had the bright idea to use server-side redirects in the interim - so that when one clicked on the image link it would redirect to the main gallery page of that particular year.
When I coded 2016 I tested functionality several times before implementing the redirects, and even though I didn't share each and every photo, FB seems to have cached the original links, not the redirects for all the photos.
I tackled 2013 and 2012 next but in this case the redirects were implemented in advance of publishing the respective pages and I discovered that FB is now previewing a default photo for all shares from each respective gallery. This is not ideal! I instantly had this problem when I created a batch folder redirect in 2016 which went away when I did individual redirects for all 207 photos, perhaps because some individual links were already cached.
Last night I played around with the FB scrape tool and disabled the 2013 redirects while I tested this. I'm wondering if I encourage FB to cache the individual photo links and then re-implement the server-side redirects if that will work?
Also, this is a very time consuming and cumbersome fix - and I'm guessing it won't be permanent either. Surely there is a better way through coding?
The bottom line question: Is there a way to force FB to preview the original html link, instead of it pinging the server, detecting the redirect and displaying a default image from the redirect gallery page?
Note that 2015 photos have not been redirected! The undesired preview behavior can be seen on the 2012 page, and at the time of writing the desired preview behavior is happening on the 2016 photos even the the coding style for both pages is the same. Also 2014 is not yet published so for the moment will yield a 404.
Sorry for the long explanation - I didn't see a way to shorten it. I really hope someone can help with this!
I have a slightly confusing setup on my site right now with:
A like button with the data-ref attribute set to the root domain of my site
A like box with date-ref set to a Facebook page I created for my site.
These obviously leads to different things, as the like button has 2.7k likes while the like box/Facebook page has around 600. This last number is also the number of likes I see on my regular Facebook page.
Now I also noticed that I have a second Facebook page saying it is the administration page for my webpage. The page has never been used to post anything, and it doesn't seem to be visible to anyone but me. This page has 700 likes.
I've been reading documentation on this stuff, but I'm not feeling confident about merging the pages or anything just yet, so I have a couple of questions I'm hoping someone with more Facebook experience than me can answer:
Where does this 700 number come from? It's not displayed on either my like button or my like box.
Is there any way for me to combine these three different counts into one?
The 700 is the count of people that liked the URL after you created the admin page which represents that URL - this is irrelevant now as that functionality is deprecated. ( see the link CBroe provided: developers.facebook.com/docs/reference/plugins/like/migration
It is not possible to migrate fans from one object or page to another, except as was allowed during the migration period outlined in that document, if you didn't migrate during that period you cannot move the fans of the site/domain to be fans of the Facebook page instead
I'm sure anyone who has worked with Facebook has encountered the url unreachable problem with the comments plugin and alike.
I managed to get around this initially by making urls go to the facebook app page rather the hosted page, figuring facebook would be able to find itself, and ammended the url with a query string which could internally redirect them to right content. For example "app.facebook.com/myApp/?myAppP=videos&myAppId=0001" would first of all load the facebook app page then redirect the iframe to show the videos page and play video 0001.
This worked great at first but seems to have become a little unpredictable. I have a list of different videos, all of which use the same url except that the "myAppId" is different so the correct video is loaded. However whilst the "comments" and "like" plugins work fine for about a 1/3 of them, the other 2/3 show the "url unreachable". I can see no correlation between the urls that work and those that don't. It seems completely random, but it is always the same one that do and don't work.
This has got me completely stumped. Any ideas?
try to disable sandbox on app settings
I use fan gates on a lot of different fan pages. The idea has always been you land on the page and see a like us to gain something after clicking like the page reloads and now the user sees the content behind the fan gate.
I noticed today that after liking a page it immediately goes to the wall, is this a bug? Is this feature deprecated? I don't have much wall activity on my pages, I'd rather users see our portfolio or special deals.
This is a bug on facebook right now, described here - https://developers.facebook.com/bugs/110015112440103
It'd be great to have an interim fix but since the code for the Like button is outside of what's accessible to the page tab, I'm having trouble imaging what a solution might look like, short of removing the address from your page to make it not a "place", which seem to be the only pages affected.
I've been having this problem for the past few days, but today I found the solution. It seems the problem lies with the new recommend dialog box on pages. This box only appears on pages for places and prevents the page from reloading. If you have a address assigned to your page then remove it and your fangate will reload in the window when liked and not redirect to the wall page. I know this isn't a preferred fix, but until Facebook fixes the new dialog box it'll have to do.