Extension talk:Facebook

Public FAQ for Extension:Facebook

When commenting, please include the versions of all the software you are having problems with (especially your version of the Facebook extension)!

Facebook Connect Started to Work, But Now Fails
After installing, I was able to get the Facebook Connect dialog and clicked to link my accounts, then it failed. Now, I see this error every time.

Warning: Invalid argument supplied for foreach in /extensions/FBConnect/FBConnectDB.php on line 65

Fatal error: Call to a member function free on a non-object in /extensions/FBConnect/FBConnectDB.php on line 68


 * ^ When commenting, please include the version of FBConnect that you are currently using.


 * Did you install the user_fbconnect table in your database by running maintenance/update.php? -Gbruin 07:34, 6 October 2010 (UTC)

Yes, I ran update.php and it created table "wiki_user_fbconnect"

Update: I reinstalled the extension from scratch. I still had a case where it couldn't find the table, but I went into my database and renamed the table and now it works! The only problem now is that the initial time the Facebook Connect login window comes up, it takes a really long time to load. I thought it had failed at first, but I waited and the dialog finally loaded.

Facebook Connect Login Button Not Appearing
Hello, I'm using the Facebook Connect Plugin for MediaWiki. However, the FB login button is not appearing below, "Click this button to login to this site via facebook". See here – Thank you

- dawsonking 18:49, 24 May 2010 (UTC)
 * I've been collaborating on this extension with a developer from Wikia, and for a week after he committed a fix for their clustered databases I had this problem as well. I don't know if the commit caused it or the problem was on Facebook's end (likely the latter), however it got me to re-write the extension using Facebook's new PHP SDK. The Facebook-login issue is now fixed. Make sure you re-configure using the updated config.sample.php. If the database issue persists, please email me.


 * The current revision is 204. Please make sure you're up to date when posting bugs! You can follow the automatic twitter robot for this extension here.


 * Thanks,  Gbruin 18:42, 24 May 2010 (UTC)

Hi. I'm also experiencing this problem, this site - am using 204 and what I assume is the latest config (in 204 folder). Any suggestions? Thanks -Niall
 * Hi, when the Facebook login button doesn't show up, it is an issue with the Javascript library. It is not initializing correctly. This could happen if config.php isn't configured correctly, but also if your application settings are not correct within the Facebook developer app. Verify these settings, especially the ones concerning the base domain for cookies and the callback url. If you're still having problems, I'll rack my brain to see if I can think of anything else. -Gbruin 21:54, 10 September 2010 (UTC)

Hey. Thanks for the feedback. Have double-checked everything and seems to be configured correctly. The callback url is your domain URL - correct? Niall


 * As a side note, in the past four months, Wikia has made 340 changes, most of which I've cherry-picked back into SourceForge. I have the new version running on my personal wiki, and when I have a few remaining bugs hammered out, I'll push the new version to the MediaWiki repo. Gbruin


 * Just to follow up on this comment thread, a new version of the extension has been pushed to SourceForge. You can find a download link from the extension page. If you find any problems, please let me know and I'll do my best to fix them as time allows! --Gbruin 06:51, 4 January 2011 (UTC)

Base domain not valid domain
Hi, I just installed this and everything seems to work, however when I try and log in with my facebook account I get an error saying " please set your Connect URL in the application settings editor. " I tried to type our home URL into the field (in a variety of ways I.E. with http://, without, with a / at the end, and without..etc) but I keep getting an error that says "base domain is not a valid domain". 13:06, 23 April 2010 (UTC)
 * This isn't the best place to post this, you should hit up Facebook for support on their end. Regardless, do you the mean applications settings editor at http://www.facebook.com/developers/editapp.php? Make sure the "Base Domain" field is correct. Here is how my settings look:
 * Connect URL: http://www.trianglebruins.com/
 * Base Domain: trianglebruins.com
 * Edit: I just came across this: http://github.com/facebook/php-sdk/commit/078887046dc15aa1d1149e1e2a52de6b0694c646. If it is a problem with the PHP SDK, then it'll need to be updated to the most recent version. Keep an eye on this extension's SourceForge updates (mirrored here). Gbruin 19:32, 23 April 2010 (UTC)

Thanks a lot we got it working.

I have one other question, when we click "log out of facebook" it doesn't do anything. Our developer said the code is simply missing. Is this suppose to work?11:56, 24 April 2010 (UTC)
 * Because MediaWiki's PersonalUrls hook doesn't provide an onclick attribute for the links, this code is attached to the link when the DOM is rendered. This logout code can be found in fbconnect.js and looks something like this:


 * Hope this helps in tracking down your error! Gbruin 19:40, 25 April 2010 (UTC)

Thanks,

I also found an error that when we log in and a user goes to Special:preferences the preferences are not available - we get and error message Fatal error: Access to undeclared static property: FBConnect::$api in /home/nicewiki/public_html/en/extensions/FBConnect/FBConnectHooks.php on line 338

I appreciate the help, but I think we are going to remove this extension for now. :)67.169.112.215 08:38, 29 April 2010 (UTC)
 * Removing the extension is probably a safer bet than running an old version. That error was fixed and committed to the svn in revision 156. If you're still looking to try out this extension, I recommend following its development. Gbruin 22:53, 30 April 2010 (UTC)

Path and cross-domain issues...
...are now a thing of the past! For details, see Extension:FBConnect.

Essentially, I migrated over to the new Facebook Connect JavaScript SDK (announced here) and the callback URL no longer needs to be specified ($fbCallbackUrl has been completely removed). If you are still receiving similar issues, they need to be reported to the GitHub tracker.

- Gbruin 07:53, 14 April 2010 (UTC)

MediaWiki 1.12
Hi everybody,

Is there a way to use this extension with v1.12 ? I really like this plugin and it would be great to be able to use it on previous versions of MediaWiki =)

--Marineam 16:37, 20 April 2009 (UTC)


 * Unfortunately, right now there is not. I started developing this extension on MW 1.14alpha and recently resumed development for 1.16.0beta1 wikis. However, I have included a significant amount of backwards compatibility code and research in the source if anyone wants to pick up the torch for legacy users. If you have PHP programming experience, I encourage you to give this a try =) Gbruin 22:55, 28 March 2010 (UTC)

Conflicts with other extensions
I noticed a conflict with the FCKeditor extension. Apparently the FCKeditor also uses the UserLoadFromSession hook. However, since the FBConnect extension registers with the hooks only after all the setup for the other extensions has been complete, the other extensions may have already loaded the user object by the time this extension registers its UserLoadFromSession handler. This results in the FBConnectHooks::UserLoadFromSession method never being run and the FB user from not getting authenticated.

I'm not sure if this is the best work-around, but it seems to do the trick. One potential risk is that the other extensions may initially load a different user as the FB user would not have been set up yet. If possible, this extension should load the user earlier in the setup process.

Here's my hack, in FBConnect.php: public static function init { global $wgXhtmlNamespaces, $wgAuth, $wgHooks;

