Allow mapping of FB profile url to Link field

scrap2000,

You can actually do this on your own using FBOauth's API. Checkout related tutorial here:
http://grasmash.com/article/connecting-facebook-drupal-easy-way

Basically, you can create hook in your own custom module to permit mapping to a link field.

I agree with Scrap2000 that this functionality should be available out of the box from the fboauth module. I'll be sending over a patch shortly.

OK, here's a patch, I added the 'link-field' as a valid field type for the Website and Facebook profile link fields.

I patched it against the 7.x-1.6 release as the master is out of date.

There's a bug in this patch where the data doesn't get loaded. I'll submit a new patch shortly.

Ok, I've added in the fixes to make this patch work. I had to add in code to actually deal with link fields in the /includes/fboauth.field.inc file.
As a part of this patch, I've fixed numerous issues that the coder module found with /includes/fboath.fboauth.inc and /includes/fboauth.field.inc files. I did this because I've got another patch I recently submitted that was rejected because it didn't meet coder standards.

I've got two other patches I'm working on--One that imports city and state information for the US and Canada, and one that allows this module to play nice with the multiple_emails module. Those two patches, if you want to use them, should be applied first, before this patch, as this patch changes a lot due to the coder fixes. I'll post links to them here once I submit them.

Facebook URLs can now be directly mapped and copied into Drupal Link fields, as can the Blog/Website field.

This patch that also incorporates fixes for:

• Play nice with Multiple Email module
• Import City and State Location data from Facebook into Drupal Location Field for US and CA

Adding in support for Multiple Email involved rewriting the login logic at connection time, but all of the same functionality is maintained. The code in includes/fboauth.fboauth.inc and in includes/fboauth.fields.inc has been cleaned up based on recommendations from Coder.

Thanks for the patch @DarrellDuane! I'd be happy to make you co-maintainer for the project! A few things about this patch in particular:

-    drupal_set_message(t('Invalid request type "@type" for Facebook graphy query. Must be either @get, @post, or @delete.', array('@type' => $method, '@get' => 'GET', '@post' => 'POST', '@delete' => 'DELETE')), 'error');
+    drupal_set_message(t('Invalid request type "@type" for 
+      Facebook graphy query. Must be either @get, @post, or @delete.',
+      array(
+        '@type'   => $method,
+        '@get'    => 'GET',
+        '@post'   => 'POST',
+        '@delete' => 'DELETE')), 'error');

It's great that we're formatting these lines so they fit easier in 80 characters, but if we're just doing formatting, we should match the Drupal coding standards and close parens so their on the matching indentation. Additionally you should *never* put a new line inside of a t() or watchdog() call, because that means when the text is translated, the new line itself has to be translated as well. Changing the location of the new line (to alter the line wrapping) would cause existing translations to break.

Although I can't find explicit evidence in the documented coding standards, I'm fairly sure if you wrapped the line, matching up opening and closing parens so they are on the same vertical link would look like this:

+    drupal_set_message(t('Invalid request type "@type" for Facebook graphy query. Must be either @get, @post, or @delete.', array(
+      '@type'   => $method,
+      '@get'    => 'GET',
+      '@post'   => 'POST',
+      '@delete' => 'DELETE')
+    ), 'error');

But by far the most common approach in Drupal core is to just put it all on one line, since translated strings tend to exceed the 80 character bar anyway and you can't break it up even if you wanted to.

Overall though, formatting doesn't bother me too much even if it varies slightly from core, but let's not break our translated strings. :)

I've given you commit access to the project, welcome aboard!

One more thing about translated strings:

-        '#title' => t($instance['label']),
+        '#title' => t(check_plain($instance['label'])),

The check_plain() should go around the outside, not the inside of t(). Otherwise translators are going to need to translate "&" instead of translating "&" (and other unencoded characters).

Thanks for the tips, I'll fix this before committing!