form submit path/action not right?

There's some really tricky stuff that happens in form submission on canvas pages. fb_canvas attempts to change the form action, so that values are submitted to your drupal server directly, instead of apps.facebook.com/yourapp/... It's entirely possible that it doesn't do this properly in all cases.

I'm curious, add this snipped to hook_form_alter(), and let me know if it fixes the problem:

function dff_custom_form_alter(&$form, $form_state, $form_id) {


  if (fb_canvas_is_fbml()) {
    // Special canvas page form handling *only* when enctype is set.            
    if (!isset($form['#attributes']) ||
        !isset($form['#attributes']['enctype'])) {
      // Prevent fb_canvas from changing the form's action                      
      fb_canvas_form_action_via_facebook($form);

    }
  }
}

What the snippet does is send form posts through apps.facebook.com, unless the enctype has been set which usually means the form has a file field.

No, don't edit anything in modules/fb/ Instead make your own module. It's really useful in all Drupal sites to have one small module of little customizations like this. You can't always do all you want just through configuration. In my example, the module would be called dff_custom.module.

Also use the <code> or <?php ... ?> tags when posting here.

I just tried upgrading to the head revision and also began having trouble with the form submission. When submitting forms from canvas pages it began redirecting the users back to the site vs. staying on canvas version. I reverted back to 1.35 of the fb_canvas.module and it seems to be fine again. I didn't look too close as to what the changes were in 1.36 that caused this behavior, but it looks like it has to do with the new redirecting stuff for permissions?

So, you've created a custom module, not making changes to fb_canvas, right?

Load your canvas page and use your browser's view source feature. At the top, in comments, should be the FBML your server sent to facebook (you must be logged in as the app developer for this to work). Copy and paste here exactly the <form action=...> tag looks like. Use drupal.org's <code> tag so that what you paste here can be read.

I'm pretty sure the wonky crud at the end of the action comes from Drupal, its just replicating the current request, and facebook has appended all those values in order to send the iframe all the info it needs.

The auto_submit_path doesn't have those extra attributes. What the heck is #auto_submit_path? Is that even a documented feature? Is it specific to five star module? Whatever it is, it doesn't have those attributes, so my guess is that it is called via ajax or something, but treated as a different session, so it fails to do whatever it is supposed to do.

What browser are you using? You could try setting $conf['fb_session_cookieless_iframe'] in your settings.php, before including fb_settings.inc. That's just an experiment but I'm curious if it makes it work.

Dave,

I just upgraded to beta 6, forgetting that I had rolled back the fb_canvas.module as noted in comment 5 below on my last upgrade. I broke my site again, basically when the forms were submitted they were submitted back to the site, not the facebook app.

I then went and added this patch to my custom module and it seems to have cleared things up. Is this something that needs to go into the mainline?

I'm not understanding... it's beta 4, right? And what's "this patch?"

Sorry, you're correct beta 4. I thought I was replying to your earlier thread post and that it would show nested. The code snippet you shared in this comment: http://drupal.org/node/711654#comment-2589684

Which forms were causing problems? Can you submit a form in drupal core like contact or add a node?

It was just a typical add node form for a CCK type. No frills.

I also just tried the contact form, it also isn't working. Please note that when I say "isn't working", the form submits, it just ends up bringing the user off the canvas page and back into the site. It seems to me that this fb_canvas_form_action_via_facebook call is needed from canvas pages.

In my work I use FBML canvas pages. But facebook changed the default to iframe. I'm guessing everyone with this problem is using iframes and not FBML?

No, I am also using FBML canvas pages.

Dave,

I see on the new release that the patch from comment #1 is still not in? Don't we need this call to fb_canvas_form_action_via_facebook so that the actions work correctly from canvas pages? From what I've seen it seems that I do, am I missing something? It doesn't look as though that method is called from anywhere else.

Sending the form via facebook is OK for some forms, but not forms where files are uploaded, for instance. So I can't invoke that for all forms. You can, in your custom module, if you like.

Please try this patch, which is working for me at least for the contact form which is all I've tested so far.

I applied the patch, but it still doesn't seem to work. This stuff all used to work? I rolled back to version 1.35 of the fb_canvas.module which is the last version that worked correctly in all cases and the forms both worked again. But, then of course this broke other things.

Contact Form - Works with the patch, meaning the call to fb_canvas_form_action_via_facebook.
http://apps.facebook.com/funfriendfacts/contact

CCK Form - Standard CCK form, this form doesn't work with or without the patch. With the patch, the call to fb_canvas_form_action_via_facebook is not envoked. I'm guessing this is b/c this form accepts file uploads? If you try submitting the form, it puts you into an infinite redirect.
http://apps.facebook.com/howigotengaged/node/add/engagementstory