...		// Install all public static functions in class FBConnectHooks as MediaWiki hooks $hooks = self::enumMethods('FBConnectHooks'); foreach( $hooks as $hookName ) { $wgHooks[$hookName][] = "FBConnectHooks::$hookName"; }		// HACK // Other extensions may have already loaded the user. Start the process over. global $wgUser; if ($wgUser->mDataLoaded) { $wgUser->clearInstanceCache ('session'); }		// END HACK // ParserFirstCallInit was introduced in modern (1.12+) MW versions so as to		// avoid unstubbing $wgParser on setHook too early, as per r35980 if (!defined( 'MW_SUPPORTS_PARSERFIRSTCALLINIT' )) { Mreall 23:08, 30 June 2009 (UTC)

Mreall, it works very well. I've included all your hacks, Thanks a lot for your work. profetes --86.171.130.44 22:40, 9 July 2009 (UTC)

LDAP conflicts
I have the LDAP extension setup to be used alongside the local accounts. When i enable FBconnect the domain drop down disappears. Is this easy to address?


 * In short, no. I re-wrote the extension, and believe the new version to be more pluggable in nature. Keep an eye on the head of the SVN and let me know if it looks like this becoming more possible. Gbruin 23:19, 28 March 2010 (UTC)

Using this connection in an wikifarm setup
Hi there,

does anyone tried to use this extension in an wikifarm setup? I'd like to use it and would share the extension across all my wikis. And another question: How is the progress on the missing features from the Extensionpage? --Marcus Stöhr 13:21, 26 July 2009 (UTC)

Does Mouseover Tooltips collide with Navigation Popups?
Anyone have an issue with Gadget:Navigation Popups being incompatible with this FBConnect feature? --76.216.200.201 03:26, 14 March 2010 (UTC)


 * These tooltips have been removed in the current version due to an architectural change in my extension. Moreover, if there is ever a need to re-implement them, it will be done using jQuery and hopefully won't conflict with your Gadget:Navigation Popus anymore. Gbruin 22:59, 28 March 2010 (UTC)

undefined method OutputPage::addInlineStyle
After fresh install on MediaWiki 1.15.2 I immediately receive "Call to undefined method OutputPage::addInlineStyle in FBConnectHooks.php on line 114". Any ideas? SeanFromIT 14:19, 1 April 2010 (UTC)
 * This function was added in r53282 on 7/14/09. If you can tell me the highest version missing this function (probably 1.15.2) then I'll write the workaround code. Gbruin 00:58, 4 April 2010 (UTC)
 * I fixed this in SVN, but I don't have a 1.15.2 wiki so I'm unable to test. Do you still receive this problem? Gbruin 01:35, 4 April 2010 (UTC)
 * In 1.15.2 it still errors because the Html class isn't in v1.15 either ;) -SColombo 02:01, 8 April 2010 (UTC)
 * *facepalm* haha should work now Gbruin 18:23, 8 April 2010 (UTC)

Signatures
Would it be possible in the next version to have the real name (or nick name) be used for the signatures? Because, right now, when you are facebook connected and use the ~ to place a signature, you get the 9 facebook id digits. This is not really meaningful. Fredd-E 10:50, 21 May 2009 (UTC)

Problems setting up: does not create new user
I am not sure what I am doing wrong. It all seems to work but when I log into facebook through the pop up window it doesnt create a new user and nothing changes. Then when I go to the Special Pages: Connect there is the option of logging out from facebook connect but I am still not logged into the mediawiki. --86.24.193.46 12:16, 26 June 2009 (UTC)

Problems with using an account prefix
I found a couple bugs when using an account prefix. My accounts weren't being created or when they were I wasn't being automatically signed in to them. The problem lies in a couple methods that should call FBConnectAPI::idFromName on the the ID before passing it to Facebook:

