Right now if you use this with fbconnect it will add facebook's fb-root settings twice.

CommentFileSizeAuthor
#1 dont-include-settings_1293826_1.patch1.18 KBacouch
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

acouch’s picture

Attached is a patch that adds an option in the admin to not include fb-root settings. I've included a patch to fb_connect as well, but I think it should be up to the user which version they would prefer not to include.

acouch’s picture

Status: Active » Needs review
ferdi’s picture

I really like to solve the conflict with fbconnect. and we have tried a couple of options in the past without success. This is probably the way to go but the way you have it now, my hook_fb_social_event_subscribe get lost !

thanks!

acouch’s picture

I could put that 'return' below the module_invoke but I don't think that would really help you because even if your hook_ was getting called it wouldn't affect the init code.

The real solution would be to have a single "facebook config" module that all of the others connected to. Would you support that? I've been working with the maintainers of fbconnect so could see if they would support that at least for the 7.x versions.

Alternatively we could try and add a similar hook to fbconnect (there is already a ticket there like this one #1243534: Facebook Connect with fb_social) so that if you turn off the settings on this module you could plugin to a similar hook on that module.

What is the use case for that hook_ ? To add these event handlers? http://developers.facebook.com/docs/reference/javascript/

ferdi’s picture

As I have said it before (http://drupal.org/node/852582#comment-3267358), creating a common dependency module ("facebook api" / "facebook config") would help. A while back I was contacted by someone who started to work on this idea (http://drupal.org/sandbox/ausrick/1129900) but I havent looked at it.

Something similar to what you have in your patch should work too though. fbconnect could call the hook too. Which basically adds handlers to fb javascript events (http://developers.facebook.com/docs/reference/javascript/FB.Event.subscr...)

codycraven’s picture

ferdi,

I've just created a sandbox project to address this exact issue - http://drupal.org/sandbox/codycraven/1324022. If I supply a patch for fb_social would you be interested in reviewing it with a dependency on the sandbox module?

acouch’s picture

Great work on starting a sandbox. I think it would be best to take over this module and use its namespace instead of creating a full new project: http://drupal.org/project/facebook_api

I put in a ticket to do so but got no response: http://drupal.org/node/1308740

The next step would be to request maintainersship if you would like to do so: http://drupal.org/node/251466

ferdi’s picture

codycraven,

Can we make it so the existing modules integrate with yours but not necessarily depend on it. Your module should solve the modules incompatibility issue, but there are many people that use just one of these modules (including myself).

Thanks for working on this !

Ferdi

codycraven’s picture

ferdi,

It certainly does to not need to be a dependency. The only caveat is that your module will be reproducing much of the code which would require you to test against your internal code and the external for all releases (not to mention duplicate administration pages for site admins such as App ID and using a lot of if module_exists() calls).

Just as a note, I started work on a patch yesterday and was able to add support with adding two lines of code and removing a lot of code from fb_social that is redundant with the sandbox module as a dependency. Right now I'm just trying to feel out how open you are to the module. If you'd like me to submit two patches (one as a dependency, the other adding support if it exists) then I'm certainly open to doing that so that you can review the differences.

acouch,

It would be a good idea to take over the Facebook API project name, however my concern is that there may be some confusion with the module being "Facebook API" (trademark infringement) and I'd really hate to make any modules depending on it to change their dependencies on an upgrade, even worse causing any site maintainers to remove and install a new module, if Facebook forced us to rename the module.

SocialNicheGuru’s picture

the first patch in #1 no longer works.

I would love to find a way to use drupal for facebook and the fb_social module. currently, I don't see how.

DamienMcKenna’s picture

Issue summary: View changes
Status: Needs review » Closed (duplicate)

There are two other issues that attempt to resolve the problem in other ways: #852582: Integrate with another fb* modules and #1293826: Add ability to not include fb-root settings for compatibility with other Facebook modules. I'm going to suggest combining efforts in #852582.