It seems like there's a bug with the facebook page tabs. Lots of them are rendering content on the bottom of the page.
Is there a change that developers must be aware of?
It is in fact a bug. I've just spent an hour looking into it.
It appears that they have increased the width of the right pane and it has caused the content area to shrink to less than 520px.
Unfortunately, the iframe that Facebook uses to display app content is hardcoded with a 520px width and you are unable to modify it. Need to wait till Facebook pushes out an update.
Edit: Bug reported to facebook already. Details here
Indeed, this is FB wide on all pages. All of our iframe apps have this issue, including Coke, Chevy, etc. FB just finished a push minutes ago http://developers.facebook.com/live_status/ and I hope that they're fixing this right now!
Problem still persists. There is a bug listed on Facebook http://developers.facebook.com/bugs/298512163544012?browse=search_4f3c5c801a70d4639459595. I hope it gets prioritized.
yup Facebook have stuffed up
Someone needs to fire the dev who committed these changes without testing them.....
Well my apps shrink to fit any width. My apps can fit as small as 100 pixels w to 1000 pixels. Therefore its not a width issue. I'm just happy its nothing on my end I was freaking out for a second. Even restarted the computer (LOL) whew!!!
Related
I've been working on an Android game, and I wanted to setup a webpage to redirect to the download page. This part was easy.
So I share it on my facebook timeline. Ok, my screenshot gets cropped horribly. Spend 30 minutes reading all sorts of guides on how to point facebook to the proper image for a thumbnail ...
No matter what I do, facebook always, always, always shows a horribly cropped image. I would like to simply specify the correct image to facebook using og:image but it seems to always ignore this. I've tried many different combinations of properties and it's always wrong. I've tried making the og:image square, doesn't matter. I've tried making it smaller, doesn't matter.
It's also hard to figure out if facebook is caching an old image or not, no matter how many times I go on the debug link and tell it to scrape things again.
Can anyone tell me any change I can make to show the entire image instead of the horrible cropped version?
I went to http://validator.w3.org and made sure the page didn't have errors beyond the og ones you apparently can't avoid.
The page is: www.playlunapuma.com
There must be a way to convince facebook to show a different image that looks good.
The thing that finally worked was resizing the og:image to 600x315 exactly.
When I use the Facebook debugger to view my website top page, under the "Warnings That Should Be Fixed" section, I get a few different errors. However, if I press the "Fetch new scrape information" button one time, then on the next round only one error remains.
The error I am currently trying to solve is this one:
og:image could not be downloaded or is too small
og:image was not defined, could not be downloaded or was not big
enough. Please define
a chosen image using the og:image metatag, and use an image that's at
least 200x200px and is accessible from Facebook. Image
'http://davegutteridge.com/+image/mizumushi_profile.jpg' will be used
instead.
Facebook seems to have cached an old image and is displaying that one, even though I have deleted it from my server.
The image I want to show is this one. To try and make it work, I've tried removing the "exif" data, I've tried making it square (my original was 1200 by 600 pixels), and I've ensured it's well above 200 by 200 pixels. I have also tried refreshing multiple times, and waiting over 24 hours to see if Facebook's cache changes. 48 hours after first discovering this problem, the debugger still shows the wrong image.
How do I get Facebook to reference the correct image?
Make sure you follow the specificiations: https://developers.facebook.com/docs/sharing/best-practices#images
Square images are not a good choice, but i just tested it in the debugger and it does work fine. Btw, those are just warnings, not errors.
I had a similar problem, where the image was set "correctly" but the debugger would not take it. So I played around, and figured out, that I could help the debugger by adding the og:image:width and og:image:height.
After that, the image was taken instantly :)
This Process is called pre-caching and here is the ref to it ;)
https://developers.facebook.com/docs/sharing/best-practices#precaching
Hope this helps!
Seems like FB has an issue fetching or displaying properly set og:image on our links suddenly - this affects share dialogs etc.
Everything has been working fine so far. I noticed this issue today.
Debugger https://developers.facebook.com/tools/debug/og/object/ shows the image after refetching (try: http://cakesdecor.com/cakes/194565-3d-vintage-clock-cake) but the image doesn't appear in the share dialog at all.
Is it a temporary bug or are there some new FB policies re images?
Approx. 2 hours ago, this bug was confirmed by FB!
see: https://developers.facebook.com/bugs/978421888869140/
I confirm this issue also occurs on multiple sites I own. It began some time in the past 14 hours. The debugger is returning a valid output (but the post preview at the bottom is lacking the image).
My guess is that it is somehow related to the face that today (30/apr) they've forced all fb apps to migrate to sdk2.0.
I sure hope they're already working on a fix... but go figure :-/
Hi anyone have idea what's going on with the iframe apps on facebook keep loading the xd_proxy.php? I haven't notice it's a new or existing issue because my apps screen is fix, today, when I change some code,I scrolling the screen with my mouse, and discover that the xd_proxy is loading while scrolling(no matter use mouse wheel, kb arrow, scroll bar..), I search some posts in the google and stack overflow, but with no luck, none of them can solve it, I've try add the channelurl, rearrange the javascript...etc, but no luck, please help, thanks in advance.
This is logged as a bug in Facebook's bug tracker now. Best way to get it fixed is to vote for it!
http://bugs.developers.facebook.net/show_bug.cgi?id=16176
Facebook fixed a bug we have been waiting on in their JS SDK this week so we were planning on switching from the old JS SDK to the new but during final testing came across this as well. Looks like window location is being reported back.
Anyone know if this is new and what exactly it is used for? Can it be disabled? Wonder what this would do to performance across different environments.
This starts happening after FB.init in window.fbAsyncInit is called with de JS SDK. It is passing height and width of the client and scroll as parameters with type canvasPage.update. It might, but I do not know, have something to do with a bug earlier this year when apps in iframes weren't resizing, something like a work around.
I just noticed this today as well, and initially thought it was due to FB.Canvas.setAutoResize() being called surreptitiously, but nope, it seems like scroll has been bound to this update.
I'm about to make a facebook application and I'm confused about what width I can design for. It seems that at the moment you have 760px at your disposal, but a lot of sources say this will be reduced to 520px in the beginning of 2010. Being halfway through 2010 already, I'm wondering if this is really happening? 520px seems very little? Does anyone know if and when the change will happen? What will happen to existing applications that are wider?
The 520px width is in reference the Application-Specific Tabs, not Applications proper.
Applications still use the full 760px width.
I've no idea what they intend, so take this with a pinch of salt. (Similarly, treat any assertions by non-Facebook staff with a heavy amount of cynicism - those crazy Zuckerbergites work in strange ways...)
Anyway, the last time they introduced a new width, they gave developers the option to stick with the old width system.
In fact, that option is still there (in the app settings):
Given that that option is still there, I'd cautiously suggest that:
They're not realistically planning another change any time soon.
If they do, they won't force it on developers
Hope this helps.