Dave, is there any chance you could reroll this patch for beta7? Or has it been committed?

That patch has been committed.

i'm using fb b8, with iframe canvas. form submissions are broken with ajax, like fivestar and with the standard contact form, it returns the user to the system default theme - which wasn't designed for fb iframes =)

no errors or warnings are generated and nothing written to the /var/log/httpd/

...will we need to patch every form used within fb canvas pages, like comment #14 by mikerasmussen ?

dave have you given up on this thread?

on line 241 of fb_canvas.module : "// Unfortunately, other modules' hook_exit() may not be called." - in what cases would they not be called?

i went ahead and installed beta9 - but even the standard contact form still redirects the user back to the non-fb site, with the callback url prefixed.

***i just looked at watchdog:

The Facebook Application labeled dffb_beta9test has a suspicious connect_url. The value is http://*/fb_cb/144/, while something starting with https://* was expected. Consider editing dffb_beta9test.

it looks like secure_pages module is forcing callbacks through https - even when i disable secure_pages; apparently this is stored somewhere not easily edited? maybe as a drupal variable or as a database field value? please let me know everywhere it's stored so i can edit it thoroughly - or is this base_url created dynamically for fb, based on the site base_url?

thanks for your great work dave =)

i should note that secure_pages directs requests to admin/* to https - where the fb app is now created. even when disabling and uninstalling secure_pages, i still get requests to the callback through https!

**another edit - i've tried both iframe and fbml canvas pages and still get redirected. also, with iframe, even after applying the xd_receiver.htm channel patch to enable resizeable iframes in fb canvas pages, form submissions will load the returned page with scrollbars [or for some reason seems to ignore the code added to page.tpl.php to resize the iframe canvas]

When you save an application, it sets the callback url and a few other settings on facebook. So if you are editing apps on a url that starts https://.... you'll get a callback url that starts the same.

you can edit the settings manually on the facebook form. If this works better you should uncheck the "set application properties automatically" checkbox.

since user logins require https for the site, it looks like the only solution here is to use https for the entire site, since facebook app does not have a property to set the secure base_url.

anyway, this is the error logged to the screen and watchdog after enabling an iframe theme [actually just the framework theme modified to use the xd_receiver for resizing iframes to fit the canvas]:

call_user_func_array() [<a href='function.call-user-func-array'>function.call-user-func-array</a>]: First argument is expected to be a valid callback, 'fb_canvas_theme_page_override' was given in */includes/theme.inc on line 656

noticed that after this message is received, if i go to themes, the theme selected for iframes is disabled [was enabled before this message].

... after trying to get fb to work with iframes, i've given up on it at the moment - i really don't know what's meant by "a facebook aware theme"... so i rely on your expertise built into fb_fbml. the main problem is that a lot of the neat functionality that comes with js is lost with fb_fbml.

dave, i've tried both http and https [with and without secure_pages enabled, and checked that the fb app was using the respective server for the callback] - and using only the fb_fbml theme, forms still redirect the user off the canvas page.

i've tried using both beta9 and the latest dev version [today's]. what am i missing?

Upgraded to beta9, still having the same issues - form submits break the theme inside the canvas iframe and redirect to the main site.

It would be nice to know a few things....

First look at the source of the page before submitting the form. What is the form's action attribute?

Enable the devel module and select the display redirection page option. With that enabled, is it the form post or is the redirect that follows which sends the user outside the canvas page?

Looked at the source for an exposed Views filter form, the default Drupal search form, and a node add form - all have the same action:
form action="/fb_cb/applabel/" with ?query data appended to it if that's in the current URL.

After enabling the display redirection page, the intermediate redirection page adheres to the fb_fbml theme fine - it's the page it redirects to that breaks it. EDIT: except for the exposed Views filter which doesn't seem to have an intermediate redirection page.

Dave, the form tag for the native drupal contact page:
<form action="*/fb_cb/applabel/contact" accept_charset="UTF_8" method="post" id="contact_mail_page">

the "Facebook Devel Page Info" blocks don't show, even with anonymous visibility enabled.

...requiring visitors to authenticate the app enabled doesn't allow me to logout [it automatically logs me back in] to try to login as user 1 if that's required to view the fb devel blocks - when i allow anonymous an error is generated:

Errors while loading page from application
The URL https://*/fb_cb/applabel/home did not respond.

Please try again later. We appreciate your patience as the developers of * and Facebook resolve this issue. Thanks!

sorry, my mistake on the devel blocks - was a role permissions oversight.

fb devel block:
url() returns = */fb_cb/applabel/