In FBConnectAPI.php, I commented out the original code and added in the fix: public function getRealName( $user ) { // HACK //$name = $this->getFields( $user->getName, array( 'name' )); $name = $this->getFields( $this->idFromName($user->getName), array( 'name' )); return $name[0]['name']; }	public function isConnected { global $wgUser; // Hack //return $wgUser->isLoggedIn && $this->isIdValid( $wgUser->getName ); return $wgUser->isLoggedIn && $this->isIdValid( $this->idFromName($wgUser->getName) ); } Mreall 13:38, 30 June 2009 (UTC)

Usernames
I was wondering how it could be implemented a solution to change the usernames of the facebooks users from numbers to names. Also, when I log in as administrator not-facebook user, I cannot see the names or numbers of facebook users on the user list. profetes --86.171.94.53 10:34, 24 July 2009 (UTC)
 * Seconded on this. Especially since you auth to Facebook (user-facing) with your e-mail - makes sense to store the e-mail in the profile (not currently done), auth with that, then maybe let the user set/pick a "user-friendly" Wiki name? e.g. Or maybe auto-set it to the "user" part of their e-mail (before "@"), and then just run it through the "check duplicate usernames" which is already implemented? --User:Dforester 8-Aug-2009


 * Both great ideas. Unfortunately, until recently Facebook wouldn't give out your email address, only a proxied email that looked like apps+2247576871.6549491.a8f9c147347345bd2d9e9aa57dd93ade@proxymail.facebook.com. Also unfortunate is that letting the user pick a "user-friendly" Wiki name is really the way to go, but would call for a complete re-write of the entire extension from the ground up. Now for the fortunate part: that's what I used by spring break for. The new architecture suggests a few usernames, but ultimately lets the Facebook Connect user choose their own the first time they connect. This should solve the username problems you two are having. Gbruin 23:17, 28 March 2010 (UTC)

Problem with 64bit Facebook UID numbers for server with only 32bit PHP
New Facebook accounts now have a much longer UID (64bit). With those accounts this extension does not work (new users are not created). This does not happens if your PHP handle 64bit (to check it see ). A workaround is to use float ... see, as I did, so:

(btw, I've before used the above patch by Mgrell: thank you Mgrell!)

A quick (and dirty) solution is: in config.php set

$fbUserName = '';

and in FBConnectAPI.php:

public function isIdValid( $id ) { ...               //HACK //return 0 < $id && $id < hexdec( 'FFFFFFFFFFFFFFFF' ); return 1 == 1; // I guess you can just have "return true", or "return 0 < $id" }

and, once again in FBConnectAPI.php

public function idFromName( $username ) { ...                       // HACK // return intval( $username ); return sprintf ( "%.0f", floatval( $username )); ...

--Oriettaxx 12:00, 13 October 2009 (UTC)

FB registered users can only preview but not save
I've installed this extension, it works (the xd_receiver only in IE), but when a user is logged on Facebook and tries to save a page, it always previews it. Wiki registered users work perfectly, only problem is with FBConnected users.

--Fulgen 10:54, 7 January 2010 (UTC)

Tries to create duplicate accounts
1User name conflict found: "XXXXXXXXXXX". Rename offending user or set $fbUserName = true.

Cannot enable it. I also deleted old account, merging it with another one. But after connecting once it doesn't understand the account already exists and tries to crete it again.

--Mrrux 21:43, 7 January 2010 (UTC)


 * Tracking down bugs like these would would have been a pain so I used my spring break to completely re-write the extension from the ground up. Account names are now chosen by the user and I removed the configuration parameter completely. This should eliminate the bug... if not, I would like to hear about it. Thanks! Gbruin 23:05, 28 March 2010 (UTC)

Don't FB authenticate if you're already signed in
When you are already signed in to the wiki under a local wiki account and don't want the system to automatically sign you out of the local account and into your FB account, add the following code:

In FBConnectHooks.php, UserLoadFromSession method (just the HACK section): static function UserLoadFromSession( $user, &$result ) { global $wgAuth, $wgUser; // HACK: don't do anything if the user is already signed in from the session. global $wgCookiePrefix; if ($user->mFrom == 'session' && isset($_COOKIE["{$wgCookiePrefix}UserID"])) { return true; }		// END HACK // Check to see if we have a connection with Facebook if ( !FBConnect::$api->user ) {

and in fbconnect.js addOnloadHook(facebook_onload_addFBConnectButtons); addOnloadHook(facebook_add_user_tooltips); addOnloadHook(facebook_init);

// HACK if (!wgUserName) { addOnloadHook(facebook_onload); } //END HACK Mreall 13:41, 30 June 2009 (UTC)

Special:UserLogin Vulnerability
First off, thanks for starting this extension.

I am not sure if this is isolated to my wiki. But once $fbAllowOldAccounts = true; in config.php, on Special:UserLogin if you enter any registered member's user name without entering a password and press login, this automatically logs you into the users account without any validation.

Could some one try this on there installation and let me know if its just my setup or its a bug withing this extension.

I'm running MediaWiki 	1.14.0

--69.41.102.224 19:42, 9 May 2009 (UTC)
 * Thanks for mentioning this. I'm running the same MediaWiki version 1.14.0 and you're absolutely right about the bug. This is a huge security issue. I've disabled FBConnect on my wiki for now until the developer gets active again. Fredd-E 10:43, 21 May 2009 (UTC)

--96.20.202.45 01:37, 2 June 2009 (UTC)
 * The script is producing the same security issue for me.


 * The problem is that "FBConnect::$api->idFromName( $username )" returns "0" for registered wiki member's and "FBConnect::$api->user" returns "null" when using local (wiki) authentication. First we should verify that we have a FB ID (see sample below):

FBConnectAuthPlugin.php: 56: public function authenticate( $username, $password = '' ) { 57:   $id = FBConnect::$api->idFromName( $username ); 58:   $user = FBConnect::$api->user; 59:   return $id > 0 && $id == $user; 60: } Mreall 22:30, 24 June 2009 (UTC)

SSO Not Working
Using Mediawiki 1.14, the extension loads fine, and on the Special:Connect page, I can log in and out of Facebook. However, upon clicking "Connect with Facebook" on, say, the Main Page. The pop-up appears, and I log in to Facebook. The Main Page is then reloaded, but I am not logged in, and no account was created. The "Log in" and "Connect With Facebook" links are still present. Additionally, there are no PHP errors, so I am at a loss to troubleshoot this extension. Any tips on troubleshooting this would be greatly appreciated. --John Thomson 03:06, 13 June 2009 (UTC)


 * Just as an update, Mreall's solution regarding the FCK conflict resolved the SSO issue for me. THANKS! --John Thomson 23:06, 22 August 2009 (UTC)

- Something similar happens to me. If I try to "facebook connect" in the main page as a logged off user, it just reloads the main page. --86.24.193.46 11:35, 21 June 2009 (UTC)

- It happened to me me also, and I cannot find the problem. I tried the FCK conflict, but it´s not working. Could you please help me? --fladei 16:10, 08 October 2010 (UTC)


 * Hi fladei (et al.), MediaWiki 1.14 is not supported by this extension. When writing it I scoured mediawiki.org for all the relevant 1.14->1.15 changes and coded them in, so a lot of backwards-compatibility code is present. However, I never tested with 1.14 so some small additional changes may still be needed. If that's the case, please submit a patch and I'll include your additions (also I can give you dev rights so you could add them yourself Smiley.svg).


 * If you are using a more recent version of MediaWiki, please make sure that you are also using the newest version of FBConnect (>= 2.2.1, revision > 300). These version use cache-breaking to load the main page with a randomly generated parameter "cb", forcing MediaWiki to render the page with the correct account credentials. Hope this helps! -Gbruin 15:24, 9 October 2010 (UTC)

Loss of Session Data?
My fb-users can not save any edits. Logging out then in yields no improvements. From what I can tell. FBConnect is otherwise working as expected. Anyone else seen this?

'''Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in. '''

I have disabled Captcha and FCK to no avail...non-FB users have no issues.

TIA --John Thomson 23:05, 22 August 2009 (UTC)


 * Problem seems to have solved itself...must have been a conflict or other config issue. I just turned it on for the first time since this post, and now it works.   --John Thomson 02:22, 4 March 2010 (UTC)

Wrong, the problem is back, but now I can reproduce it:


 * 1) If enabled, disable the extension.
 * 2) Visit any page of the wiki, confirm you are not logged in as a FBConnect user
 * 3) Enable the extension
 * 4) Visit any page, verify you are logged in as your FBConnect user
 * 5) Edit any page, this ought to work.
 * 6) "Facebook Logout" of the wiki
 * 7) Log in through Facebook again.
 * 8) Edit any page, and you will get the Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in.  error
 * 9) Argh.

--John Thomson 03:13, 4 March 2010 (UTC)

Shows the Special:UserLogout page upon connecting with FBConnect
For some reason, when I login to my wiki via FBConnect, I am brought to the logout page. It still works - if I navigate away from the page, I'll find myself logged in under my Facebook account. This is hardly ideal, though - any thoughts on what might be wrong? I've tried applying some of mreall's hacks, but they don't seem to have addressed this issue. --218.186.8.236 17:38, 24 January 2010 (UTC)


 * Over my spring break I managed to completely re-write this extension and redo the underlying architecture. Hopefully this is no longer the case, but if so I would like to hear about it. Thanks! Gbruin 23:01, 28 March 2010 (UTC)

Preferences for logged in account
it gives: Fatal error: Call to undefined method SpecialPreferencesExtension::execute in ....../wiki/extensions/FBConnect/PreferencesExtension.php on line 267 (mediawiki-1.16.0beta2)


 * PreferencesExtension.php has only been tested in 1.15 so far. Sorry for the inconvenience. Keep an eye on the development to see when this is fixed for 1.16! (On a side note, I think this was added in r165. For now I would try downloading the tarbal of revision 164 and then working backwards from there). -Gbruin 08:19, 4 May 2010 (UTC)
 * I was able to fix it by commenting out these lines in PreferencesExtension.php:

And also:

