Like Button and other XFBML not working without application

That will certainly cause other problems. I suggest you remove that and look for javascript errors using firebug.

A Like button should work fine without an application. So what you describe sounds like a bug.

It might be that fb.module does not initialize the javascript unless there is an app. I'm not sure the cause.

The js is in footer, therefore can't transform the widget. Take it into the header works well. I don't know, what would be the solution, i think there are some reason to put fb js in footer..

(subscribe)

In $fb_init_settings (fb.module) the xfbml is set to FALSE which "turns off" xfbml, so it seems. Why that's the default, I don't know. Setting that to TRUE fixed my issues with fb markup.

fbAsyncInit in fb.js should be parsing the XFBML. I believe the latest version fixes this problem.

I have the same problem, installing the latest dev version (fb-6.x-3.x-dev) did not help. Firebug is showing "FB.getLoginStatus() called before calling FB.init().". Markup for the like button (<fb:like href="https://www.example.org/news/201101/good-news" show_faces="true"></fb:like>) is in the page code, but the like button is not appearing. Will investigate more.

Comment #8 from tobias helped. Now I have fb-6.x-3.0-rc13, and in the file fb.module, around line 151:

// Data structure to pass to FB.init();
  $fb_init_settings = array(
    'xfbml' => TRUE,
    'status' => FALSE,
    'cookie' => variable_get(FB_VAR_USE_COOKIE, TRUE),
  );

Yup, 'xfbml' => TRUE fixed like buttons for me.

My problem was that the Like button would sometimes appear and sometimes not appear. #8 has so far resolved my issue (along with fb-6.x-3.0-rc13)

If you're using the 'xfbml' => TRUE "fix", you have some other issue which you will no doubt break something else in the future. I highly recommend not making that change.

Probably, you are including facebook's javascript ("all.js") more than once. Facebook stupidly uses a global FB so there is a race to initialize it. If some chunk of code initializes it before fb.module does, then none of your fb.module settings will be present in javascript.

So search your page's source for "all.js". You should see it only once, in the javascript settings in the footer of the page. If you see it anywhere else, for example in a <script> tag, delete that script tag from whatever block or content that it appears.

I'm only seeing one mention of all.js, in the footer.

I can confirm that the 'xfbml' => TRUE "fix", solves the <fg:like></fb:like> display issue. With or without the "fix", I only see one instance of the all.js file, and that is in the page footer, where fb_init_settings is added to Dupal.settings.

I've also noticed that whatever I set the value of xfbml to, get's directly injected into Drupal.settings. for instance, 'xfbml' => 'eggnog' results in jQuery.extend(Drupal.settings, {"fb":{"ajax_event_url":"http:\/\/example.com\/fb\/ajax","fb_init_settings":{"xfbml":"eggnog" ...
(which, indecently, works.. because it isn't false...)

Now I see that FB.getLoginStatus() does nothing when there is no application. It doesn't give the code in fb.js a chance to parse XFBML.

I wish I could remember exactly why I moved the XFBML parse code there. Hope to find a solution shortly.

Here's a patch I'm testing.

I've noticed an error in firebug:

XUL box for span element contained an inline #text child, forcing all its children to be wrapped in a block.

... but I'm not sure its related to this change. If anyone understands that or knows its cause, please let me know.

I tried this as suggested in #940018-43: FB Connect Unstable: FB.login() called before calling FB.init(). and it definitely seemed to have fixed the issue I reported at #940018-42: FB Connect Unstable: FB.login() called before calling FB.init()., like button seem to be working fine. I didn't saw any strange thing on chrome console, haven't tested on ff though yet. It also seem to have removed the warning on the getLoginStatus() called before init().

Dave,
the patch in #18 solved the issue for me. (I'm running currently and tested with only the fb.module enabled, no others from the project, no fb apps)

Also, the XUL box firebug error did not show up in my environment, though it sounds like you have a <span> element somewhere on that page that is displaying as a block (via a css rule similar to: span { display: block; } ??). That could be completely wrong though too :)

Great. Glad this is resolved.

Hey Dave,

I just wanted to thanks for your committed work - and working with Facebook is liking working with a moving target and raging bull.

Regardless, I tried this and it didn't work tragically. I'm using the latest release 3.3, Chrome, and included both the Like and Comments section.

Without doing the suggestion mentioned at #12 it just simply doesn't work properly.

Any ideas? What's also interesting is looking at the console (for Javascript) I am getting this error as well (when I set xfbml to FALSE).

FB.getLoginStatus() called before calling FB.init().

Update: For the record I only have the basic FB setup and not the FB Connect which might cause some problems I'm not sure.

Same problem here.. I've implemented the hook_page_build() hook in a custom module, changing the xfbml value to TRUE. I've chosen this hook because it is called after hook_init() and before hook_page_alter(), so I don't have to care about the modules' weights.

/**
 * Implements hook_page_build().
 */
function YOURMODULENAME_page_build(&$page) {
  if (function_exists('fb_js_settings')) {
    $fb_init_settings = fb_js_settings('fb_init_settings');
    $fb_init_settings['xfbml'] = TRUE;
    fb_js_settings('fb_init_settings', $fb_init_settings);
  }
}

PS: I've done this in D7, but I believe, the hooks are the same in D6, as well as the function name from FB module

Without doing the suggestion mentioned at #12 it just simply doesn't work properly.

Did you try the advice in comment #13?

If you have to set XFBML to true, that implies something is off with your setup, and you will have problems if you ever decide to host an application.

Did you try the advice in comment #13?

I guess, you mean comment #14 (http://drupal.org/node/1160934#comment-4540254)

I'm 100% sure, that there is no duplicate FB js file. But the like button only shows up with xfbml = true. It's also set to true, when you use the default code provided by FB here: http://developers.facebook.com/docs/reference/plugins/like/

<div id="fb-root"></div>
<script>(function(d, s, id) {
  var js, fjs = d.getElementsByTagName(s)[0];
  if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "//connect.facebook.net/de_DE/all.js#xfbml=1";
  fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

But nevermind, for me this situation is ok as it is. I don't need a deeper FB integration on this site than showing like buttons and a like box. I just wanted to provide an elegant solution for others having the same problem

Yes, I meant #14.

If you see FB.getLoginStatus() called before calling FB.init(), you're probably using more than one facebook-related module, and the two are not compatible together.

Firebug's javascript debugger can be useful to track problems down. You might see warnings in the console or get a stack trace.

You're right that Firebug's console is reporting "FB.getLoginStatus() called before calling FB.init()." But I do not use a second FB related module. Is there a problem when not setting an appid, when only using the like button and like box features? Normally I don't use a Drupal module, but insert the code manually. And there's always the xfbml=1 set in the parameters. So it's the first time I ran into this problems

Has this patch (#18) been committed?
I'm also getting "FB.getLoginStatus() called before calling FB.init()." error with the current 3.3 release and with no other facebook related module installed.

Path #18 was committed. However a more recent commit seems to have brought back the bug. Thanks for pointing it out. I will try to fix it.

Facebook has made it harder to detect the state we need to look out for here. See if the attached patch solves for you.

pushed #31.