when the app gets redirected, it gets redirected to {base_url}/fb_cb/applabel/{path}

i switched both iframe and fbml themes in the app to use the included fb_fbml theme, although the app setting is for fbml.

this happens in all my form search, node submit. It redirect me back to my site rather than staying on fb.

i updated to beta10. it doesn't seem that a fix for this was included?
how can i assist you in patching?

Hi all,

i did a fix for this and it working fine.. same fix applicable to links also

in setting.php

if(strpos($_REQUEST['q'],"b_cb") )
{
$conf = array(
'theme_default' => 'fb_fbml',
);
}

mahen1984, I think your code is just masking the problem, not actually fixing it. Or you have an entirely different problem.

jaypark, I don't have a fix for this. With beta10, I made an iframe app and tested its contact form. It worked fine for me.

when posting a comment, using beta10, fb_fbml, it will get posted a multiple of 3 times, either 0, 3, 6. however, when implementing hook_comment to post a status_update, it's posted only once.

odd, this warning was returned after flushing all caches:

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'fb_canvas_theme_page_override' was given in /*/includes/theme.inc on line 656

in fb_canvas.module, just above fb_canvas_theme_page_override() there's a comment "The second hack calls fb_canvas_process() to munge the entire page." - is this the culprit?

// fb_canvas.module::fb_canvas_process()

// Change paths to files to fully qualified URLs. This matches relative                        ... why paths to files to urls?
      // URLs that do not include the canvas (that is, not matched by previous            
      // patterns).
      if ($base_path != "/{$_fb_app->canvas}/") {
        $patterns[] = '|="'. $base_path . "(?!{$_fb_app->canvas})|";
        $replacements[] = '="'. $base_url .'/';
      }

mahen,

$conf['theme_default'] = 'fb_fbml';

sets the system default theme to fb_fbml, not good if you've users making requests outside of facebook to your drupal site... it's a workable solution iff the system default theme is the same as the dff theme. even if the dff theme works inside iframe, if you want to implement resizeable iframe canvas pages using facebook's solution, your pages requested outside dff will have no scrollbars

when using an iframe theme for dff, at some point the iframe theme gets disabled during form submission.

dave, is there some way to define a 'system default theme' for dff? the only way to make this issue disappear at the moment is if the dff theme is the same as the system default.

I'm not seeing these problems. Do you have global redirect enabled? Or any modules that muck with hook_exit() or call drupal_goto() to an absolute url?

Hey does this help? Try adding this code to fb_canvas_form_alter(), or really any hook_form_alter()...

  if (fb_canvas_is_iframe()) {                                                                                
    // Include the fb_sig so that when post is received, we know we are still in a canvas.                        
    foreach ($_REQUEST as $key => $value) {                                                                       
      if (strpos($key, 'fb_sig') === 0) {                                                                         
        $form['fb_canvas_iframe'][$key] = array(                                                                  
          '#type' => 'hidden',                                                                                    
          '#value' => $value,                                                                                     
        );                                                                                                        
      }                                                                                                           
    }                                                                                                             
  }      

Dave, that code fixes submissions from an exposed Views filter (yay!), but node adds still break.

comment, contact forms stay at a.f.c - but the iframe theme gets disabled & the system default theme renders.
i checked the fb module weight in the system table, there was only 1 other module with a lower weighting, getid3 with -10. i disabled it and now fb is in front at -2... still no joy.
tried your last snipped above, included it in a module with same weighting as fb... =(

on trying the fb_fbml theme, i get these funky warnings:

* warning: file_get_contents(sites/all/modules/fb/fb_fbml.js?v=1218825267) [function.file-get-contents]: failed to open stream: No such file or directory in /*/includes/locale.inc on line 1708.
* warning: file_get_contents() [function.file-get-contents]: Filename cannot be empty in /*/includes/locale.inc on line 1708.

does this have something to do with "Chang[ing] paths to files to fully qualified URLs." ?
http://drupal.org/node/711654#comment-2795898

using fb_fbml redirects away from a.f.c on form submission [comment, contact] ><

I have the same experience as #50. Exposed Views filter now works, but node adds still no go. The node form has the 'fb_canvas_iframe' array.

Also, I have my iFrame theme set as system default, and it only makes them look similar. The links in my resulting created nodes, are no longer to apps.facebook URLs

When the form submits, say node/add/story, instead of the browser's URL locator showing the submit redirecting you to node/25 view, it still says node/add/story. The content in the frame is the view for node/25, though, but the links are no longer apps.facebook links, all mysite.example.com/fb_fb/mylabel links. Since they are all target="top" links, the next click takes you out of FB chrome and to the site's theme by itself.

But with the code from #49, the Exposed Views Filter results now have links to apps.facebook links.

I'm wondering if a custom submit handler for the node, would allow me to force the redirect to the proper URL.

I found a way to work around this. It ain't pretty, but its working. I have to get this product launched Monday, so after that I will post my experiences and how I got the form submits to return to the FB chrome and the iFrame theme within.

jaypark,

i got the fb_fbml theme only for facebook iframe application. the site remain with the same theme. i made a little modification in my code. can you have a look and let me know

if(strpos($_REQUEST['q'],"b_cb/218/"))
{
$conf = array(
'theme_default' => 'fb_fbml',
);
}

}

The problem is not that the system theme is 'disabled'. The problem is that when you submit a form, the action takes you to what FB sees as 'another site', one apart from the FB iFrame site. Look at the Locator when you submit a node/add ... does the URL say 'http://apps.facebook.com/myapplabel/node/12345' or does it still say 'http://apps.facebook.com/myapplabel/node/add/nodetype'?

Here I get around the problem ... but be warned ... this will NOT solve form validation errors. For now, my validation errors are handled by a custom validation handler function that redirects the user back to an 'unchanged' form, the same form you were on, but reloaded. I am working on a more graceful-looking solution.

Here is how I handle node submits.

function custom_form_alter(&$form, $form_state, $form_id) {

  if ($form_id == 'views_exposed_form') {
    // I don't want the exposed_view forms to redirect, but I may want to do something custom to the form(s) here
  } else {
    // By making the form's action target=_top, the form results leave the frame and load a new URL in the locator
    // But this will create the problem of 'relative URL' actions, and your resulting window will be of your Drupal site URL outside of FB chrome, in the site default theme
    // We will correct this later

    $form['#attributes'] = array('target' => '_top');
  }

// Dave's suggestion below fixes the issue with exposed form results messing up the theme
// So, THAT problem IS a theme problem

  if (fb_canvas_is_iframe()) {                                                                               
    // Include the fb_sig so that when post is received, we know we are still in a canvas.                       
    foreach ($_REQUEST as $key => $value) {                                                                      
      if (strpos($key, 'fb_sig') === 0) {                                                                        
        $form['fb_canvas_iframe'][$key] = array(                                                                 
          '#type' => 'hidden',                                                                                   
          '#value' => $value,                                                                                    
        );                                                                                                       
      }                                                                                                          
    }                                                                                                            
  }     

// Now we setup how the results properly redirect
// Also keep in mind that the links to your forms may contain a destination query string, and that other modules may redirect your forms for you
// I suggest really getting to know your forms, their IDs and their submit handlers by checking the #submit array in $form

// This will cover node forms, because with adds you want to redirect to the node ID, but it hasn't been created yet. 
// I picked this up from another Drupal discussion, and this works well for me.
// With most other forms, you can just attach a submit handler to $form[#submit][] = 'my_handler_function', but to get the Node ID ...
  if (isset($form['#node']) && $form['#node']->type .'_node_form' == $form_id) {
    if (fb_canvas_is_iframe()) {                                                                               
      $form['buttons']['submit']['#submit'][] = 'custom_node_redirect_handler';
      if (isset( $_GET['destination'])) {
        $dest = $_GET['destination'];
        $fbpath = _custom_my_fb_app_path();
        $pos = strpos($dest, $fbpath);
        if ($pos === FALSE) {
          $dest = $fbpath . '/' . $dest;
        }
        $form['custom_dest'] = array(
          '#type' => 'value',
          '#value' => $dest,
        );
      }
    }
  }
}

And now we write our handler function. Keep in mind that the destination link is stored for us to use as the, ahem, 'final destination' - as any other module that sets $form_state['redirect'] will override the value in the destination query string. So, we're going to guarantee the destination link works.

We also have to make a kludgy path-making function. You can get the myapplabel part from the field fb.canvas, but I just hardcoded it. I create an FB app for each stage: dev, stage, prod - and each one uses a different app label for the URL. Here I'll just pretend there is one app and one label.

function _custom_my_fb_app_path() {
  $domain = 'http://apps.facebook.com/';
  $myapplabel = 'myapplabel';
  $path = $domain . $myapplabel;
  return $path;
}

function custom_node_redirect_handler($form, &$form_state) {
  if ($form_state['nid']) {
    // you can optionally reload here if you need to get something from the node for context. Commenting it out, but showing it as an option
    // $node = node_load(array('nid' => $form_state['nid']));
    if (isset($form['custom_dest'])) {
      $form_state['redirect'] = $form['custom_dest']['#value'];
    } else {
      // This handler was added because we are in an iframe. So I just call for my fb path again
      $fbpath = _custom_my_fb_app_path();
      $form_state['redirect'] = $fbpath . '/node/' . $form_state['nid'];
    }
  }
}

And that is pretty much it. You may want to check my code here, as I just chopped up my working model to remove all the other nasty bits I have in it, so I may have chopped off some syntax by mistake.

Obviously there are other forms, like comment forms, and contrib-module forms. Comments usually redirect back to the node view, so you don't need to grab the $cid. I grab $form['nid']['#value'] so I can redirect, and I use a separate handler function for each 'class' of forms: exposed_view, node, comment, each contrib, etc.

I hope this solves your problem. It seems to have solved mine.

There's code in fb_canvas.module intended to do the things your code is doing. IMHO, it would be better to understand why that does not work in some cases, rather than everyone writing their own custom hooks.

We also have to make a kludgy path-making function. You can get the myapplabel part from the field fb.canvas, but I just hardcoded it. I create an FB app for each stage: dev, stage, prod - and each one uses a different app label for the URL. Here I'll just pretend there is one app and one label.

In Drupal for Facebook, each app has a 'label' and that's what it's for. You should keep the app label the same on each of your sites, even though the apikey and everything else will change. Code can grab the app details by label.

"There's code in fb_canvas.module intended to do the things your code is doing."

I had no idea, probably because it has not worked for me up to this point - so I assumed there was no feature for it, yet. Definitely, I want the fb_canvas features to work, and if I had more time, I would focus on that, but I had to build an app in a very limited timeframe, with no room for pushing back the launch date, and this has gotten it working for now.

I mistakenly thought at one point that the function fb_canvas_is_iframe() was returning false incorrectly, then realized that the site I was seeing in the iFrame (because our site theme IS our iFrame theme) was in fact the 'Site' and not the 'App' as it were, so as far as the App was concerned, it was not in fact in an iFrame. This would have been more obvious if we were using a standalone site theme.

I also noticed the issue with the function 'drupal_goto' as anytime it 'goes to' a relative path like 'node/ . $node->id it goes to http://www.mysite.com/node/$nid and not http://apps.facebook.com/myapplabel/node/$nid. I know your code is re-theming links, and that works for me in template files, but I don't know why that is happening in drupal_goto, which in fact rewrites the path with the url() function. I don't have any modules running that hit init_theme before DFF does.

And of course, if you simply set the form action or redirect to an 'apps.facebook' URL without the target=_top, you will load the FB chrome within an iFrame within FB chrome. That is the issue for me. If you want to force the whole window to change, it needs to be form target=_top, and because of that, apparently, I have to re-write all the destination strings and relative redirects to be full FB paths.

To the question of the app label: I'm talking about the part that is assigned from the FB end. 'canvas'. OK, I should not call it 'label'. I mean the 'canvas'. If that canvas name was the same across all three boxes, how could they run simultaneously as separate FB apps? Those have to be different.

Let me make it clear, though. Aside from this issue, and that I had to comment out the second window reload call in fbconnect.js (infinite reloads), Drupal for Facebook is amazing. I would have been sunk without it. DFF, and many other wonderful Drupal contrib modules, allowed our team to build a very nice Facebook app from 'scratch' to production in a month's time. You gave us an incredible head start, Dave. Thank you.

Okay, I looked at fb_canvas.module. It's not doing what I need it to do, to render the results I need.

A form in an iFrame, even if the action is an absolute URL, will not reload the entire window, and thus change the URL your browser's locator displays, unless form target=_top. Once you do that, though, you have to make your redirects absolute. I want the URLs in the FB app to always match the Drupal equivalent, just like they do when clicking links themed by fb_canvas, but on form submits as well.

I did originally make the form action absolute, and what I got was iFrame within FB chrome within iFrame within FB chrome. Instead, I leave the form action local (and I didn't mention but do use fb_canvas_form_action_via_facebook() within a conditional to guarantee that part) but make the redirect absolute, because really, it's where I end up that matters, not what transpires in between.

I also have a lot of destination links. Really the app we did contains a series of re-themed node forms exposed to the user, so it's really important they end up in the right place. Originally I re-themed the destination links to absolute URLs, but now I'm thinking I can just allow those to all be relative and convert them in form_alter.

Ultimately, I feel this is an iFrame/form issue, not an FB or DFF one. But fb_canvas could be patched to do the same things.

I'm glad its working for you. Again just my opinion, if you've commented out lines in fb_connect or anywhere else, you're in too much of a hurry. Your app has bugs in it, probably. And you'll have problems if you ever upgrade to a later release of modules/fb.

fb_canvas tries to fix some of these problems. In some cases with awkward code, like preg_replaces and changing destinations in hook_exit. Although I spend more time in FBML canvas apps rather than iframes, I have seen form submission work in the cases I've tested.

My hope is that in each version of Drupal, and each release of modules/fb, there will be less of this awkward code. There's already less in the .dev release than there is in beta 10. But I know that in D6 at least there is no way to get rid of it all. See fb_canvas_form_alter(), fb_canvas_process() and fb_canvas_exit() for details.

I agree. Believe me, I'd love to have that 12 hours back it took me to get my forms working. Just for the record, I only commented out one line from any of the code, which I think showed up in beta4 or 5, which is the reload conditional in fbconnect.js, the one that says if (fb.data) window.reload. It just reloads forever. But that's another issue I will definitely discuss later.

In too much of a hurry? Absolutely. The timeline for this project has been a real nightmare. I'd never even used Facebook before this. (Shhhhh.)

shannon's custom functions have got node add form submits working for me now also - I'm not on quite as tight a deadline as you, but it's a huge help to have some sort of working solution. Thanks :)

I am having the same issue in fb canvas app and would prefer a fix in the fb module than a custom one :)

Here is my app: (using the Amazon module)

Just click "Add to Cart"

and you will see this issue in action:

http://apps.facebook.com/shopping-mall/

I found a possible dupe of this one at
#740334: Breaks out of Facebook and takes me to Drupal site Iframe apps
mahen proposes a solution in that thread though

This one was a dupe as well
#794146: Redirection on form submit

If this problem is caused by the amazon module or some other third party module, I can't reproduce it. Someone has to figure out what the problem is. And, hopefully, in which module the problem lies.

Of course I'd like to fix all these things, but I personally cannot support or even test with all third party modules.

This issue has gotten long and mixed with things. But, the stuff I'd posted is still an issue and was not related to other modules. I've just given up on upgrading and am running on a manually patched version of the module. Ever since version 1.36 of the fb_canvas.module I haven't seen this work correctly.

I'm encountering this issue with the 6.x-2.0-rc2 release. I'm seeing it basically anywhere I have a form element - submitting the form take the user out of the canvas page and into our site, which is jarring for the user.

Here's the form element for the search block as it appears on our (dev) site:

<div class="content">
    <form action="/drupal_dev/"  accept-charset="UTF-8" method="post" id="search-block-form">
<div><div class="container-inline">
  <div class="form-item" id="edit-search-block-form-1-wrapper">
 <label for="edit-search-block-form-1">Search this site: </label>
 <input type="text" maxlength="128" name="search_block_form" id="edit-search-block-form-1" size="15" value="" title="Enter the terms you wish to search for." class="form-text" />
</div>
<input type="submit" name="op" id="edit-submit" value="Search"  class="form-submit" />
<input type="hidden" name="form_build_id" id="form-37025e3210df56b5089e558dbb0f8615" value="form-37025e3210df56b5089e558dbb0f8615"  />
<input type="hidden" name="form_token" id="edit-search-block-form-form-token" value="655e9da05118cb504f067e4c35e9ad4b"  />
<input type="hidden" name="form_id" id="edit-search-block-form" value="search_block_form"  />
</div>

</div></form>
  </div>

And how it appears in the FBML canvas page:

  <div class="content"><form action="http://flixfling.com/drupal_dev/"  accept_charset="UTF_8" method="post" id="search_block_form">
<div><div class="container_inline">
  <div class="form_item" id="edit_search_block_form_1_wrapper">
 <label for="edit_search_block_form_1">Search this site: </label>
 <input type="text" maxlength="128" name="search_block_form" id="edit_search_block_form_1" size="15" value="" title="Enter the terms you wish to search for." class="form_text" />
</div>
<input type="submit" name="op" id="edit_submit" value="Search"  class="form_submit" />
<input type="hidden" name="_fb_handling_form" id="edit__fb_handling_form" value="1"  />
<input type="hidden" name="form_build_id" id="form_8f73098b3d707f73676d016390106508" value="form_8f73098b3d707f73676d016390106508"  />
<input type="hidden" name="form_token" id="edit_search_block_form_form_token" value="656625d5ce9893daeb2e024bb921de1b"  />
<input type="hidden" name="form_id" id="edit_search_block_form" value="search_block_form"  />
</div>

</div></form>
</div>

In the FB canvas page an absolute URL is set as the form action field and seems to be the culprit. Is this happening because we're using a subdirectory (drupal_dev) for our development install?

I have installed the code from #1 as a custom module which has had no effect.

I'm doing some digging around on this issue and here are my findings to date:
I installed that dff_custom code as mentioned before. I added in a couple watchdog function calls to see what was happening with the form data. My dff_custom.module looks like this:

function dff_custom_form_alter(&$form, $form_state, $form_id) {


  if (fb_canvas_is_fbml()) {
    // Special canvas page form handling *only* when enctype is set.           
    if (!isset($form['#attributes']) || !isset($form['#attributes']['enctype'])) {
      // Prevent fb_canvas from changing the form's action 
      watchdog('dff_custom', 'Form before function: !data', array('!data' => '<pre>'. check_plain(print_r($form, TRUE)) .'</pre>'));                    
      fb_canvas_form_action_via_facebook($form);
      watchdog('dff_custom', 'Form after function: !data', array('!data' => '<pre>'. check_plain(print_r($form, TRUE)) .'</pre>'));
    }
  }
}

Loading up my base page in FB confirms the function is being called, which in turn is calling the fb_canvas_form_action_via_facebook() function. However in my $form array I'm not seeing any

[_fb_canvas_form_handler] => Array
        (
            [#action_fb] => /drupal_dev/
            [#action_local] => http://flixfling.com/drupal_dev/
        )

in the array, which is what the fb_canvas_form_action_via_facebook() function is looking for to modify the $form['#action'] field. So the function is called, but nothing is done to the $form array.

The [_fb_canvas_form_handler] array *is* added in as expected in fb_canvas_form_alter() function in fb_canvas.module at line 383 (DFF 2.0-rc2 version):

    if (!isset($form[FB_CANVAS_FORM_HANDLER_WRAP])) {
      // Use the form data structure to keep track of whether data is
      // posted directly to us, via absolute URL, or instead via
      // relative URL on apps.facebook.com/...
      $form[FB_CANVAS_FORM_HANDLER_WRAP] = array(
        '#action_fb' => $form['#action'],
        '#action_local' => _fb_canvas_make_form_action_local($form['#action']),
      );

      // This helper function allows third-party modules to control
      // where the post goes.  By default use local server.
      fb_canvas_form_action_via_facebook($form, FALSE);      
    }

And here it calls fb_canvas_form_action_via_facebook($form, FALSE) and since $use_facebook is set to false it sets the $form['#action'] to the $form[_fb_canvas_form_handler][#action_local] value, which sends the user to the site instead of the canvas page if I presume correctly.

Is the dff_custom_form_alter() function being called before the fb_canvas_form_alter() simply because of alphabetical order? If it was called after fb_canvas_form_alter() it would see the the $form[_fb_canvas_form_handler] array, be called with $use_facebook set to TRUE, and use the $form[_fb_canvas_form_handler][#action_fb] value. Or would it be better to add into the dff_custom_form_alter() function code to set up the $form[_fb_canvas_form_handler] array like so:

function dff_custom_form_alter(&$form, $form_state, $form_id) {


  if (fb_canvas_is_fbml()) {
    // Special canvas page form handling *only* when enctype is set.           
    if (!isset($form['#attributes']) || !isset($form['#attributes']['enctype'])) {
      if (!isset($form[FB_CANVAS_FORM_HANDLER_WRAP])) {
        // Use the form data structure to keep track of whether data is
        // posted directly to us, via absolute URL, or instead via
        // relative URL on apps.facebook.com/...
        $form[FB_CANVAS_FORM_HANDLER_WRAP] = array(
          '#action_fb' => $form['#action'],
          '#action_local' => _fb_canvas_make_form_action_local($form['#action']),
        );
      }
      // Prevent fb_canvas from changing the form's action                   
      fb_canvas_form_action_via_facebook($form);
    }
  }
}

Or am I just looking at the tip of the iceberg?

I tried out that code for my dff_custom module and I am getting the following error in the canvas page:
------
Errors while loading page from application
The URL http://flixfling.com/drupal_dev/search/node/rage caused too many redirections.

Please try again later. We appreciate your patience as the developers of FlixFling and Facebook resolve this issue. Thanks!
------

But it stayed in the canvas page!

This is for anyone who needs to make sure their iFrame form actions end up in FB chrome.

I'm still successfully using my customizations based on my post #56. There's a lot there I don't go into (forms from contrib modules, validation, comments, node forms specifics, etc), but the basic gist is this:

The only way to guarantee your iFrame form returns in FB chrome, is for the form's target to be '_top' and the form's destinations (for validation AND submission) to lead with 'http://apps.facebook.com/yourappname/%'

It's the same principle that is applied to all themed links in the app (they all get target='_top' added on by DFF).

There are two ways to have an FB app running in an iFrame:

1. The Facebook location.url stays at http://apps.facebook.com/yourappname and the iFrame changes views of the Drupal site in it - so even though the Drupal site shows node/1234, the browser locator doesn't show that. If you were to hit refresh on the browser, the app would reload to its homepage.

OR

2. Every change to the iFrame's view forces the location.url of the browser to change and the FB chrome reloads with a URL that specifically references the path of the content in Drupal (http://apps.facebook.com/yourappname/node/1234) - you pass to FB the path of your Drupal content, and it passes the path to the iFrame and therefore, to your Drupal site.

Since DFF themes the links you create from l() or url(), every time you click a link within your app, the FB chrome should reload and the URL locator shows the Drupal path, as in #2. So, DFF favors the second method of running app-in-iFrame.

But for forms within iFrames to do the same thing as links, you have to control the form's target attribute, then control the form's destinations, which I found to be a nightmare in Drupal, since different forms use different ways of controlling destinations. To get my app working with Organic Groups and DFF, I had to hack OG modules extensively, because they use drupal_goto() in their menu item callbacks for certain situations (approve confirm, approve deny, join confirm, etc) , instead of setting form destinations using form API redirect methods, which in Drupal can still be in varying places, but can at least be overridden.

Unfortunately, server-side form validation gets killed doing it this way, because if your form fails validation, Drupal rebuilds the form with all the values the user entered and returns with the Drupal site URL. If the form weren't set to target=_top, the app would stay within the frame but with the site theme, not the iFrame theme. Because we set the target=_top, instead you will get a non-FB-chrome page, locator will have http://yoursitename.com/ instead of http://apps.facebook.com and you will see your failed-validation form with values. For that, I had to force validation to set a redirect so that the form goes to form without previous values set. So, right now, in my app, if you submit a form that fails validation, you will get the form back blank but with the validation error in place. Still have to work that out, but the client has to agree to let me change it.

Ultimately, I feel that the issue is really how HTML forms work in iFrames, and that this is not an issue of DFF specifically. To get around the problems created by using forms within iFrames, the only solution I have found is the one I'm using. This could be patched into DFF, but it should also be optional (tied to a system variable setting) and it would only be good for node and comment forms, given contrib forms don't have to follow Form API to the letter.

I hope this helps and my ramblings make sense to someone who just needs to get it working. Thanks.

ccshannon,

I am writing to say that your method seems to be working for me as well although my issue was slightly different: #820770: iFrame Theme not sticking on form submissions. I have a further problem now as that issue describes, but if anyone else is having problem similar to mine your solution can work in that case as well. The forms issue has been driving me absolutely batty.

I was having a similar problem redirecting by hand until I found this gem in the FB modules:

fb_canvas_goto('<relative url>');

This worked for in canvas or out as it detects if it is in canvas. If not it uses drupal_goto.

hi Mike. which line of which version of fivestar did you insert this? thanks.

Since there has not been much action on this.

I wanted to say I got the same problem as giorgio79 on #64, except I am just using ubercart, and I am on 3.x

All I am trying to do is get a "add to cart" button/checkout forms for ubercart to work without it redirecting outside of the canvas page. Am I wrong to say this issue is still not solved, unless you hack it in a very serious way like #56? I would really rather not write custom validation/hack modules to get this to work.

Oh, and I am pretty sure it's related to the ubercart SSL module, which should basically be assumed when were dealing with ubercart.

Thanks.

There has not been much action on this because (a) it's a 2.x issue, and development is now focused on 3.x, and (b) the fix may need to be in third-party modules (or maybe new rules need to be added to fb_canvas_process(), I'm not sure).

FYI, I am on 3.x just so you know, still a problem. I did not create a new issue because it's still the same problem as 2.x

I would think being able to make forms work would be a key make or break feature to your module? FBML will be deprecated soon, otherwise I would just go with that.

Thanks for your help.

This is a 2.x issue. If there's a 3.x problem, it needs its own issue. If you can find a form that doesn't work on http://apps.facebook.com/drupalforfacebook please let me know as that would make the issue easy to reproduce. Until then I consider it a make or break feature that works.

Hey Dave,

Just wanted to let you know the offending module in my case is the "ubercart ssl" module most likely because of a hard coded redirect or something. Well, I just went with secure pages and it all works! Thanks a ton for your fast reply's.

Great. Thanks for letting us know.

I'm marking this wont fix because the issue is 2.x.

My offending module? It was Global Redirect. Turned that off and all was swell.

@capellic: This still exists in 6.3? Global redirect compatibility would be great, since it solves so many SEO issues.

This thread is too old to re-open.

I suspect any patch that provides "global redirect compatibility" will be a patch to global redirect module. But feel free to provide a patch to modules/fb if I am wrong.