Tisane 11:01, 16 May 2010 (UTC)

Unable to call FBConnect::init
I followed the exact installs as described here.

When accessing my Wiki page, I get:

Warning: call_user_func(FBConnect::init) [function.call-user-func]: Unable to call FBConnect::init in /var/www/vhosts/infoaffe.de/httpdocs/w/includes/Setup.php on line 310

I use the latest MW version

MediaWiki	1.15.3 PHP	5.1.2 (apache2handler) MySQL	5.0.22-Debian_0ubuntu6.06.12

Any ideas?


 * You are not alone, using Plesk 8.2 I ran into the same problem. I took the same mediawiki install, moved it over to a Hostgator account with no problems. I think it has something to do with restrictions on remote file access, that particular version of php, or running php as cgi instead of apache2handler


 * My guess is the particular version of PHP. The true installation of this extension happens in FBConnect.php: $wgExtensionFunctions[] = 'FBConnect::init'; I haven't run across any other extensions that place the init function inside a class (i.e. use :: in the function name). To track down this error, we should try different versions of PHP on the same server and see if that makes a difference. -Gbruin 01:25, 6 June 2010 (UTC)

I have come across what I believe to be a solution, older versions of php require alternate code to call methods:

http://www.mediawiki.org/wiki/Manual:$wgExtensionFunctions

$wgExtensionFunctions[] = "functionName"; $wgExtensionFunctions[] = array( $classInstance, 'functionName' ); $wgExtensionFunctions[] = array( 'ClassName', 'staticFunctionName' ); $wgExtensionFunctions[] = 'ClassName::staticFunctionName'; // NOT recommended, works only for newer PHP versions

so, using the 3rd option should work for this extension on older php installs.

