All page tabs are blank

If that doesn't work, its probably because some module is initializing the theme too soon. Sometimes error messages cause this, so look in your drupal log for any errors or warnings.

Try putting dpm() or breakpoint in init_theme(). To see when it is first called and why. Something like dpm(debug_backtrace()); should tell you.

First of all, enable fb_devel.module. Reproduce the error and look for any messages on the page or in the drupal logs. The README.txt has basic instructions for troubleshooting.

From that dpm() output, you need to expand the stack trace to figure out what is calling theme().

Since you did not have devel.module installed until comment #4, I'm assuming you don't have fb_devel.module enabled. Enable it.

You need to figure out the first argument being passed to theme(). And you might need to inspect further up the call stack to see exactly what it making the first call to theme().

Make sure you've read everything in the readme.txt, and the documentation that it refers you to. Pay close attention to anything that fb_devel.module has to tell you. Its often a good idea to enable devel info for anonymous, when troubleshooting these sorts of things.

You can see what modules/fb thinks is going on by enabling the block it provides. It spews out a lot of info. At the very least get to the point where it knows the type of page is a tab. If it knows the type of page, and still has the wrong theme, you'll have to figure out what is causing init_theme() to be called.

Try adding debug output in fb_tab.module. Look for the FB_OP_INITIALIZE clause of fb_tab_fb(), add something like:

 elseif ($op == FB_OP_INITIALIZE) {
    if (fb_is_tab()) {
      $config = _fb_tab_get_config($fb_app);
      dpm(__FUNCTION__ . ": config theme is $config[custom_theme], global custom_theme is $GLOBALS[custom_theme], global theme is $GLOBALS[theme] .");  // Add this line of debug output.
      if (!isset($GLOBALS['custom_theme'])) {
        $GLOBALS['custom_theme'] = $config['custom_theme'];
      }
...

If global theme or custom_theme is already set, it will not attempt to change it.

When $op == FB_OP_CURRENT_APP, fb_tab.module should return the $fb_app data structure. (Basically, fb.module is asking "which app is currently active?" and fb_tab.module is saying, "this is a page tab, and therefore I know which app it is."). Can you tell whether it is returning an $fb_app?

If fb.module should then initialize the facebook php sdk, it will call FB_OP_INITIALIZE. Since it is not calling that app, either it is failing to initialize, or no $fb_app was returned.

The other ops don't matter in this case.

I've been ripping out my hair for over a week now with the exact same problem, and a few other people seem also to have the problem when looking in the issue queue - maybe there is a problem with the module? the theme is never initialized. Here is a similar issue: http://drupal.org/node/1197116

if i do a dpm for $fb_app in the end of the fb_tab_fb function it returns all the informations from the app currently used, in the variable I can see that fb_app_data->fb_tab->custom_theme is indeed set to the custom theme it should be, so it looks like this is not the problem.
I should add that I have the problem in Drupal 7, but it might as well be the same.

_fb_tab_get_config also returns an array with the correct custom theme only used for tabs, so I'm pretty lost.
I can also add that the same theme works perfectly when set for canvas pages.

I found a fix for the Drupal 7 branch, see: http://drupal.org/node/1197116

Sounds like the 7.x version is sorely in need of that fix.

This issue is the 6.x version, right?

True enough that I don't know what's going wrong. Also was away all of last week.

Are you including fb_settings.inc in your settings.php?

try

include "sites/all/modules/fb/fb_settings.inc";
print "<pre>" . print_r(fb_settings(), 1) . "</pre>";

and paste what you see here.

On the facebook "advanced" settings, do you have it using oauth2 signed requests?

Try...

include "sites/all/modules/fb/fb_settings.inc";
print "<pre>" . print_r(fb_settings(), 1) . "</pre>";
exit();

It wont render the page, but should show you the data.

Also, try the .dev build instead of the 3.1. There may be a fix in fb_settings.inc to parse the signed requests.

So it looks like fb_settings.inc is determining that it is a page tab.

The profile_tab_url looks fine. That's how it now works. When you get a blank page, check your error logs. Make sure PHP is configured to show all errors including startup errors.

Go back to #16, are you sure even with the updated modules/fb that fb_tab.module is not returning an $fb_app?

FB_OP_INITIALIZE is a constant. FB_OP_INITIALIZE and 'init' are the same thing.

Is the theme you're trying to use enabled?

During that ($op == FB_OP_INITIALIZE), what is $GLOBAL['theme'] and what is $GLOBAL['custom_theme']?

When init_theme() first runs, what is the value of $GLOBAL['custom_theme']?

init_theme is somewhere in drupal core, maybe includes/theme.inc. I'm not sure.

Find it a determine whether i$GLOBALS['custom_theme'] is set to something else when it is called.

We're back to where we were in comment #2.

Put something like

drupal_set_message("custom theme is " . $GLOBALS['custom_theme']);

At the top of the init_theme function.

I have the same problem, Drupal stops and display blank page.

Tricky workaround: using Domain Access create a subdomain for www, fb app and fb tab. Than the rest of configuration is inside Facebook. Poor but works. Good to have SSL certificate with wildcard.

Usually when drupal displays a white screen there is an error somewhere, i.e. an apache log. If PHP is configured correctly it will display the error somewhere.

Just upgraded to the Dec. 12th dev, cannot say it made a difference. I think infotrendy had it right: this is a bug report since multiple suers are having the problem. I've also checked the Apache error logs, nothing there. It's not a parsing error, otherwise Php would display an error. I think you need to go back to comment #42 and look how I mention that init_theme isn't called in the module. Since its not there, where is it called? I don't know Drupal, but I think that is the starting point. We can also show that it isn't an PHP error because I can echo stuff from inside the functions in fb_tab.module in order to not make it a blank page.

I can tell you exactly what's happen too:

function fb_tab_fb is called six times:
The first time it doesn't evaluate to any of the if_elseif statements so it ends.
The second time, it evaluates to true for the FB_OP_CURRENT_APP && fb_is_tab, so it steps through that.
The third time it doesn't evaluate so it doesn't run.
The fourth time it runs the FB_OP_INITIALIZE and it hits the fb_is_tab() statement right after that and evaluates to true. IT then sets $GLOBALS['custom_theme'] equal to facebook. It then sets $use_ob to true. It doesn't look like it sets $dummy equal to anything. Then, it runs the if ($use_ob) { statement. After that it hits the if ($_REQUEST['q'] == FB_TAB_PATH_VIEW), but it evaluates to false - so nothing associated with that statement runs. And, finally, the if ($path && $path != FB_TAB_PATH_VIEW) { evaluates to false as well, so it doesnt run either. It's officially out of stuff to run with that FB_OP_INITIALIZE
The fifth time it hits fb_op_post_init.
The sixth time it finally hits FB_OP_EXIT && fb_is_tab()) . It evaluates to true on if (isset($GLOBALS['fb_tab_post_process']) && $GLOBALS['fb_tab_post_process']) { . However, somehow it gets stuck on this $output = ob_get_contents();
and any echo statements added after that don't display.

So, what happens there - is that normal? what is ob_get_contents() supposed to do? If it stops the rest of the function from running when it otherwise should, we now know where the issue lies. Or, is it perhaps echoing stuff before the ob_get_contents() is called is messing up the function? Or perhaps the output buffer isn't set properly in the previous functions? Is there another way to go around using the ob buffer?

also, another interesting question I have is should I be able to echo stuff when the ob_start() has been called?

If I can somehow confirm the case, let me know, but results seams to be the same.

During general tests of FB Tabs I figure out on one forum (that I can not find now), that this thing happens on polish hosting - home.pl (my case), and the solution was to change the extension of the file to .php (.html didn't work). That test was outside of Drupal.

Please try this patch. It renames a couple functions, for clarity. But the important change is to not rely on $_REQUEST['q'] to determine the path.

This works, you need to commit this ASAP and dump out a new version of this as a critical release, haha.

That being said, it opens up a new can of worms: the handling of links within the iframe isn't uniform: sometimes they will open in the iframe, sometimes it will trigger a new canvas, and sometimes it will open in the main browser window. When it does open in the iframe, sometimes it will carry over the Facebook theme, sometimes it won't. It does seems, however to be dependent on the type of page that you are linking to: for instance, my links that go to custom pages/panel pages are the ones that don't carry the theme over.

At this point, I just enabled processing on iframe tabs and disabled Links send user to canvas pages so it just pops up with the link directing to the main website and its theme.

There's a checkbox on admin/build/fb/fb_tab to control whether links go to canvas pages. If the link is generated by l() or url() functions, this should work. If the link is generated some other way, there's not much modules/fb can do about it.

I'll mark this issue fixed when the patch is pushed to git. Any further discussion of the links should be moved to its own thread.

This was actually committed some time ago. Never updated issue status.