Blank screen
I tried the FBConnect 2.2.1r307 on Mediawiki 1.16.0b2: it gives a blank screen. After debugging the FBConnect.php, I found that the request to php-sdk/facebook.php was the problem (stopping the loading of the page). In fact I tried direct call (not $dir which gives /home/www/site...) replacing $dir by the path in web (http://site/wiki/extension...) and replace require_once by include_once.

Next Ineeded to replace FBConnect::init by FBConnect:init

However, it's still don't work, even login link isn't replaced, netheir the userlogin.php... And debugging the call of Facebook or FBConnectAPI from the defaultsetting.php page or the monobook.php (near "start of content) doesn't work. Moreover debuging the class of FBConnectAPI (which was running correctly in July) show that nothing work.

Blank screen here too
As soon as I add "require_once("$IP/extensions/FBConnect/FBConnect.php");" the wiki goes blank. Does anyone know if this extension works anymore, I haven't tried it before. 16:13, 20 November 2010 (UTC)


 * Do these problems still occur on version 3.0 of the facebook extension? If so, and if it isn't too much trouble to upgrade to MediaWiki 1.16.1, do the problems disappear on the newest MediaWiki version? If you can answer these questions, then maybe I can help find a fix. Best regards, Gbruin 08:17, 4 January 2011 (UTC)

Can't get any FBML to work
I am using nearly freespeech as my webhosting provider and am on the settings: Apache 2.2, PHP 5.3 Fast, CGI (Beta) I have installed mediawiki 1.16.0 and the Version 2.1.0 of fbconnect, registered with facebook connect and gave them my url and set $wgFbAppId and $wgFbSecret in my local settings file. I did install the .sql file in phpmyadmin. I get the "login with facebook connect" option at the top and that seems to work ok.

If I enter something  into the wiki nothing comes up at all. If I view the source there is still nothing there.

If I remove the "require_once" entry for fbconnect it does show the code.

Any ideas on what I may be doing wrong? My wiki is http://www.sexmeup.org/index.php/Main_Page (completely safe for work as its a new install)

There is also some confusion on if I should be using the facebook App ID or the API key. I am also getting the following warning:

Warning: Parameter 3 to __lambda_func expected to be a reference, value given in /f5/sexmeup/public/includes/parser/Parser.php on line 3333

I'm now trying with Version 2.2.1, September 18, 2010 from SVN. Thank you

Caston1981 06:14, 1 December 2010 (UTC)

I messed around with a few different PHP and apache versions on nearly freespeech but eventually gave up and tried getting the social profile extension to work. That asked me to run the update.php and after that the FBconnect started working. I thought it said in the instructions for FB connect you could either run update.php or import the .sql and I went with the second option. Well it looks like its working now so I will have to play around with it and see what I think of it and if it could be stable enough for my main wiki.


 * Sorry FBML didn't work the first time around. It indeed seems like updating is necessary, instead of just importing the sql file. I modified the main page to reflect these instructions. Also, Facebook has deprecated the "API Key" (though it may still work) so you should use the "App ID". Finally, there is a new version available, 3.0, that will hopefully fix other problems as well. Hope this works for you in the end! --Gbruin 07:35, 4 January 2011 (UTC)

"Like this page"
Is there also a way to connect MediaWiki pages to the "like this page" Facebook feature? http://www.facebook.com/help/?page=773 Tisane 21:40, 7 May 2010 (UTC)


 * XFBML has been a feature of this extension since Day 1. On pages you want this button to show up on, you could probably add the corresponding XFBML code. If you want a "like" button to show up on every page, check out the links at the bottom of Manual:$wgSiteNotice. Simply stick the XFBML code in and, because this extension validates the use of XFBML, it should show up on every page! Gbruin 18:51, 8 May 2010 (UTC)
 * How does the Facebook developers' wiki integrate with Facebook? I notice that there are hardly any extensions listed: http://wiki.developers.facebook.com/index.php/Special:Version Tisane 10:01, 16 May 2010 (UTC)


 * The Facebook Developer Wiki (now deprecated) was setup by Arjun Banker. It ties directly into Facebook's database of 500 million users. -Gbruin 01:57, 6 June 2010 (UTC)


 * I went ahead and used  I suppose it would be best to create a hook for Manual:Hooks/SiteNoticeBefore to suppress the "like" button when one is editing a page, viewing its history, etc. $wgRequest might be useful in implementing this. Tisane 11:16, 16 May 2010 (UTC)


 * XFBML supposedly needs closing tags, so I would recommend . I have no plans to strip XFBML out of SiteNoticeBefore calls, but I imagine this can be accomplished with magic words or ParserFunctions. If you write the template, we'll upload it to the extension page. -Gbruin 01:57, 6 June 2010 (UTC)

"Turn around with WIKI 1.15.3 / 1.16.beta2 and FBConnect (SVN Release available on 10 May 2010)
I am not a seasoned developer on MediaWiki, but I follow exactly the different installation steps you provide. I let the two login possibilities Wiki && Facebook. When I point to Wiki, I have the two links (FaceBook && Classic WiKi) for login connect as text only. When I try through FaceBook, I have a Special Page with error message in tag Title.

If I log though the classic Wiki login (As wikiSysop), it is OK. Now I am logged, If I try again with FaceBook connect, he tells me "I am already connected" but this time I have the FaceBook Icon Login button. Now If I try it (the FaceBook login button), I access to my FaceBook specific application popup and I allow access to my Public Information. I am again directed on the Wiki to a verification Error Page, with the same design as previously, but with the following message as a link : "You can convert your account as a FaceBook connect" the Special:Connect/Convert page. But, this link it is a loop on the current page. Of course no FaceBook users are recorded in {prefix}user_fbconnet.

I notice also in FBConnectDB I must remove prefix in getPrefix method => Last line  I correct as [return $s=';] I removed self::sharedDB..... Then the table name is prefixed correctly.

== With the changes inside FBConnect about the database, it Woks correctly with the MEDIAWIKI 1.16.beta2 == => But One day only, from the 12th of May to the 13th. Now, neither the 1.15 nor the 1.16 works. Now, there are not any buttons and nothing works. Is there an other place to find more informations ?

Thanks for any help. Marcel Bariou 14 May 2010

Issues with r180
I just installed FBConnect at Libertapedia: http://libertapedia.org/wiki/Special:Version

A few issues. First, although SVN tells me I checked out r180, in Special:Version, it says r152, April 14, 2010. Also, there's a typo; it says "You are loggin out of both this site and Facebook." There is supposed to be a "g" at the end of "loggin." Tisane 10:36, 16 May 2010 (UTC)
 * Good catch! I fixed the typo in the svn (r191). I guess it was too much work updating the version string every commit. When I have time I might update the code to calculate this dynamically. -Gbruin 19:52, 22 May 2010 (UTC)

Also, does any XFBML stuff besides  and  work?  and  are behaving kinda strangely, saying they're logged out and then, when you click on an item, not letting you log in (try it out at http://libertapedia.org/wiki/Libertapedia:Recommendations and http://libertapedia.org/wiki/Libertapedia:Activity) and Facepile doesn't seem to work. Nor does the like box seem to work. The latter two simply do nothing; the tags are not processed in any way and appear as plaintext.

Thanks for developing this extension, by the way; it's pretty badass! Tisane 11:50, 16 May 2010 (UTC)
 * Thanks for the appreciation. Before F8, only a small subset of XBML tags were supported, and I've been sticking in others as I became aware of them. Later today I'll update the list straight from the source. In the future, if Facebook adds a tag (or you make your own custom one!) the list can be modified in MediaWiki with the XFBMLAvailableTags hook. -Gbruin 19:52, 22 May 2010 (UTC)

Update
Now I'm getting this error when I try to login:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

INSERT INTO `user_fbconnect` (user_id,user_fbid) VALUES ('0','509992950')

from within function "FBConnectDB::addFacebookID". Database returned error "1062: Duplicate entry '509992950' for key 'PRIMARY' (localhost)".

I tried deleting the only row from the user_fbconnect table and retrying, but then it didn't login, and the next time I tried to login, I got the same error. The row in user_fbconnect was re-created. Tisane 12:14, 16 May 2010 (UTC)
 * Somehow the user_id field in user_fbconnect got set to 0. I manually changed it to 1 (i.e. the sysop account) and it worked. Tisane 12:21, 16 May 2010 (UTC)
 * Now, though, if I logout and then log back in by clicking "login / create account," it doesn't actually log me in. I have to login with Facebook Connect. Tisane 12:29, 16 May 2010 (UTC)
 * I believe this bug was brought about by changes in the user-creation code for compatibility with clustered servers. I ran into this problem myself when I updated this extension to use the new Facebook PHP SDK yesterday. I believe I've fixed this problem for non-clustered wikis (and hopefully didn't break it for larger deployments), but the update to the new PHP SDK might come with problems of its own. If you run into any, report them here! -Gbruin 20:22, 22 May 2010 (UTC)

MediaWiki SVN
Is there any possibility of using the MediaWiki SVN rather than SourceForge's? That would enable download through Special:ExtensionDistributor. I didn't want to upload it to SVN without asking lest we run into similar problems as what happened here. Tisane 01:10, 23 May 2010 (UTC)
 * Yeah, that would be really good. --Diego Grez return fire 01:11, 23 May 2010 (UTC)
 * Fair enough. commit access requested :) -Gbruin 22:39, 24 May 2010 (UTC)
 * Approved. I'll work on checking it in sometime over the next week. -Gbruin 04:50, 28 May 2010 (UTC)
 * If you run into any trouble with the SVN I can help. (I found it a bit tricky to work with at first) Tisane 06:34, 31 May 2010 (UTC)
 * Oh, oops, I thought you said "weekend." Sorry, I kinda jumped the gun and committed it early. Well anyway, now that it's in MediaWiki SVN, I may as well work on moving those configuration variables into $wg global variables. Tisane 07:26, 31 May 2010 (UTC)
 * Done; they are all changed now. Tisane 09:33, 31 May 2010 (UTC)
 * Saw that. Thanks a bunch! I'm struggling with ssh, putty is putting up a fight. Any way to whip TortoiseSVN into shape? -Gbruin 03:08, 1 June 2010 (UTC)
 * Hmm, I take it you are working with Windows? To be honest, the easiest thing would be to set up Ubuntu Linux and use the command line svn. But failing that, you could try these instructions, if you haven't already: Download_from_SVN The problem is, those instructions don't really take you step-by-step through the entire process of getting set up with putty and everything else. And I don't have a Windows installation anymore with which to create a more complete set of instructions. So I think your best bet may be to get on IRC, explain the specific problems you are encountering, and ask for help; that is what I had to do to figure it out. And at some point, some new user should write a full step-by-step set of instructions for getting set up with SVN, while it is still fresh in his memory. :) That is basically what I did with the XAMPP instructions. Sorry I couldn't be as helpful as I thought I would be able to be. Tisane 07:59, 1 June 2010 (UTC)

Extension was removed again from svn.wikimedia.org because it was not being maintained. siebrand 22:49, 5 December 2010 (UTC)

Configuration variables
The configuration variables should be set using globals in LocalSettings.php (e.g. $wgFbAppId), rather than in config.php. Tisane 04:11, 26 May 2010 (UTC)

"Please update the $fbAppId in config.php"
I just installed the newest revision (r204) and am getting a message, "Please update the $fbAppId in config.php." The config settings are the same as before, and I checked them against the Facebook dashboard to be sure they hadn't changed. I also tried using both the app key and the app ID for $fbAppId and neither worked. Tisane 04:23, 26 May 2010 (UTC)
 * Think this could be the problem? The name of $fbSecret changed also. I'll update the script to use the old variable $fbApiSecret if found. -Gbruin 07:33, 26 May 2010 (UTC)
 * Ah, OK. Yeah, it was the fact that the name of that configuration variable changed. Tisane 06:50, 31 May 2010 (UTC)

Demo site?
Is there a demo site where we can see what this extension does and what features it adds? --Choshi 23:39, 30 May 2010 (UTC) Our site is using it, [| Gamification.org]

Version strategy
If you have a version that worked pretty reliably with v1.15, you can upload that to the appropriate SVN branch for distribution under that version via Special:ExtensionDistributor. But I think going forward, we should focus on getting it to work with v1.16 and v1.17, which have overhauled preferences and whatnot. Most of the devs will be using those versions for their test wikis, so for collaboration purposes it's best if we do the same. Tisane 06:56, 31 May 2010 (UTC)
 * I changed the FBConnect version to 2.0.2, figuring that we'd already had one fairly major change that made it incompatible with previous versions. Tisane 09:01, 31 May 2010 (UTC)

Caching?
Do wikis using this extension still get any of the benefits of page caching, considering that the Facebook content has to be regenerated every time a page is loaded? Performance seems to take a hit when this extension is active. There should probably be an option in Preferences to turn off the FBConnect tag parsing (e.g. cause XFBML tags to show as plaintext or simply vanish), or at least to turn it off when the user is editing a page. The thing about wikis is that people are reluctant enough to edit them, but when any kind of slowness or other barrier is introduced, they become even more reluctant. Tisane 09:13, 31 May 2010 (UTC)
 * $wgFbUseMarkup -Gbruin 06:38, 11 June 2010 (UTC)
 * I don't mean that it should be toggled on or off globally for everyone in all situations. Tisane 16:52, 13 June 2010 (UTC)
 * To implement this, in what situations would we need to disable the rendering? -Gbruin 17:46, 13 June 2010 (UTC)
 * I'll need to put some deeper thought into that. A drawback of disabling the XFBML on the edit page is that some users might get confused by those Facebook items' disappearance when they switch from viewing to editing; plus it would make the page preview less representative of what the page will look like when the saved page is rendered. So maybe what I propose is unworkable. Upon further reflection, I'm really not sure what the best way to deal with the performance issues is. Tisane 15:19, 14 June 2010 (UTC)

Hook.php line 117
Hi,

After installing the extension, i got this error. Does anyone know what's meant by it?

"Warning: Parameter 1 to FBConnectHooks::UserGetRights expected to be a reference, value given in D:\xampp\htdocs\wiki\includes\Hooks.php on line 117"

Thanks a lot! --Dullmau 19:09, 10 June 2010 (UTC)


 * The prototype of the hook function might have changed across MediaWiki versions. What version of MediaWiki are you using? -Gbruin 02:09, 11 June 2010 (UTC)


 * Hi Gbruin, i'm using mediawiki 1.15. This is one of the most useful extensions to build up a community and i really hope to solve the problem... --Dullmau 13:59, 13 June 2010 (UTC)

I'm getting a similar error:

Detected bug in an extension! Hook FBConnectHooks::UserGetRights failed to return a value; should return true to continue hook processing or false to abort. Backtrace:
 * 1) 0 /Applications/MAMP/htdocs/mediawiki/includes/User.php(1976): wfRunHooks('UserGetRights', Array)
 * 2) 1 /Applications/MAMP/htdocs/mediawiki/includes/User.php(2125): User->getRights
 * 3) 2 /Applications/MAMP/htdocs/mediawiki/includes/Title.php(1206): User->isAllowed('edit')

Running r204 and MediaWiki 1.15.4 http://grab.by/50U2 -- Thanks Chao Lam 18 June 2010
 * FBConnectHooks::UserGetRights should always return true, period. Above, I should have asked for PHP version as well. I think this might be the culprit for several issues on this page. -Gbruin 21:02, 21 June 2010 (UTC)
 * I have same problem MediaWiki 	1.15.4, PHP 5.3.2-0.dotdeb.2 (cgi-fcgi), MySQL 	5.1.41-3ubuntu12.1-log. Any new related this problem??? PChott (pchott@gmail.com) --89.142.194.93 15:00, 17 July 2010 (UTC)

''Confirmed: This is a problem with PHP 5.3. For a solution, please see http://trac.wikia-code.com/changeset/24606/wikia/trunk/extensions/FBConnect.'' -Gbruin 00:02, 29 July 2010 (UTC)

Login and logout problems
The logout link "logout of facebook" seems dead, hovering over it shows the link "...?title=MainPage#", clicking on it does nothing.

Instead as for login is concerned, after I ran the sql code in phpmyadmin to create the necessary tables, I had continuous error messages because the table prefix for some reason was being added twice to the table name. I couldn't figure out where that was happening, in the end I just deleted the returned prefix from the "getprefix" function in FBConnectDB.php as so: private static function getPrefix { global $wgDBprefix, $wgSharedPrefix; return self::sharedDB ? $wgSharedPrefix : ""; } and things started working. However every time I login, although I am directed to the Special:Connect page with result:  Facebook verification succeeded - You have been successfully logged in with Facebook Connect  I get however the following popup: '' Not logged in. You have been logged out of Facebook. Press OK to log in via Facebook Connect again,    or press Cancel to stay on the current page. OK - CANCEL '' If I press OK I just get the same popup again, if I press cancel I'm alright but it keeps coming back every once in a while. And I am logged in to facebook as a result... I am using r204, May 23, 2010 of the extension. Lwangaman 09:39, 16 July 2010 (UTC)
 * Yeah, I was getting all kinds of problems like that too. Tisane 12:06, 16 July 2010 (UTC)
 * Wikia has implemented the code across their network of wiki's. The extension they use has many upgrades and fixes, but most are specific to their setup. (Not only do they have a cluster to load-balance servers, they have a load-balancer to load-balance clusters Smiley.svg). If you wish to try it, check out http://trac.wikia-code.com/browser/wikia/trunk/extensions/FBConnect. If you're OK with waiting a few weeks, I am taking their changes, removing wikia-specific content and integrating Facebook's newer php-sdk. -Gbruin 19:19, 16 July 2010 (UTC)
 * That sounds like a good idea, if their version works well. I don't think there's any need to rush with this extension; it's more a fun little optional thing for now, albeit with great potential. Tisane 16:20, 18 July 2010 (UTC)
 * So I will deactivate the extension. What a pity! It would be so comfortable. --Markusk21 16:54, 18 July 2010 (UTC)
 * As it is not Beta anymore it is urgent to solve this problems soon, please - btw. the example-link doesn't work either.--Markusk21 21:12, 18 July 2010 (UTC)
 * So I dont get. What's the deal? Why are we experiencing this?--to.rmine 19:39, 5 August 2010 (UTC)
 * I am having the same problem. Things seemed to be working fine for awhile. Now, I keep seeing the "Not logged in" dialog even though I am logged in and the Logout link doesn't work at all. -- 12 October 2010
 * Please do fix this? I keep getting the same error.. 87.211.219.33 12:33, 23 October 2010 (UTC)
 * Me too http://iwikia.com

Error 100: Invalid parameter
I managed to install this extension into my mediawiki. But when I try to convert or connect to/ by facebook login I get the mentioned Error code. Message is:

Error Message: next is not owned by the application.

What does that mean? How can I solve it?

--Markusk21 06:17, 17 July 2010 (UTC)

I solved it mysqlf: in the Facebook-application setting the connect options must be specific. I used the http://www.server.de Adress format as Connect-URL. So, from http://server.de it didn't work. Setting server.de at Main-Domain solved the problem. --Markusk21 10:08, 18 July 2010 (UTC)


 * Is this a problem with the instructions in the config php file not being descriptive enough? I can add the extra clarification if you think others will run into this problem. Gbruin 18:24, 18 July 2010 (UTC)

FBconnect couses that UsersList fail
UsersList like Special:ListUsers fail while FBconnect is active

Logs: php5-fpm: PHP Warning: Parameter 1 to FBConnectHooks::SpecialListusersHeaderForm expected to be a reference, value given in /var/www/www.e-studij.si/includes/Hooks.php on line 133 Backtrace: Detected bug in an extension! Hook FBConnectHooks::SpecialListusersHeaderForm failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:


 * 1) 0 /var/www/.../includes/specials/SpecialListusers.php(202): wfRunHooks('SpecialListuser...', Array)
 * 2) 1 /var/www/.../includes/specials/SpecialListusers.php(279): UsersPager->getPageHeader
 * 3) 2 [internal function]: wfSpecialListusers(NULL, Object(SpecialPage))
 * 4) 3 /var/www/.../includes/SpecialPage.php(791): call_user_func('wfSpecialListus...', NULL, Object(SpecialPage))
 * 5) 4 /var/www/.../includes/SpecialPage.php(559): SpecialPage->execute(NULL)
 * 6) 5 /var/www/.../includes/Wiki.php(254): SpecialPage::executePath(Object(Title))
 * 7) 6 /var/www/.../includes/Wiki.php(64): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
 * 8) 7 /var/www/.../index.php(117): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
 * 9) 8 {main}

Any suggestion? --PChott 20:34, 15 August 2010 (UTC)


 * Yup, the problem is identical to the one described in above. PHP 5.3.0 & PHP 5.3.2 (5.3.1 isn't supported) throws the error "... expected to be a reference, value given". The solution is to either use PHP 5.1 or 5.2, or apply a fix similar to the one mentioned above. Also, in the next few weeks (perhaps days) I'll release a PHP 5.3-compatible version of FBConnect. -Gbruin 23:20, 15 August 2010 (UTC)

Datenbank meldete den Fehler: 1146
Hallo, ich benutze die Funktion: Extension:FBConnect (Version 2.0.2 und MediaWiki 1.16.0). Alle läuft prima, nur wenn ich mich als Benutzer am Wiki (http://www.evweb.de) anmelde bekomme ich folgende Fehlermeldung:

Datenbankfehler

Es ist ein Datenbankfehler aufgetreten. Der Grund kann ein Programmierfehler sein. Die letzte Datenbankabfrage lautete:

(SQL-Abfrage versteckt)

aus der Funktion „FBConnectDB::getFacebookIDs“.

Die Datenbank meldete den Fehler „1146: Table 'DB******.user_fbconnect' doesn't exist (rdbms.strato.de)“.

Hat jemand eine Idee wo das Problem liegt? Danke! Gruß Michael


 * Sorry, aber ich spreche kein Deutsch. Führen Sie das Updater-Skript wie folgt aus:

> php maintenance/updater.php
 * Viel Glück! -Gbruin 00:14, 21 August 2010 (UTC)

Installed last version 2.0.2 but blocks my site
I just installed the latest version 2.0.2, updated the mysql tables and all... but I'm now getting the following error which prevents me from even seeing my site: Fatal error: Call to a member function free on a non-object in /membri/flatnuxwiki/wiki/extensions/FBConnect/FBConnectDB.php on line 68 I see in FBConnectDB.php that "free" is being called on "$res" ( "$res->free" ), and "$res" is supposed to be the result of a query on the database. I guess the query's not getting any result... Any ideas on how to fix? Lwangaman 04:08, 24 August 2010 (UTC)

Upgrading from older versions
Reading this in the article...
 * "Take care upgrading from older versions of this extension (from r91, pre-March 2010). Unfortunately, due to the new database layout, backwards compatibility was unable to be retained and considerable user renaming might have to be done. Sorry about that!"

So any recommendations as to what to do to get from Version r71 to current release? I have about 27 FBConnect users on our wiki and don't want to mess this up. Trying to get all my extensions upgraded prior to going from Mediawiki 1.15.1 to 1.16.--Bawheeler 02:18, 2 October 2010 (UTC)
 * Don't worry, nothing is deleted when you upgrade, their profiles just don't get migrated. I was new to MySQL, so forcing users to be named after their Facebook ID was my "creative spelling" way of avoiding databases for as long as possible. As far as migrating goes, you have two options.


 * First, create the new table, user_fbconnect</tt>, with the mediawiki ID <-> facebook ID associations pre-populated. That way, MediaWiki will know about their existing accounts, and also let new users choose their own non-numeric mediawiki ID.


 * Second, and this is what I did, is upgrade anyways and let all their accounts become reset. When they log in, they will be prompted to choose a new username. Then after they choose a new nickname, use Extension:User Merge and Delete to merge their old account into their new one. This is a more manual/laborious task, but with only 27 users (my wiki had 31) it's not too bad. Unfortunately, edit counts don't get merged, but it's easy enough to just add the two edit counts together and save the sum over the old value.


 * If you need help with either, or want more information, let me know! -Gbruin 21:47, 2 October 2010 (UTC)
 * Great. That sounds very similar to what I did when it was first installed as I merged our accounts with the new FBConnect accounts.  Thanks for the feedback.--Bawheeler 22:41, 2 October 2010 (UTC)

Hi i got this error after installing FBConnect
Detected bug in an extension! Hook FBConnectHooks::UserGetRights failed to return a value; should return true to continue hook processing or false to abort.


 * 1) 0 /customers/examplesite.com/examplesite.com/httpd.www/includes/User.php(2078): wfRunHooks('UserGetRights', Array)
 * 2) 1 /customers/examplesite.com/examplesite.com/httpd.www/includes/User.php(2228): User->getRights
 * 3) 2 /customers/examplesite.com/examplesite.com/httpd.www/includes/Title.php(1217): User->isAllowed('edit')
 * 4) 3 /customers/examplesite.com/examplesite.com/httpd.www/includes/Title.php(1059): Title->getUserPermissionsErrorsInternal('edit', Object(User), false, true)
 * 5) 4 /customers/examplesite.com/examplesite.com/httpd.www/includes/Title.php(1031): Title->userCan('edit', false)
 * 6) 5 /customers/examplesite.com/examplesite.com/httpd.www/includes/parser/ParserCache.php(38): Title->quickUserCan('edit')
 * 7) 6 /customers/examplesite.com/examplesite.com/httpd.www/includes/parser/ParserCache.php(55): ParserCache->getKey(Object(Article), Object(ParserOptions))
 * 8) 7 /customers/examplesite.com/examplesite.com/httpd.www/includes/parser/ParserCache.php(65): ParserCache->getDirty(Object(Article), Object(ParserOptions))
 * 9) 8 /customers/examplesite.com/examplesite.com/httpd.www/includes/Article.php(819): ParserCache->get(Object(Article), Object(ParserOptions))
 * 10) 9 /customers/examplesite.com/examplesite.com/httpd.www/includes/Wiki.php(493): Article->view
 * 11) 10 /customers/examplesite.com/examplesite.com/httpd.www/includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
 * 12) 11 /customers/examplesite.com/examplesite.com/httpd.www/index.php(117): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
 * 13) 12 {main}

--Mosik 18:55, 31 October 2010 (UTC)
 * Hi Mosik, that you for reporting this error. please leave your version for the following software: PHP, MediaWiki and FBConnect extension. I believe this error is due to an incompatibility between some versions of PHP and MediaWiki when it comes to a few functions (namely, UserGetRights and SpecialListusersHeaderForm in FBConnectHooks.php). I recommend updating the extension (most recent version as of tonight is 3.0, revision 359), and if the problem persists you can let me know here. Thanks! --Gbruin 75.83.85.178 04:30, 29 December 2010 (UTC)

Special:UserList
Detected bug in an extension! Hook FBConnectHooks::SpecialListusersHeaderForm failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:


 * 1) 0 /var/www/includes/specials/SpecialListusers.php(202): wfRunHooks('SpecialListuser...', Array)
 * 2) 1 /var/www/includes/specials/SpecialListusers.php(279): UsersPager->getPageHeader
 * 3) 2 [internal function]: wfSpecialListusers(NULL, Object(SpecialPage))
 * 4) 3 /var/www/includes/SpecialPage.php(791): call_user_func('wfSpecialListus...', NULL, Object(SpecialPage))
 * 5) 4 /var/www/includes/SpecialPage.php(559): SpecialPage->execute(NULL)
 * 6) 5 /var/www/includes/Wiki.php(254): SpecialPage::executePath(Object(Title))
 * 7) 6 /var/www/includes/Wiki.php(64): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
 * 8) 7 /var/www/index.php(117): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
 * 9) 8 {main}

ANY tips what is wrong? --PChott 10:33, 12 December 2010 (UTC)
 * ''Hi PChott, I think the problem is related to an error that you actually help point out and fix in revision 274. Like the problem above this, it seems to be an incompatibility between PHP and MediaWiki concerning several functions (namely, UserGetRights and SpecialListusersHeaderForm in FBConnectHooks.php). I recommend updating the extension (most recent version as of tonight is 3.0, revision 359), and if the problem persists you can let me know here. Thanks! --Gbruin 04:36, 29 December 2010 (UTC)
 * Follow up: I new I had seen this problem before :) right up above, under, I identify the problem as a PHP 5.3 issue. The solution is to find the afflicted function and remove the & from the right parameter like this. The most recent version on SourceForge, 3.0 rev. 359, should contain these fixes. If not, please let me know! --Gbruin 04:43, 29 December 2010 (UTC)
 * Works in latests version of Facebook extension. Thx. --PChott 07:11, 5 January 2011 (UTC)

Strange Facebook button
Can you guys help me fixing the Facebook connect button on http://www.wikireceitas.com.br ? What´s wrong?


 * I was moving some code around in the SVN and I'm guessing you got a transitional version. What version of the extension are you using? Can you try the most recent version, 3.0_r388? N.B. I changed the folder name from "FBConnect" to "Facebook". --Gbruin 07:19, 4 January 2011 (UTC)


 * Just downloaded and I still have the same problem. I changed the default language to english to test it and I get the same. It looks like a CSS problem, so maybe I have some CSS missing? Filipe, 4 January 2011


 *  Well, I found the problem but I have no clue what is causing it. Do you know how to add CSS to your wiki? Adding this will make it look a lot better: Give it a try, and if it still looks weird we'll figure something else out. --Gbruin 01:43, 9 January 2011 (UTC)

What about networks that restrict access to facebook?
I've been successful in implementing this extension on a external mediawiki website for students, but then I found out that at their school, the facebook login extention is blocked en mass with the main facebook website. I've been told by the school IT manager that if I can show a way to enable facebook authentication only and still allow main facebook site to stay blocked, that he would consider opening the login portion only. Does anyone know what to ask the IT folks for who manage the firewall so that they can keep FB block but allow this extensions to work for the students wiki?

-- FOLLOW-UP -- After digging around a little bit, I've gotten the impression that facebook uses the "login.facebook.com" domain to handle authentication (please tell me if this is correct). Would it be as simple as opening the "login.facebook.com" only? If so, is there any documentation that supports this that I could sumbit to the IT folks? any help is greatly appreciated. thanks.


 * Here are my thoughts:


 * This probably doesn't have an easy solution now. In the past I accomplished this by blocking www.facebook.com and allowing connect.facebook.com. However, if a user visited connect.facebook.com then they would basically get a working Facebook with some broken images, so it wasn't effective at keeping more tech-savy users out.
 * For reference, here are the Facebook domains that I see getting hit by this extension.
 * connect.facebook.net (for the Facebook JavaScript SDK - this can be overridden in the file config.default.php)
 * static.ak.fbcdn.net (Facebook Content Delivery Network - used for the Facebook logo, can also be overridden)
 * www.facebook.com/login.php (opened in a new window by the javascript sdk to authenticate users)
 * login.facebook.com/login.php (performs the actual login when a user clicks Login)
 * Facebook uses the standard OAuth 2.0 protocol for authentication and authorization. The entire goal of this protocol is obtaining an access token for the user (on the server side). The Facebook JavaScript SDK does this by having the user login to www.facebook.com; Facebook itself then sends the access token to the server if the user has allowed Facebook to do so. I think that your problem can be solved by replacing the JavaScript SDK login with another client-side method (white-listed by the network, of course) for obtaining the access key, and then sending this access key to the server. Alternatively, this method can even be run on the server if the server asks for the user's Facebook username and password (kind of a no-no). Some resources to start with are the OAuth 2.0 protocol, Authentication Overview, Desktop Authentication and Mobile authentication.
 * Something else you should consider is that the server itself needs to be white-listed because it relies on calls to the Facebook API. Alternatively, the extension can easily be modified so that the server talks to Facebook by proxy.


 * Hopefully you're up for some programming. Good Luck! --Gbruin 04:20, 10 January 2011 (UTC)

{|
 * --Revansx 18:00, 10 January 2011 (UTC)
 * Thanks for the prompt response, the insights and options. I'm sad that there isn't a proper and clean solution. I think that as it becomes more and more evident that using a single third party identity service (not necessarily facebook) is better for users than having them manage many individual user accounts, that this type of issue will be addressed in the architecture of those services (lol - I don't think that FB foresaw the universality of their service as a general network identity service apart from FB social features).

That said, since there isn't a 'clean and proper' solution, I have my choice of work-arounds.... I'd like to learn more about the last option you gave.