Extension talk:Facebook/Archive 1

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)!


Way to not let users choose a username

I'm reading that this Username choice screen is a somewhat new feature in this extension. I want to make it so that the users don't get a chance to choose their name. I want it to only be their facebook 'real' name. Is there an easy way to modify the SpecialConnect.php to eliminate the choices? My PHP isn't great, and it all seems intertwined. 68.0.118.80 06:51, 12 May 2012 (UTC)Reply

Live with it
Gouge your eyes out with an icepick
Become an expert in PHP and mediawiki's API
That is in order of decreasing suggestion and increasing pain

SOLVED "Fatal error: Call to a member function getNamespace() on a non-object in /includes/Skin.php on line 250" ???

Im include facebook extension in Localsettings my Search is going to Fatal error.
I cannot resolve this error, why facebook extension error on search page? My site is http://www.nasill.com if click search http://www.nasill.com/%C3%96zel:Ara?search=&go=Go get error. Can you help me? Mediawiki : 1.17.0
Facebook Open Graph for MediaWiki (Version 4.0-final, Valentine's Day, 2012)
Facebook sdk is latest
thanks --Wikican (talk) 20:06, 24 February 2012 (UTC)Reply

Let's figure out what's going on. If you remove your custom skin, does the problem still happen? If you upgrade to MediaWiki 1.17.2 or 1.18.1, does the problem still happen?
Also, I see that the Facebook logo is off-center on your custom skin. I just fixed this problem in the most recent GitHub version, this should fix the off-centered logo on your wiki. --Gbruin (talk) 20:30, 24 February 2012 (UTC)Reply
Thanks, i changed skin but This error is not due to skin;?--Wikican (talk) 20:38, 24 February 2012 (UTC)Reply
OK. I solved problem. Facebook extension conflict ChangeAuthor extension, i remove it and system began working properly.

How do I find? I started to disable every single extension. refresh error page.

Good detective work :) --Gbruin (talk) 20:53, 24 February 2012 (UTC)Reply

"User Rights from Facebook Group" not working???

The facebook user authentication works great, however, the user rights from groups does not.

The symptoms are:

  • Special:ListUsers does not show Facebook REAL names (as configured to)
  • Special:ListUsers does not show group memberships (as expected to based on the facebook group)
  • see next statement below:

When I visit the wiki User List page at "Special:ListUsers" is says,

bureaucrat and administrator privileges are automatically transfered 
from the officer and admin titles of the Facebook group <>.
For more info, please contact the group creator <>. 
The default Facebook group image
"?"
when no image is provided

in the past,I remember this page correctly showing the group's name, owner, and group image

bureaucrat and administrator privileges are automatically transfered 
from the officer and admin titles of the Facebook group <fbgroupname>.
For more info, please contact the group creator <fbgroupowner>. 
<fbgroup-logo>

Here's what I've got:

Product          Version
-------------------------------
A-Apache         2.2.6 (Win32) mod_ssl/2.2.6 OpenSSL/0.9.8g PHP/5.2.5
M-MySQL          5.0.45-community-nt-log
P-PHP            5.2.5 (apache2handler)
-------------------------------
MediaWiki        v1.16 & 17 (same problem)
Facebook Connect Version 3.0_r403, 2/5/2011)
-------------------------------

any insights, tests, or experience to the contrary would be highly valued. --Rich

Explanation:

  • This feature (FB group permissions) apparently used to work on all groups regardless of the status of the group. Now it seems that "Closed", and "SECRET" groups will not work with this extension's attempt to get the group data (like members, owner, logo, etc...) from the group unless the group is "OPEN".
  • The way I have found to test this is to use the group's ID with the Facebook 'graph' service and see if it returns the the group information or 'false'. If false, then you can not use this group for Mediawiki permissions...
  • Example: https://graph.facebook.com/1234567890/ where "1234567890" is a group number.

If I'm wrong, please let me know... otherwise I hope this note saves people all the troubleshooting and frustration that I went through... Good Luck!

Database update

I don't have access to command line, because I use a shared web server. Any alternatives?
Make a local copy, update then load it back? --LaKing 16:54, 21 February 2011 (UTC)Reply
U can access to comand line by php system comand or exec --User teamspeak Info 10:49, 9 August 2011 (UTC)Reply

<?php
echo exec('whoami');
echo exec('/path/to/php /path/to/mediawiki/folder/maintenance/update.php');
?>

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)Reply

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.

Similar Issue:

I have done the following:

Updated the LocalSettings.php Updated the FB app # and security.

When I went to run maintenance/update.php I get the following error.

Fatal error: Out of memory (allocated 12058624) (tried to allocate 90 bytes) in /home/wikipla1/public_html/includes/LocalisationCache.php on line 616

Facebook Connect didn't start at all

Hi all!

When I've clicked on the FB-login button and allowed access to my FB-account from my FB-app I got the following message?

Database error A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "FacebookDB::getUser". Database returned error "1146: Table 'notyetproduced_com.mw_notyetproduced_com_user_fbconnect' doesn't exist (s246.loopia.se)".

On my MySQL server and mw-database I haven't seen any new tables such as user_fbconnect, fbconnect_event_stats or fbconnect_event_show (from Facebook/sql/). The $wgDBprefix-bug is solved in FacebookDB.php where also this problem is highlighted. Maybe the MW-updater in maintenance/update.php isn't working when I'm opening it up locally, and then sends it back to the server. I've tried to get access the commandline from puTTY to my web host but I fail to establish a connection.

My prerequisites are: Facebook extension version: 3.0_r403, MediaWiki version 1.16.1, PHP version: 5.3.3, MySQL server version 5.1.54, PHP MySQL client version: 5.0.90

Solutions please?

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)Reply


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:
// Add the logout behavior to the "Logout of Facebook" button
$('#pt-fblogout').click(function() {
	if (confirm("You are loggin out of both this site and Facebook.")) {
		FB.logout(function(response) {
			window.location = window.fbLogoutURL;
		});
	}
});
Hope this helps in tracking down your error! Gbruin 19:40, 25 April 2010 (UTC)Reply


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)Reply

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)Reply

Path and cross-domain issues...

...are now a thing of the past! For details, see Extension:FBConnect#No more annoying xd receiver.php!.

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)Reply

Compatibility issues

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)Reply

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)Reply

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)Reply


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)Reply

It works on wiki-farms, however you might to do slight modifications manually. --LaKing 17:07, 24 February 2011 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply
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)Reply
In 1.15.2 it still errors because the Html class isn't in v1.15 either ;) -SColombo 02:01, 8 April 2010 (UTC)Reply
*facepalm* haha should work now Gbruin 18:23, 8 April 2010 (UTC)Reply

PHP4.4 - no joy?

I'm on paid hosting, no root access, and the server is running php 4.4. Does this mean I'm plain old S.O.L.? I did try to install (uploaded the extension, extracted the tarball, edited my LocalSettings.php to require once blah blah), ran php maintenance/update.php, got an error, and it seems to have hosed the whole wiki. No worries, since removing the require statement in LocalSettings.php put everything right, again, but, no joy with the FB goodies.

--Tonybaldwin 02:18, 27 March 2011 (UTC)Reply

Are you sure your server doesn't have both PHP5 and PHP4? —Emufarmers(T|C) 07:54, 27 March 2011 (UTC)Reply

Working with ConfirmAccount

Because of ridiculous spam I installed ConfirmAccount which is ideal. However, it does not work with this Facebook login. If ConfirmAccount is turned on and someone tries to login for the first time via Facebook they receive the error message:

You do not have permission to create this user account, for the following reason: 
The action you have requested is limited to users in the group: Administrators.

Is there any way to bypass checking for facebook users but keep it for "normal" users?


Username issues

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)Reply

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)Reply

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)Reply

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)Reply

  • 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)Reply

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 [1]). A workaround is to use float ... see [2], 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)Reply

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)Reply

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)Reply

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)Reply

Authentication issues

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)Reply


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)Reply
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)Reply
--96.20.202.45 01:37, 2 June 2009 (UTC)Reply
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)Reply

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)Reply

- 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)Reply

- 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)Reply

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  ).
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)Reply
Thanks, Gbruin. I am now running MW 1.16.2 and Facebook v 3.0 (January 3rd, 2011). On my Main Page, the facebook icon does not appear, and clicking the "Log in with Facebook" link produces no results. Nothing. I have verified that this happens on my skin as well as monobook. On every other page, this works just great...I can see the icon, and all functionality works as described. Here is my wiki.
Any toughts?
Thanks!
--John Thomson 05:49, 6 March 2011 (UTC)Reply
I just realized the "Latest Version" attribute for this extension wasn't updated in February. I installed "Version 3.0_r403, February 5, 2011", but I still have issues. This time, a pop-up box appears, /something/ happens, and the pop-up disappears. No log in happened. Same thing though, on every other page, this works as expected. --John Thomson 13:28, 6 March 2011 (UTC)Reply

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)Reply

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)Reply

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)Reply


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)Reply

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)Reply

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)Reply
I was able to fix it by commenting out these lines in PreferencesExtension.php:
/*wfProfileIn(__METHOD__);
	
    // we 'override' the default preferences special page with our own
    $list["Preferences"] = array("SpecialPage", "Preferences", "", true, "wfSpecialPreferencesExtension");
	
	wfProfileOut(__METHOD__);*/

And also:

/*global $wgRequest;
    $prefs = new SpecialPreferencesExtension($wgRequest);
    $prefs->execute();
	
	wfProfileOut(__METHOD__);*/

Tisane 11:01, 16 May 2010 (UTC)Reply

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)Reply

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

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)Reply

I get the same results using MediaWiki v1.16.1, PHP v5.2.9 (litespeed), MySQL v5.0.77 and version 3.0 of extension except when I change "require_once("$IP/extensions/FBConnect/FBConnect.php");" to "require_once("$IP/extensions/Facebook/Facebook.php");" I get this message "Please update $wgFbAppId and $wgFbSecret.". I have put my AppID and AppSecret in to config.php in the Facebook extension folder --Benregn 13:10, 12 January 2011 (UTC)Reply

I noticed that I renamed my "config.default.php" to default.php instead of config.php. However, now the Facebook connect button looks weird... But I habe applied the CSS fix mentioned on this talk page :) --Benregn 13:30, 12 January 2011 (UTC)Reply

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 <fb:comments></fb:comments> 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)Reply


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)Reply

"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)Reply

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#See also. 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)Reply
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)Reply
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)Reply
I went ahead and used $wgSiteNotice='<fb:like>'; 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)Reply
XFBML supposedly needs closing tags, so I would recommend $wgSiteNotice='<fb:like></fb:like>';. 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)Reply

"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

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)Reply

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)Reply
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)Reply
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)Reply

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)Reply

Yeah, that would be really good. --Diego Grez return fire 01:11, 23 May 2010 (UTC)Reply
Fair enough. commit access requested :) -Gbruin 22:39, 24 May 2010 (UTC)Reply
Approved. I'll work on checking it in sometime over the next week. -Gbruin 04:50, 28 May 2010 (UTC)Reply
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)Reply
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)Reply
Done; they are all changed now. Tisane 09:33, 31 May 2010 (UTC)Reply
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)Reply
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#Using_TortoiseSVN 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)Reply

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

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)Reply

"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)Reply

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)Reply
Ah, OK. Yeah, it was the fact that the name of that configuration variable changed. Tisane 06:50, 31 May 2010 (UTC)Reply

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]Reply


I checked out the demo site testpedia.us and it's giving me a similar error to the one I've been getting when I try to set up Facebook extention on my 1.16.1 MediaWiki installation:

Database error A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: SELECT user_id FROM `user_fbconnect` WHERE user_fbid = '1082567374' LIMIT 1 from within function "FBConnectDB::getUser". Database returned error "1146: Table 'rpedorg_testpedia.user_fbconnect' doesn't exist (localhost)".

The only problem I've noted is that update.php doesn't seem to work all the way through. I'll run it, and it returns this (or similar) error:

Fatal error: Out of memory (allocated 7340032) (tried to allocate 7680 bytes) in /home/divinewi/public_html/wiki/languages/Language.php on line 507

But then after that it appears to work for a bit - I get the app connect, facebook login, all that. Then after logging in, I get this error:

Database error A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "FacebookDB::getUser". Database returned error "1146: Table 'divinewi_wikiDB.user_fbconnect' doesn't exist (localhost)".

My wiki site is divinewithin.us Hope to get this up and running soon! --MatheoDJ 17:49, 5 February 2011 (UTC)Reply

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)Reply

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)Reply

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)Reply

$wgFbUseMarkup -Gbruin 06:38, 11 June 2010 (UTC)Reply
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)Reply
To implement this, in what situations would we need to disable the rendering? -Gbruin 17:46, 13 June 2010 (UTC)Reply
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)Reply

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)Reply

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)Reply
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)Reply

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)Reply
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)Reply


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)Reply

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)Reply

Yeah, I was getting all kinds of problems like that too. Tisane 12:06, 16 July 2010 (UTC)Reply
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  ). 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)Reply
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)Reply
So I will deactivate the extension. What a pity! It would be so comfortable. --Markusk21 16:54, 18 July 2010 (UTC)Reply
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)Reply
So I dont get. What's the deal? Why are we experiencing this?--to.rmine 19:39, 5 August 2010 (UTC)Reply
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)Reply
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)Reply

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)Reply

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)Reply

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)Reply

Yup, the problem is identical to the one described in #Hook.php line 117 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)Reply


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)Reply

Datenbank-prefix problem? Ist das prefix villeicht verdoppelt? --LaKing 15:26, 24 February 2011 (UTC)Reply

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)Reply

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)Reply

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, 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)Reply
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)Reply

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)Reply

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)Reply

No longer show any error with the latest version, very nice Mosik 19:24, 11 March 2011 (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)Reply

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)Reply
Follow up: I new I had seen this problem before :) right up above, under #Hook.php line 117, 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)Reply
Works in latests version of Facebook extension. Thx. --PChott 07:11, 5 January 2011 (UTC)Reply

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)Reply
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:
.fb_button, .fb_button_rtl { background: none !important; }

Give it a try, and if it still looks weird we'll figure something else out. --Gbruin 01:43, 9 January 2011 (UTC)Reply

Worked! Thanks! :) Filipe, 10 January 2011
How can I change the text size of the "Log in with Facebook"? --Benregn 14:32, 12 January 2011 (UTC)Reply
I would also like to change the text size. This CSS fix worked to remove the broken background, but the font size is still out of my control. The only place a grep of my entire server found "fb_button" and "fb_button_small" was in the FacebookHooks.php and I can't for the life of me see any CSS attributes assigned on that page. I am using the most recent version available from the extension's page on this site. Hopefully it's just the cold medication, but I'm very confused. --NoxDineen 13:51, 23 March 2011 (UTC)Reply

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.

--Gbruin 04:20, 10 January 2011 (UTC)Reply

Here are my thoughts:
  1. 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.
  2. 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)
  3. 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.
  4. 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)Reply

--Revansx 18:00, 10 January 2011 (UTC)Reply

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 (Option #4) you gave. How easy is easy? Is it enough to point out what files need to be modified? Is it just urls in the 'config.default.php' file as you suggested?

No such file (wiki_user_fbconnect.sql) error trying to create DB table

  • Version: 3.0_r388 (January 3, 2011) -- just downloaded the SourceForge tarball an hour or so ago (Feb 16, 2011).
  • MediaWiki version: 1.16.0
  • PHP version: 5.2.14
  • SQL version: 5.0.91-community
  • URL: www.theplantencyclopedia.org

Attempting to run MediaWiki's update.php script results in the following error:

Creating wiki_user_fbconnect table...Warning: fopen(/home/adendev/public_html/extensions/Facebook/sql/wiki_user_fbconnect.sql): failed to open stream: No such file or directory in /home/adendev/public_html/includes/db/Database.php on line 2166
Could not open "/home/adendev/public_html/extensions/Facebook/sql/wiki_user_fbconnect.sql".
Backtrace:
0 /home/adendev/public_html/maintenance/updaters.inc(251): DatabaseBase->sourceFile('/home/adendev/p...')
1 /home/adendev/public_html/maintenance/updaters.inc(1134): add_table()
2 /home/adendev/public_html/maintenance/update.php(44): do_all_updates('wiki_user_fbcon...', '/home/adendev/p...', true)
3 {main}

I have double-checked and no file named wiki_user_fbconnect.sql is included in the currently available version of the extension. Is the reference supposed to be to user_fbconnect.sql? If so, which file(s) do I need to edit to update the reference?

Thanks for any assistance with this.

In my opinion all three .sql files. After making a copy with adding your prefix update runs smoothly, but you will experience other errors in your configuration--LaKing 15:29, 24 February 2011 (UTC)Reply

Collision with LightboxThumbs

I'm currently having problems running Facebook and LightboxThumbs on the same wiki. This probably has to do with the fact that the lightbox uses Prototype, which collides with Facebook's jQuery. I suggest using the $j handle instead of just $, where $j should be defined as jQuery.noConflict(); Litso 10:50, 17 February 2011 (UTC)Reply

Getting fatal error

I am getting these errors.

Fatal error: Uncaught exception 'Exception' with message 'Facebook needs the CURL PHP extension.' in C:\wamp\www\Wiki\extensions\Facebook\php-sdk\facebook.php:4 Stack trace: #0 C:\wamp\www\Wiki\extensions\Facebook\Facebook.php(75): require_once() #1 C:\wamp\www\Wiki\LocalSettings.php(239): require_once('C:\wamp\www\Wik...') #2 C:\wamp\www\Wiki\includes\WebStart.php(116): require_once('C:\wamp\www\Wik...') #3 C:\wamp\www\Wiki\index.php(42): require_once('C:\wamp\www\Wik...') #4 {main} thrown in C:\wamp\www\Wiki\extensions\Facebook\php-sdk\facebook.php on line 4

Any suggestions?

I am running MW 1.16.1

You need the cURL PHP extension. —Emufarmers(T|C) 02:16, 27 February 2011 (UTC)Reply

Update.php Trying to Recreate Database

So, I have installed the extension, and it works fine for logging in and connecting to a Facebook account. Using full real names in the site also seems to work, but I can't get any XFBML to render. When I view source, the code is just gone, but still stored in the page on an edit.

Oddly, when I run update.php, I get the following:

"Creating user_fbconnect table...A database query syntax error has occurred.
The last attempted database query was:
"CREATE TABLE `user_fbconnect` (
 user_fbid BIGINT unsigned NOT NULL PRIMARY KEY,
 user_id int(10) unsigned NOT NULL
 ) ENGINE=InnoDB, DEFAULT CHARSET=binary
"
from within function "DatabaseBase::sourceStream".
Database returned error "1050: Table 'user_fbconnect' already exists (localhost)""

So, I'm wondering what the issue could be. I'm running PHP 5.3.4, MediaWiki 1.16.1.

Thanks in advance!

--Christophermluna 14:02, 5 March 2011 (UTC)Reply

Edit: I just started getting this PHP error:

Warning: Parameter 3 to __lambda_func() expected to be a reference, value
given in /w/includes/parser/Parser.php on line 3333

--Christophermluna 14:53, 5 March 2011 (UTC)Reply

Ar doing a lot of searching about the parser error above, I found it was (probably) an issue of compatibility with PHP 5.3. I was able to solve the PHP error by replacing all instances of &$parser with $parser in FacebookHooks.php and FacebookXFBML.php.

I hope that this isn't going to break something later. I am not a PHP expert.

I am still getting the above Database error every time I try to run update.php, however, which is strange. Why is FBConnect trying to recreate this database on every update? Is it something I have done wrong?

Thanks!

--Christophermluna 01:36, 8 March 2011 (UTC)Reply

Uninstall problems

Hello, as I wasn't able to get the extension to work I decided to uninstall for the moment, and maybe give it a try again when I have for time for troubleshoting. However, the loginbar refuses to go away even after commenting out the extension in LocalSettings. Do I need to do something else? I have MediaWiki 1.16.1, PHP 5.3.3-7, MySQL 5.1.49-3 and FB revision 404. It's not a cache problem. (http://säsongsmat.nu/ssm/Special:Version) 213.89.121.199 20:14, 9 March 2011 (UTC)Reply

My bad, I had require_once(Facbook) twice in LocalSetting. Sorry. 213.89.121.199 20:15, 9 March 2011 (UTC)Reply

Facebook Connect button

First of all, this fb connect button look like a mess http://img851.imageshack.us/i/skrmklipp.png/

Second, I wonder alot. Aint it possible to move the nice looking button from "Special:Connect" and move it too the front?

The button looks better now, It seems. /MikaelLindmark 17:14, 19 April 2011 (UTC)Reply
It seems that the Vector skin that cause the problem. It looks OK with the monobook skin. /MikaelLindmark 12:05, 28 July 2011 (UTC)Reply
Is there a way to fix the problem with the vector skin? I love vector and would hate to give it up. --70.112.0.226 07:14, 8 October 2011 (UTC)Reply
The button has been fixed (sorry I allowed Facebook and MediaWiki updates to leave it so fugly). The development branch on GitHub contains these fixes. --Gbruin 00:22, 7 January 2012 (UTC)Reply

Add users created through FB Connect to autoconfirmed by default?

This might be too much to ask, but is it possible to snag a user's email address from Facebook and then add them to the autoconfirmed list by default when they create an account through this extension?

We've had serious issues with spam, and as a result have had to require users confirm their email address before they get create/edit permission. As of now that means anybody who registers through the Facebook extension is left unable to edit and confused about why.

--NoxDineen 15:21, 23 March 2011 (UTC)Reply

Extension installing, but just not working?

The whole thing installs and the button appears, (In a screwed up way like above) but it's just not WORKING. Step by step instructions anyone? Anywhere?

79.140.223.157 23:51, 13 April 2011 (UTC)Reply

There are some instructions in config.default.php. /MikaelLindmark 17:12, 19 April 2011 (UTC)Reply

PushToFacebook problems

Hi!

This extension works well (creating users from FB, logging in and out, etc) on my wiki except that the PushToFacebook doesn't work well. The tags seems to work since they write on my FB wall (such as <fb:like></fb:like>) but I want my Wiki article edits to show up on my FB wall as well (triggering the FBPush_OnLargeEdit code). I have tried to find why this doesn't work but failed.

Wiki server settings and versions:

I have turned $wgFbEnablePushToFacebook = true; both in config.php and LocalSettings.php.
The sql files are renamed since $wgDBprefix = "wiki_"; and the tables within are renamed to match.
$wgDBmysql5 = true;
$wgLanguageCode = "sv";
$wgFbExtendedPermissions=true;
Facebook for MediaWiki (Version 3.0_r403, February 5, 2011) (r404)
Linux Debian  5.0.8
MediaWiki     1.16.2
PHP           5.2.6-1+lenny10 with Suhosin-Patch 0.9.6.2 (cli) (built: Mar 19 2011 01:46:14) 32-bit int
MySQL         5.0.51a-24+lenny5

I would be happy if someone could give me some ideas or how I should debug further.

Sincerely, MikaelLindmark 08:10, 20 April 2011 (UTC)Reply

How to enable facebook comments for all wiki pages?

Does anyone knows how can I enable facebook comments for all wiki pages?

  • One way to do it is to use the Extension:PageNotice and put the facebook tag in the MediaWiki:Bottom-notice-ns-0 page. /MikaelLindmark 09:14, 7 August 2011 (UTC)Reply
  • I use Extensions:NewArticlesTemplate, and paste the code into the template. This requires some tweaking for getting the corrent page url for the comment box, but the following works: {{#tag:fb:comments||href=http://REDACTED.org/w/index.php?title={{FULLPAGENAMEE}}|num_posts=10|width=470}} It's also possible to edit on every page create of course, as it's in the template.

Cant get Tags working

hey

  • ive installed facebook extension, run update.php, get new api key, secure number and so on
  • loaded (required) in localsettings
  • pasted values to localsettings
  • can use connect to facebook and my account is be counted in fb-api list, so this is working

but! no tag i tried will give me any visable result, there is always nothing when i put the tags between a 1 and a 2... the result in sourcecode will be 12 nothing between them

  • Facebook_v3.0.r391
  • MediaWiki 1.16.4

any ideas? --91.65.185.199 12:25, 9 May 2011 (UTC)Reply

Found Solution - Extension talk:Facebook#Easy Fix for Parser.php 3333 Error --88.73.50.223 13:58, 10 May 2011 (UTC)Reply

Easy Fix for Parser.php 3333 Error

In the Facebook extension File: FacebookXFBML.php

around line 100:

$args = '$text,$args,&$parser';

change to:

$args = '$text,$args,$parser';

(remove & in front of $parser)

Will fix the error!

Thx myself  :) --88.73.50.223 13:57, 10 May 2011 (UTC)Reply

Update database from command line

How do I update my database from a command line? I have no idea how I should do this. Windows 7 PHP 5 MySql 4.1.22
This is like in linux by comand line Open comand line (Start->Run->CMD and follow this

c:\path\to\php\php.exe c:\path\to\mediawiki\folder\maintenance\update.php >> c:\update.log

If you have php addet in PATH just execute

php c:\path\to\mediawiki\folder\maintenance\update.php >> c:\update.log

-- User teamspeak Info 10:58, 9 August 2011 (UTC)Reply

User Privacy and Request to Access Everything

I managed to get this working on my site, I think. I can only test it with myself, but it seemed to work. The thing is that when I went to sign up using Facebook, I got the standard box saying that by clicking Agree, I was agreeing to give my wiki site all kinds of personal information, including my friends list and such.

The only reason I installed this Extension was to allow people to avoid having to create a user account on my wiki and having to register and remember yet another password. By just using their Facebook sign in, I thought more people would contribute. But the need for them to agree to giving up their privacy is going to cause a number of people to decline to use it. I don't want their private information and I don't know how I would get it from Facebook even if I did want it.

Is there any way to change this so the only thing they are agreeing to is what I want, which is allowing me to use this as Authentication. At https://developers.facebook.com/docs/guides/web/#login it shows the form. Users are asked to agree to "Access my basic information - Includes name, profile picture, gender, networks, user ID, list of friends, and any other information I've shared with everyone."

I'm sure Facebook considers all that "Basic Information" but it is far more then I need or should have. Is there any way to ask for less? Or do I have to talk to Facebook, which is an interesting idea to try to get them to increase user privacy...

Thanks. 24.40.138.185 07:04, 12 July 2011 (UTC)Reply

Yes, it's Facebook that put too much in the "Basic Information". You can't ask for less than that. You are not alone about this problem (people decline to use it) /MikaelLindmark 12:59, 28 July 2011 (UTC)Reply
Facebook's privacy controls have gotten much more granular since Open Graph was released. This means that back in the day, you could request a bunch of info with one user_info permission. Now, there's user_about_me, user_activities, user_birthday, user_education_history, user_events... you get the idea. The solution is to figure out which ones are needed (probably only email). When I update this extension to the new Open Graph beta (no promises) I'll fix this issue. --Gbruin
I have an update on the privacy permissions. I have re-written most of the extension to use Facebook's Open Graph Protocol. Privacy permissions are now limited to a select few. In the future, permissions will be selected dynamically based on the configuration parameters (like $wgEnableEmail and $wgFbUserRightsFromGroup). If you have any feedback on privacy controls and permissions, I am interested -- please let me know :) --Gbruin 00:18, 7 January 2012 (UTC)Reply

I am setting $wgFbUserRightsFromGroup=true in the LocalSettings.php, but still cannot access the Facebook groups the Facebook user belongs to ? I am trying to use membership to Facebook Groups to determine privilege level within my wiki, after authenticating with Facebook connect. Any thoughts ? I debugged by inspecting the FacebookUser::getGroupRights() but it seems that the following is true empty($wgFbUserRightsFromGroup).

Disabling Required Login

After enabling FB extension (since disabled) on my wiki it is now required to signup/login to view any page. I only wanted this extension to be up in the corner by the site login as an option for users to create an account using their FB account rather than going through the site sign up process just as another option for account creation for the end user.

Is there any parameters in LocalSettings (I presume) so that if I enable it, that users aren't blocked from all pages on the site and so they are not only given an account creation page before they can even look at anything?

Irt3hj4y 13:09, 21 July 2011 (UTC)Reply

I tested your site and it looks OK now. So I guess you fixed it? /MikaelLindmark 13:00, 28 July 2011 (UTC)Reply

?? No it doesn't work because it hasn't been enabled. I cannot leave something like this enabled when it doesn't work hence me asking is there a way to disable this. If I enable it, then every single visitor has to login/signup to view anything. I cannot essentially block the tens of thousands of visitors and make it mandatory for them to login.

Irt3hj4y 17:40, 30 July 2011 (UTC)Reply

Testing Facebook Connect Integration from a localhost WAMP

Here's what I've got:

Product          Version
-------------------------------
W-WinXP Pro      2002 SP3
A-Apache         2.2.6 (Win32) mod_ssl/2.2.6 OpenSSL/0.9.8g PHP/5.2.5
M-MySQL          5.0.45-community-nt-log
P-PHP            5.2.5 (apache2handler)
-------------------------------
MediaWiki        v1.17.0
Facebook Connect Version 3.0_r403, 2/5/2011)
-------------------------------

It's that simple... that clean...

I have a mediawiki site that uses Facebook Connect to authenticate users. This part works well. I have tried to implement the option of using a facebook group to assign user permissions based on a private, closed facebook group that I made, but this part isn't working.

My web-host that my live-wiki runs on does not provide me with shell access (so I get by with manual SQL updates using the phpmysql SQL tool to do updates since the MaintinenceShell extension doesn't work in 1.17 *frown* ) but I have been fairly successful in developing and debugging many issues using my home PC's localhost running the WAMP 2.0 package as found at: http://sourceforge.net/projects/webdeveloper/files/Web-Developer%20Server%20Suite/

Obviously the Facebook Connect Extension does not connect from the localhost clone as it would on the production server, but everything else works fine for debugging.

My two questions are:

  1. Could someone tell me if the "permissions-from-fbgroup" code from the Facebook Connect extention should still work even if the Facebook users can not be authenticated due to obvious mismatch in the fb app callback link on the local host version? (My guess is it should - I'd just like someone to tell me if I'm right)
    and...
    The facebook group permissions feature is not working on either my published site (where the facebook connect user integration IS working) or on my PC's localhost test WAMP server... so,
  2. How can I debug it on the localhost test WAMP?...

I've set "error_reporting=E_ALL&E_NOTICE&E_STRICT" in my PHP.INI file and I've made sure that display_errors = On shows the erros, but nada, nothing. The failure seems to be silent (i.e. with no reportable bugs in the php/apache logs either)

I know I'm referring to a valid group

When I visit the wiki User List page at "Special:ListUsers" is says,

bureaucrat and administrator privileges are automatically transfered 
from the officer and admin titles of the Facebook group .
For more info, please contact the group creator . 

?

in the past (mediawiki 1.16 for sure) I remember this page reporting the groups name, owner

bureaucrat and administrator privileges are automatically transfered 
from the officer and admin titles of the Facebook group <fbgroupname>.
For more info, please contact the group creator <fbgroupowner>. 

<fbgroup-logo>

so it seems clear to me that this is a good place to decide if the facebook groups code is working or not.

I am very eager to learn how to debug this.. please seomeone respond with either some recomendations on what to try or a recomendation on where else to ask for help.

as it is this is the only place I know of to ask.

Thanks in advance. --Rich

NOTE: I have confirmed that Facebook Connect "Group permissions" WILL WORK with a valid group even if the Facebook Connect authentication does not work because you are on a test server.

Explanation of a valid group:

  • This feature (FB group permissions) apparently used to work on all groups regardless of the status of the group. Now it seems that "Closed", and "SECRET" groups will not work with this extension's attempt to get the group data (like members, owner, logo, etc...) from the group unless the group is "OPEN".
  • The way I have found to test this is to use the group's ID with the Facebook 'graph' service and see if it returns the the group information or 'false'. If false, then you can not use this group for Mediawiki permissions...
  • Example: https://graph.facebook.com/1234567890/ where "1234567890" is a group number.

If I'm wrong, please let me know... otherwise I hope this note saves people all the troubleshooting and frustration that I went through... Good Luck!

PushEvent bug found

Hello, I'm currently implementing a wiki for someone who needs the wiki changes pushed to user's Facebook Wall so I've enabled the PushEvent functionality even though it states that it's currently incomplete. I found a bug which is that in FacebookPushEvent.php on line 169 it checks user preferences to see if it should call the PushClass's init method, but it was never getting called. I found that this was because the up_properties field of the user_properties database table is of type varbinary(32), so the "facebook-push-allow-OnArticleComment" name is getting truncated. --Nad 09:25, 4 October 2011 (UTC)Reply

The Reason why everyone's facebook connect isn't working: New Facebook API Issues

So my facebook connect no longer works on my site. In internet explorer I get the error message:

OAuth2 specification states that 'perms' should now be called 'scope'. Please update.

This is because facebook updated their API. I'm no developer and although I'm smart enough to figure it out... it would probably take me a REALLY long time. Hopefully some other developer can update perms to scope... a simple find and replace in all the extension files didn't work. Here's a stackoverflow page with some solutions that worked but I didn't know what they meant:

http://stackoverflow.com/questions/8505601/new-facebook-api-issue

All wikia pages are having this problem as well because they rely on the same facebook extension. Someone brave and knowledgable please help!


6 days ago Wikia updated their code concerning the bug: r46174. To backport this fix, change line 218 in facebook.js:
FB.login(fn, {perms : "publish_stream"});
to
FB.login(fn, {scope : "publish_stream"});
Hopefully this fixes things. --Gbruin 01:17, 22 December 2011 (UTC)Reply


I installed the latest version today and the line 218 of facebook.js doesn't contain any FB.login. Plus, FB-login can be found at line 117 and it has been commented out. The Facebook login button doesn't work and it's just a plain link to "#". Has this extension stopped working? I am using MediaWiki 1.17, just upgraded from 1.16 on which it didn't work. Too bad... --cleoni 16:38, 31 December 2011 (GMT)

I got this working using the latest Github version and MW1.16. --Tosfos 02:31, 5 January 2012 (UTC)Reply
Glad to hear it works. Make sure you stay up to date if you install a development branch! Expect a release in a few days when I finish testing 1.18. -Gbruin 06:24, 5 January 2012 (UTC)Reply
Thanks Gbruin, you're a lifesaver. 162.89.0.60 20:36, 5 January 2012 (UTC)Reply
I found the problem. Race condition due to MediaWiki's new ResourceLoader. Give the master branch a try on my Github page. If everything works I'll push out a new release. --Gbruin 00:35, 6 January 2012 (UTC)Reply
This is in regards to [cleoni 16:38, 31 December 2011 (GMT)]. I "fixed" the "#" but it caused more problems than it was worth. See 59793de for more info. --Gbruin 00:11, 7 January 2012 (UTC)Reply

Extension not working anymore?

I just loaded this today as the above users said, it seems to do nothing anymore. Has anyone gotten this to work from a clean install of the latest mediawiki?

I haven't played around with it too much - but no - I haven't been able to get it work on MW1.18 or MW1.19 test installations. --Varnent 23:55, 2 January 2012 (UTC)Reply
With the latest git pull it's now mostly working on MW1.19 - haven't tested on MW1.18 yet. I do have to manually rename the database files so they'll import properly. However, even after that I continue to get errors from update.php (swapping out correct prefix and domain with XYZ):
Database returned error "1050: Table 'XYZ_user_fbconnect' already exists (mysql.XYZ.org)"
Seems to keep trying to create the table even after it exists while the other existing tables don't error out.
Other than that - the actual extension itself is functioning again - thank you! --Varnent 11:51, 6 January 2012 (UTC)Reply
Thanks for reporting this error. LoadExtensionSchemaUpdates was updated in MW 1.17. I'll need to update the code for the changes. The other two tables, fbconnect_*, are not used currently. They have been removed from the upgrade process. --Gbruin 23:47, 6 January 2012 (UTC)Reply
Also, using the code on the extension page for a login button on the login page, it shows the row of faces, but no button or way to login via Facebook: http://screencast.com/t/onbozkOzg --Varnent 12:06, 6 January 2012 (UTC)Reply
Ultimately this is an error in the way Facebook transfers its cookies from the JS SDK to the PHP SDK. The cookies on the server lag the cookies on the client by 1 or more page views in some situations. I am looking into possible workarounds.
In the short term I need a new view for Special:Connect, similar to the OpenId extension. Currently I simply redirect to Special:UserLogin because I did not anticipate the above inconsistency of login states.
Try this: If you are redirected to Special:UserLogin even though you are already logged in to Facebook, manually type in the URL for Special:Connect and hit enter. The normal authentication process should then continue. Let me know if this isn't the case. --Gbruin 23:47, 6 January 2012 (UTC)Reply
Look forward to the updated schema code.  :) Here's what I wound up doing with the text on [[MediaWiki:Nologin]] to allow already logged into Facebook folks to have a way of connecting from the basic login screen:
Don't have an account? $1. You can also [[Special:Connect|log in with Facebook]].

<fb:login-button show-faces="true" width="450" max-rows="1" scope="email"></fb:login-button>
I got a better one for ya :) --Gbruin 21:28, 8 January 2012 (UTC)Reply
Don't have an account? $1. You can also <span class="mw-facebook-logo">[[Special:Connect|log in with Facebook]]</span>.

<fb:login-button show-faces="true" width="450" max-rows="1" scope="email"></fb:login-button>
Also, a redirect to a simple page that confirms you've logged in and then redirects you mainpage after 5/10 seconds would be great for when folks login from the login page rather than via the button in the upper-right. --Varnent 04:10, 7 January 2012 (UTC)Reply

What is the latest version that anyone has this working with? Should I try loading it with MW1.17? --Jtwing 00:07, 3 January 2012 (UTC)Reply

I updated the extension for MediaWiki 1.17+ and Facebook Open Graph. Someone should tell the web to stop evolving so fast. Anyways, feel free to test out the new version from my GitHub repository. If all is well, I'll push out a release in a few days or so. --Gbruin 00:37, 6 January 2012 (UTC)Reply
Looks good to me so far! Thanks for the quick turn around Garrett! --75.27.141.110 04:11, 6 January 2012 (UTC)Reply
This works for me. I did have to update my Facebook App ID/API Key. I guess Facebook changed the format of their App ID/API Key. You can find your App ID/API Key here: https://developers.facebook.com/apps. Click on your application and it should be under "summary." 66.25.161.17 17:20, 8 January 2012 (UTC)Reply

Most appropriate page header

Pondering what the best text to use for the Extension's page header is. Any idea if you plan on maintaining the github throughout the year - or continued plan of update the non-Wikia trunk about once a year. I don't feel strongly either way - just want to make sure we have a header that accurately credits your work. I feel awkward leaving the "abandoned" template message up as-is with all the great work going into it right now, but also don't want folks to have unfair expectations if you have a schedule in place.  :) --Varnent 03:58, 7 January 2012 (UTC)Reply

No schedule and no plans to work on it. I switched to GitHub two weeks ago so that it'd be easier for volunteers to adopt the project, but I got distracted and ended up rewriting 2/3 of the extension. (: I'll leave the notice up for now and if anyone decides to adopt the project I'm always around to answer any questions on GitHub. --Gbruin 01:43, 9 January 2012 (UTC)Reply
And I totally fail at the whole "not working on it" part. Check out the new feature (Special:Connect/Debug) I added two days ago (:

Numeric value required: value given: null TAAL[BLAME_file]

When i try to log in at Special:UserLogin with Facebook i get redirected to Facebook with following message: Numeric value required: value given: null TAAL[BLAME_file]

Any Ideas what this might be?


Ok i am srry i fixed it myself. i put in the wrong api key from facebook. it works now, thanks!

Getting Fatal error: Call to undefined method Title::isMainPage()

Hi I'm running git commit version cfb8fa38e0 on MW 1.17.2 and PHP 5.3.6. I'm getting the following error when I enable the extension:

/Parser.php on line 3470 Fatal error: Call to undefined method Title::isMainPage() in 
/var/www/wiki/extensions/Facebook/FacebookOpenGraph.php on line 274 

Any ideas? Thanks! --Mitchelln 11:23, 10 February 2012 (UTC)Reply

Sorry, incompatibility with MW 1.17. I fixed the problem, so upgrade the extension (or MW) to the latest version and you should be good to go. --Gbruin 13:31, 10 February 2012 (UTC)Reply
Great, thanks! I'll head over to github :)
--82.45.246.110 13:40, 10 February 2012 (UTC)Reply


Language not coherent with MediaWiki language

Hi, I'm running

Platform Version
MediaWiki 1.18.1
PHP 5.2.17
MySQL MySQL

My Mediawiki installation and language are both in Italian.

I installed the Facebook:extension, and I can enter the Wiki with Facebook account, edit pages, and so on.

PROBLEM: If I enter with a Facebook account where the language is different from Italian, as the main language used , the user will experience my Wiki in his/her own language.

QUESTION: How can I lock the language in my Wiki to Italian, regardless of the nationality of the facebook-visitor (who has logged-into my wiki with his/her NON-ITALIAN facebook-language)?

Thanks --84.93.179.226 12:55, 3 March 2012 (UTC)Reply

Try the steps mentioned here: Manual:$wgLanguageCode#Disable user selection of language. If that doesn't work, let me know and I'll modify my code to honor $wgHiddenPrefs[]. --Gbruin (talk) 14:21, 3 March 2012 (UTC)Reply
IT WORKED - Thanks--84.93.179.226 15:38, 3 March 2012 (UTC)Reply
Good to know. Less work on my part :) --Gbruin (talk) 00:47, 4 March 2012 (UTC)Reply

What shall I put as a namespace?

$wfFbNamespace = 'YOUR_NAMESPACE'; # Change this too its

What shall I put as a namespace. Facebook application name?

Regarding $wgFbNamespace:
When you use the new "Create New App" (literally step 1 of the setup instructions) Facebook will ask you to choose a namespace. There is plenty of information on Facebook about the namespace, but you don't necessarily need to know this. What's important is that you copy the namespace into $wgFbNamespace and let my extension "Do The Right Thing".
I understand there might be some confusion if the Facebook app was created a long time ago. In this case, you can find the namespace (or possibly create one) in the app's settings. --Gbruin (talk) 03:42, 9 March 2012 (UTC)Reply
OK, I have a better answer. Step one, let's figure out that database problem. Step two, when it works, visit Special:Connect/Debug on your wiki and the namespace problems will go away. --Gbruin (talk) 03:45, 9 March 2012 (UTC)Reply

Database return an error

I have set extension up, but I am receiving following error:

„FacebookDB::getFacebookIDs“. Database return an error „1054: Unknown column 'user_fbid' in 'field list' (localhost)“.

Now, I have mediawiki 1.17, I have wiki farm and each wiki has its own database with prefixes. I use 4.0-final (Feb 14, 2011) version of Facebok extension.

It is any other way to do it without using command line?

Pls advise

Do update.php script upgrade mediawiki to newer version also?

If I run update.php, do it upgrade of mediawiki also?

Nope. It is just for updating the database after you manually upgrade. MW 1.17 comes with a web updater -- you don't need to use update.php. See Manual:Upgrading for more information.
This extension requires a new table in the database. After installing it (and including Facebook.php in your LocalSettings.php file) run the updater (either update.php or, if MW >= 1.17, the web updater).
Hang tight buddy, I'll get to your other two questions above when I have more time:) --Gbruin (talk) 03:40, 9 March 2012 (UTC)Reply

SOLVED!!! - Extension not working after moving to CLOUDFLARE (CDN FREE SERVICE) - SOLVED!!!

Using Mediawiki 1.18.1.

I have just signed-up with a CDN (Cloudflare) service, trying to speed up my wiki. I never touched the Facebook extension, that was working fine before the move. I simply included lots of caching tricks in LocalSettings.php, plus, I might have cancelled 2 subfolders in the Cache folder, which, in hind sight, might have been related to Facebook extension.

PROBLEMS:

  1. The Facebook logo appears but it seems to go nowhere ("#")
  2. If I remove the require once (Facebook....); the wiki has a blank page, regardless of the skin. I had ?> at the end of LocalSettings.php...
  3. The Special:Connect/Debug page shows the following error message: An error occurred during verification with Facebook.

Any idea? --87.246.78.26 10:53, 12 March 2012 (UTC)Reply

SOLUTION:
The issue seemed to be related to the Cloudflare service (AUTOMINIFY and ROCKET LOADER are to blame).


CLOUDFLARE-SETTINGS attached. I found this as I was experiencing other issues with MODX manager page. And this post on the MODX forum helped me.

Issue closed. BUT SOLVED!!!

Glad it wasn't my extension -- less work for me :) Thanks for posting the solution, hopefully it helps someone out in the future. --Gbruin (talk) 22:29, 12 March 2012 (UTC)Reply
Well... I thought it was fixed. It worked for a bit, and now it is not working again. And I am not with Cloudflare any longer.
The Special:Connect/Debug page shows an error An error occurred during verification with Facebook.
No idea where to start tracking the problem down this time.... Thanks--87.112.67.196 17:16, 14 March 2012 (UTC)Reply
The verification test is failing. Check that 1) you're logged in to Facebook and 2) your Facebook account is connected to the MediaWiki username that you're logged in as. If you're getting that error message, it means that the extension is running that test and it's turning up false. --Gbruin (talk) 17:45, 14 March 2012 (UTC)Reply
Thanks. I have changed NAME SERVER back to my original Web-Hosting NS, since last time I could connect.
How do I connect FB account (I am guessing the one I use for the FB APP?) and the Administrator(?) of the Mediawiki site?--87.112.67.196 18:18, 14 March 2012 (UTC)Reply
Good question, set $wgFbAlwaysShowLogin to true.
I take it I should see AS IF I was connected to FB. But I don't. Hang on... I am having other issues with my wiki at the minute. ... which was related... of course. THE PROBLEM was related to StartProfiler.php, which I was testing for my caching tricks. With StartProfiler.php in the wiki root, Internet Explorer 6,7,8 do not load Mediawiki correctly (unlike Firefox, Chrome, Opera, which loaded it just fine). A....ND. Your FB extension becomes unusable in any browser.
BTW. Thank you, Garret. [Giuseppe]--87.112.67.196 23:35, 14 March 2012 (UTC)Reply

XFBML slow

Any time I load any XFBML content it loads extremely slowly. All the rest of the page loads in seconds, but any XFBML code takes over a min or two, if it loads at all. I'm not sure what the issue is. I'm not seeing anything in any of the logs. Is anyone else having this issue?

You can find debugging tools for most browsers. F12 in Chrome, Firebug for Firefox and IE has a debugging console extension as well. Try the page profiling features in these tools. Collect some more data, and if you're still having questions I recommend trying the Facebook developer forums (or Facebook stack overflow, or whatever tool they're using now). Regards, Garrett --Gbruin (talk) 03:02, 29 March 2012 (UTC)Reply

Getting Facebook Comments to be initiated by Like button - not only by starting commenting on wiki-page?

When I add a Like button and a Comments box to a new page, there are the following scenarios possible:

  1. a user Likes the page, it appears on his friends' News Feed, and when they - or he - comments, the comments only stay on FB, and are not synced to the wiki.
  2. a user Comments on the page, it appears in his friends' News Feed as a "user commented on...", and if the user's friends comment, the comments ARE synced to the wiki.

Is it possible to make it so that when a user Likes the post - the comments he receives are synced to the wiki page? After all, both plugins share the same href-tag value. I've checked the Open Graph for the webpage (on https://graph.facebook.com/comments/?ids=), and only the comments made in the Comments plugin are recorded - in other words, the comments made on a Like are not recorded, in spite of the href of the Like being the very same webpage. This is probably intentionally made by Facebook, and a workaround is perhaps not possible. But then - is it possible to use the Like button to initiate a Comments "object"? Is it possible to play around with the objects and get the Like button to work as Comments initator? Anybody know about this?

> Is it possible to make it so that when a user Likes the post - the comments he receives are synced to the wiki page?
Unfortunately no, and I'll explain why.
> Is it possible to use the Like button to initiate a Comments "object"?
By a comments object, do you mean an object in the Open Graph, or a comments tag in the current page?
The reason here is permissions. The Facebook application (your wiki) can't see the like or who comments on that like. Surprisingly, it even can't see the comments box -- your wiki creates a rectangle (iframe) and Facebook populates that rectangle with data. Your wiki has no way of seeing what's in the iframe.
It should be possible to program your way out of Facebook's walled garden
  • Read up on permissions
  • edge.create and comment.create tell your wiki when someone likes or comments on an article (but not who the user is)
  • If you have the user_likes permissions, it's theoretically possible to determine who just liked the article. To request the user_likes permission, add this to localsettings.php:
$wgHooks['FacebookPermissions'][] = 'needUserLikesHook';
function needUserLikesHook( &$scope ) {
    // Require an additional permission
    $scope[] = 'user_likes';
    return true;
}
Regards, Garrett --Gbruin (talk) 03:42, 29 March 2012 (UTC)Reply

An error occeured, please try again later

Hello,

it seems that I did install the extension successfully. But i cant connect. It is always saying An error occeured, please try again later.

edu.net.co

The million dollar question is: Did you try again later?? --Gbruin (talk) 03:09, 29 March 2012 (UTC)Reply
12 hours later: same effect, I dont think that facebook is so long down.
Sorry to poke fun. :) I've seen this error before when the Facebook app isn't set up correctly. Double-check your settings, and make sure that you copied the correct info into your config file.--Gbruin (talk) 11:55, 29 March 2012 (UTC)Reply

Extensions copies facebook data on every login

It seems like if I connect my wiki account with facebook then every time I log in with facebook connect the extension copies my name, my email, my username, and my language settings to my wiki's database and overwrites those fields. I can change these in the preferences but it will be only effective until the next time I press the "Login with facebook" link. When I create the account with facebook connect it asks what data should it copy from facebook to my wiki. That one works, except the next time I log in it will still copy everything it can regardless what I choose on the registration form. Any solution? ( mw 1.18.2, fbc 4.0 <-- both latest stable release )

I have identified the problem and pushed a fix to GitHub (version 4.0.3). If the problem still exists, let me know and I'll do some more digging. Thanks for reporting. --Gbruin (talk) 18:29, 9 April 2012 (UTC)Reply

Getting Blank Page half the time I try to load a page

My site: http://www.study-ib.com and its pages will open up blank more often than not. It started after installing the Facebook extension. Here is the MAIN_LOG from my host: http://pastebin.com/rt0St0DU Could anyone help in try to figure out what's happening here?

Facebook loads a second copy of the page in the background for their javascript to work (I believe this only happens on login). It is possible that this is interfering with normal operation. The fix, to remind myself later, would be to implement a light-weight channel file served from MW's ajax API, and then specify this channel file in the FB.init code.
I alternate between a 6 month and 12 month period for updating the extension (about the frequency of Facebook's new features and inconvenient deprecations). On my next update cycle I'll look into the benefits of a dedicated channel file. --Gbruin (talk) 16:26, 26 April 2012 (UTC)Reply

OpenGraph image problems

By turning on opengraph ($wgFbOpenGraph = true;) the extension adds the meta tag (meta property="og:image" content="WIKILOGO.EXT" /). However, when it is turned off and the LIKE button is clicked, Facebook picks up the MEDIAWIKI logo instead.

Is there any way I can explicitly declare a picture to be the default image? I don't want either the wiki logo or the mediawiki logo but a picture from within the content. How can this be specified?

You can set the default image by modifying line 506 of FacebookOpenGraph.php. One idea I had was to choose a picture from the page's content, but I wasn't able to finish this.
If you or another developer wants to add this feature, fork the GitHub repo and send me a pull request. The function to modify would be OpenGraphArticleObject::setDescriptionFromText() (have it set the description AND the image from the page's text). Alternatives would be a magic word or a new global configuration parameter (like $wgFbArticleImage). --Gbruin (talk) 10:47, 29 April 2012 (UTC)Reply
Thanks, I would love to help but this is well beyond my programming skills! For now as a very bad hack I've just commented out the line so that Facebook will choose an image at random; sometimes it's the logo but sometimes it's the main picture page.
Has anyone managed to figure out a code to take og:image from the page content? I've been trying to figure it out as it always takes the logo even though there are other images on the page. (I tried sending a pull request, but I'm not sure I did it right) (User talk:LTech)
Hi LTech, I imagine that getting og:image to work needs two parts - a function that parses the text for <img> links, and some code that calls the function. I did this as an example for how the second part should work. The first part would simply be to implement the new setImageFromText() function (setDescriptionFromText() is a good guide).
If you need help with git or adding the new function, feel free to email me at gbruin a/t ucla d0t edu. --Gbruin (talk) 22:26, 22 May 2012 (UTC)Reply
Thanks so much for the code. I'm stuck on the first part. Where do I find the code for the function setDescriptionFromText()? (User talk:LTech)

On my Wiki (v.1.18.3 / PHP 5.2.17 (cgi-fcgi) / MySQL 5.0.92-enterprise-gpl-log) ) I've implemented Facebook comments through Extension:PageNotice, using of course my App ID.
If I disable Extension:Facebook the Facebook comments' plugin doesn't work (it shows me only the source code); if Extension:Facebook is enabled, the Facebook comments' plugin works correctly BUT when I share a page from my Wiki no image is shown in Facebook preview. IN ADDITION, with Extension:Facebook enabled, I get this message when trying to debugging with Facebook debugging tool any page from my Wiki: Error parsing input URL, no data was scraped.. NEVERTHELESS PageTitle and PageDescription are correctly showed in Facebook preview, only image is trimmed out. Any idea to solve this situation? Thanks in advance. --Andrea Razza (talk) 22:37, 8 May 2012 (UTC)Reply

Ukrainian localisation

In order to add Ukrainian localisation, please, update the file Facebook.i18n.php with:

<already merged>

Kindly ask you to add this code to the upstream.

The newest version on GitHub includes your translation. I prefer GitHub pull requests but I'll always take code in any form. I'm having trouble with character encodings, so let me know if I've messed something up. Thanks for the translation! --Gbruin (talk) 22:09, 29 June 2012 (UTC)Reply

Facebook Open Graph and Facebook Timeline "edit" not coming up

i have muddled thru and got "discuses" and "tweek" to work but for some reason edits post as tweeks

not sure what debugging information i could provide but i will post anything you to help me figure this out (within reason ;))

Let's figure this out. If you remove tweak from $wgFbOpenGraphRegisteredActions, do the edits get posted as edits or not at all? --Gbruin (talk)

Redirect Loop to Special:UserLogin page

Not sure what I did wrong, but I'm getting an infinite redirect loop. When the user has already logged into facebook before, and they visit my wiki site, it redirects to the Special:UserLogin page and then keeps redirecting to that page.

Oh geez. Something simple. Had a space in front of the FbAppId number when I copied it over from the Facebook setup page. All is working well now!

Fatal error: Call to undefined method SkinMonoBook::getTitle() in /home/waihekep/public_html/extensions/Facebook/FacebookHooks.php on line 152

16th Aug 2012 Fatal error: Call to undefined method SkinMonoBook::getTitle() in /home/waihekep/public_html/extensions/Facebook/FacebookHooks.php on line 152

Wiki 1.15.4 with PHP's 5.3.10, 5.2.17 suhosin patch, 5.2.17, 5.1.6, and 5.0.5

Hi, we've tried two hosting platforms, PLESK and SiteGround, which very nicely lets us change PHP versions listed above.

Apart from various minor error reporting from php versions the effect of the call to getTitle() function define in a facebook php somewhere is crashing the server, http error 500 if we dont have debgging switched on.

By editing out the call getTitle() function the site will run, but hovering over "log in with facebok" in the special messages button shows sitename.org/Main_Page# which of course does nothing in the special connect.

We have removed other extensions to eliminate a collide and tried another service provider as per someone else's experiences on the Wiki Extensions facebook discussion page...further down this php it fails again on the same call... SkinMonoBook is unmodified and as far as I understand stock standard.....

Any ideas or suggestions would be apreciated....

1.15 isn't supported. getTitle() was added in r49662. Try changing the line to $skin->mTitle, and be prepared to encounter more compatibility issues. --Gbruin (talk) 20:13, 16 August 2012 (UTC)Reply

Combine with Social Profile Plugin?

Is there a 'relatively' simple way to configure this plugin to populate the fields provided in the social plugin, and to get it to retrieve the user avatar? Crazy Jake88 (talk) 02:29, 28 August 2012 (UTC)Reply

Everything is installed and operational with the exception of the FB login link at the top right, which consistently appears as a link to the same page as it is displayed upon (i.e. if on the Main Page, link is http://www.example.com/index.php/Main_Page# if on the Community Portal page the link is http://www.example.org/index.php/ExampleWiki:Community_portal# etc.). Obviously, this does not enhance the login process!

The Login / Create Account link is fine and resolves to the correct page, and the FB login from the Login / Create Account page works perfectly to log one in using the FB account.

One point which might (although probably not) be connected, but which may prove helpful to others (although it may not be correct, so please do correct it if wrong!!) is that I do not have shell access, so was unable to update the database using the command prompt. I instead attempted to use the Manual:Upgrading#Web_updater which did not appear to work as I kept getting an error message indicating that the user_fbconnect table did not exist in my database. I went into MySQL and manually created the table and as I could find no reference anywhere as to what fields there should be, gave it a field called user_fb The error message then returned a different missing field (user_fbid) followed after manual creation of that by a second missing field (user_id). Once those 2 additional fields were created, it all worked (with the exception of the top right login). I have no idea if those are the only required fields!! If someone has a better idea on that subject as well, I would appreciate input!

The database schema is here. Looks like you did a good job with that.
If you're familiar with jQuery, the button is modified when the page loads ($(document).ready(function()){}). It swaps the default action (going to #) with the correct one (logging in). There are two possibilities: the JavaScript event isn't being fired, or it can't find the login button. Check the JavaScript console for errors (F12 -> Console in Chrome, Ctrl+Shift+J or maybe Ctrl+Shift+K in Firefox). Check for the correct ID (Right click -> inspect element, on Firefox also click the three bars in the bottom left). The <a> tag should be surrounded by the tag <li id="pt-facebook">. A custom skin might change the <li> tag, so try loggin in using the default Vector skin.
If you solve the problem please post it for others :) If not, make sure you post your MW version, PHP version and my extension's version. Good luck! -Gbruin (talk) 16:12, 24 September 2012 (UTC)Reply

Thanks so much for getting back to me rapidly!

I'm not really what one would call a programmer, so there's a lot of blind stumbling around going on trying to figure this out! I checked the login element and it is indeed surrounded by <li id="pt-facebook">, so all appears well with that end of things. The more I play with this, the more illogical it is becoming (so of course, it's something simple somewhere!!). I went back over to the page I had open in Chrome to view the element as you instructed above, and while I had the inspection panel open, I clicked on the upper right FB sign-in link, and up popped the FB sign-in box! I refreshed the page, and did the same thing again - and no sign-in box!! It then crossed my mind that perhaps it might be related to AdBlock, so I went over to FireFox and fiddled with it there - "allowed" FB pages in the AdBlock page settings for the Wiki and then it worked OK - although if I log in using FB and then log back out, it will not allow a subsequent log back in without refreshing the page. Thinking that perhaps the issue was related to AdBlock, I headed back over to Chrome, and disabled AdBlock completely - no difference! I cleared caches, reloaded pages, bypassed caches, you name it, and no effect. Left it for a few hours, came back to the computer, clicked on the link and it worked! Refreshed the page, and it didn't work!! My hair is starting to get a little thin!!!

Is it possible that there's an issue at the FB end of things that's resulting in irregularity? I sort of doubt that, as it seems to be specifically related to the text login link - but at this point I ready to blame anything!! Additionally, although the FB image link login on Chrome is working OK, the text link "You can also log in with Facebook." in the "Login / create Account" page is not. If one clicks that, the page flickers, the image link disappears briefly, and then everything returns to the log in page (without logging in).

Is there perhaps a way for me to remove the text link logins? Can I do that in the Common.css page perhaps? I am incidentally using Vector with no modifications to the Vector skin other than what is in Common.css and Common.js

Here's my version information - and thanks for any help or suggestions!! :)

Product Version
MediaWiki 1.19.2
PHP 5.2.17 (cgi-fcgi)
MySQL 5.0.91-log
Facebook Open Graph for MediaWiki 4.0.4-stable, April 9, 2012

... a little further determination of the sequencing:

If I click on the upper right "Login with FB" on a regular page (such as the Main_Page), nothing - other than a hash mark being added to the URL - happens. If I click on the upper right "Login / create account" link, the Special:UserLogin page opens. If the center login screen shows the FB login logo, then clicking either that logo or the "Login with FB" text link at the upper right corner produces a popup login screen (although not the same one!). The "you can also login with Facebook" text link in the center - even though hyper linked - does nothign when clicked. If I refresh the page (without logging in), the central "Login with FB" logo disappears. The text goes straight from "you can also login with FB" to "You must have cookies enabled..." on the next line with no linear space in between. Clicking the upper right text login link in this state produces nothing. If I click the central "You can also login with Facebook" text link in this state, the lines spring apart and the FB Login logo appears. Once that log is present, clicking either that logo or the upper right corner text link produces the login popup screen.

This is in Chrome, and I have not logged in using FB in Chrome. Perhaps these characteristics are meant to be? I suspect probably not though...

Hopefully that might give you some clue as to what might be happening. Some sort of a script hiccup seems to be my thought at the moment (but as I say, I'm no programmer!!). Thanks!!

I wonder if it's a MW 1.19 issue. I've only tested with 1.16-1.18 on the most recent version. Short of downgrading and verifying a 1.19 incompatibility, in a few days I'll see if I can get a 1.19 test server running (no promises though). Have you tried the JavaScript development console yet? That might give us the answers we need. --Gbruin (talk) 23:17, 27 September 2012 (UTC)Reply
Confirmed working on 1.19. Check your JavaScript console error log. --Gbruin (talk) 00:37, 28 September 2012 (UTC)Reply

Sorry not to get back to you... have been tied up and will be for a few more days, but will keep working at it then, except... remember I said "I'm no programmer"? So please can you point me at some information about the Javascript console error log? :-) Thanks! 50.30.100.26 05:40, 29 September 2012 (UTC)Reply

Login with facebook by post method ( TODO: Set the "href" attribute of the login button to destUrl )

How can i fix this . The facebook with login is not working in IE Mobile. So i want to connect with post method how can i do this? any can fix this line // TODO: Set the "href" attribute of the login button to destUrl

it is in Facebook/modules/ext.facebook.js

Thanks in Advance --Rajaraman btech (talk) 12:03, 31 August 2013 (UTC)Reply

What is the $wgFbSecret ?

I figured out my app ID for the Facebook group that I want to link with, it was in the default URL for the page. So, what's the $wgFbSecret ? Is that my password or something else? Edit: Solved. I thought I could get a "secret" for a group, but it turns out that I had to create an app. Facebook let me create an app with the same namespace name as the already existing group, though, so it wasn't a problem. Banaticus (talk) 00:18, 29 September 2012 (UTC)Reply

Glad it worked out. Speaking of namespace, in config.php the namespace var had a typo. Make sure you correct this - I also updated the code on September 24, 2012. --Gbruin (talk) 00:36, 29 September 2012 (UTC)Reply
I haven't changed anything in config.php, at least if I didn't then I don't remember doing it. I just renamed it from config.default.php in case I wanted to edit config.php later. I set the namespace variable in LocalSettings.php. I clicked the "ZIP" button at https://github.com/garbear/facebook-mediawiki and downloaded the code today, so I should have any changes that you recently made. Banaticus (talk) 01:25, 29 September 2012 (UTC)Reply
You can access the JS console using F12 -> Console in Chrome, Ctrl+Shift+J or maybe Ctrl+Shift+K in Firefox. --Gbruin (talk) 05:44, 29 September 2012 (UTC)Reply

Can't use Special:Connect/Debug

I can't use Special:Connect/Debug -- when I try, it shows me the LogIn button and says, "In order to access this page, your MediaWiki account must be associated with a Facebook user. The Facebook user must be listed as a developer for the Facebook application." The first time I saw that, it brought up my personal Facebook login and I clicked yes, allow the app. I am the only developer for the Facebook application. Each time I view the page now, a popup windows shows for a bit, flashes through some text, then goes away and nothing else happens. Banaticus (talk) 00:21, 29 September 2012 (UTC)Reply

Read config.default.php closely. "To view this special page you must have admin rights on the wiki". Can you verify that your MW account has admin rights? Check out Help:Assigning_permissions. Let me know if this doesn't work. --Gbruin (talk) 00:40, 29 September 2012 (UTC)Reply
I created the wiki and am the only bureaucrat (there's another guy who's just an admin). I waited a while and there was a bit of text at the top asking me to confirm my information -- don't really know why it'd feel a need to do that, I don't want it to change any of my information anywhere. Perhaps there was a problem because my email address wasn't the same? I use one email on Facebook because it's "personal" and a different email address on the wiki because it's "business". After the one time that it asked me to confirm my information, it's back to flashing a screen up too quickly for me to read than saying that there was an error again. The wiki website is http://ship195.org/wiki/Main_Page if you'd like to take a look. I put in http://ship195.org/wiki/Special:Connect/Debug into https://developers.facebook.com/tools/debug and got the following warnings:

{| |Open Graph Warnings That Should Be Fixed

Inferred Property: The 'og:url' property should be explicitly provided, even if a value can be inferred from other tags. Inferred Property: The 'og:title' property should be explicitly provided, even if a value can be inferred from other tags. Inferred Property: The 'og:image' property should be explicitly provided, even if a value can be inferred from other tags. Tiny og:image: All the images referenced by og:image must be at least 200px in both dimensions. Please check all the images with tag og:image in the given url and ensure that it meets the minimum specification. |}
Banaticus (talk) 01:34, 29 September 2012 (UTC)Reply

OG warnings are toothless.
The first thing I notice is a JavaScript error on your site. Uncaught Error: JavaScript parse error: Parse error: Missing operand in file 'MediaWiki:Common.js' on line 1. Facebook relies pretty heavily on JavaScript, so that might be a concern. Common.js is a core MW file, so upgrading to MW 1.19.2 may or may not fix that (worth a shot). You can access the JS console using F12 -> Console in Chrome, Ctrl+Shift+J or maybe Ctrl+Shift+K in Firefox.
If upgrading doesn't work, then my next guess is that my extension can't see your app's roles. Try this: go to https://developers.facebook.com/tools/explorer/. The access token is APP_ID pipe APP_SECRET: 000000000000000|00000000000000000000000000000000. The GET url is APP_ID slash "roles": 000000000000000/roles. Make sure the "administrators" user ID is the one with an Admin account on the wiki.
In the mean time, I'll see if I can update the extension to be a little more verbose when Special:Connect/Debug fails. --Gbruin (talk) 01:59, 29 September 2012 (UTC)Reply
More verbosely, the error happens because my extension looks up your Facebook ID in your database and sees that it's not connected to a MediaWiki user. You say "bit of text at the top asking me to confirm my information", did you cancel, or uncheck all the boxes and click confirm? Confirming is probably the action that adds the relation to the database. Maybe clear all cookies, visit the site, and log in with Facebook. If you aren't logged in automatically as the administrator, then the relation doesn't exist in the database. --Gbruin (talk) 02:33, 29 September 2012 (UTC)Reply
I think the problem may have been that I copied in a space in front of the "secret" in LocalSettings. I opened that up as the quickest way to get my app ID and secret to check in the explorer page, and noticed that secret = ' numbers' which seemed like it would put a space in front of the secret. I went to Special:Connect/Debug, it brought up the "update information" thing, I clicked it, it took me to the main page, I went back to Special:Connect/Debug and then it gave several options. I think it's working now. Also, my Facebook user ID is indeed listed as an administrator on the developer explorer page. Thanks! :) Banaticus (talk) 14:51, 29 September 2012 (UTC)Reply
You're not the first! This guy had a space in his APP ID. What browser are you using? (Some of them, but not Google Chrome, ALWAYS add spaces to things you copy.) I'll add a note in config.default.php about this. If you need any more help with MediaWiki, let me know.
I made Life and was really active in Venturers in Ventura :) --Gbruin (talk) 22:22, 29 September 2012 (UTC)Reply

Help with the extension

Hi All, My name is Asaf Bareket, I have a wiki site for literature, and a Facebook page to support it. I've tried to use the Facebook extension to link between the two, but failed to do so. I think I have set the Facebook app just right, according to all the stages shown in the extension page and the config.default.php file in Github. then I went to Special:Connect/Debug for the configuration, but I got the line: No application information could be retrieved from Facebook Does anyone have any thoughts about what I have done wrong?

MediaWiki 1.18.1 PHP 5.4.0 (apache) MySQL 5.0.67-log facebook open graph for mediawiki 4.0.6 Thank you, Asaf Bareket

Working with Varnish Cache

Hi, I am not an expert so excuse this poor description. I installed the FB extension and it's great, but because it reads a Facebook cookie on every page request Varnish will not cache any pages, even for not-logged-in-users, which is a disaster for performance.

Is there a way in the extension to make it so that the cookie only works for logged-in users, or to disable that cookie in Varnish? Any help most appreciated. Sparkzilla (talk) 17:37, 27 November 2012 (UTC)Reply

auth_dialog_description

It appears auth_dialog_description has changed causing wiki/Special:Connect/Debug to display: No application information could be retrieved from Facebook.

If you comment out 'auth_dialog_description', // The description of an app that appears in the Auth Dialog (140)

It will work as a work around but not a fix

Aditaa (talk) 14:19, 7 March 2013 (UTC)Reply

I'll look into it schedule-depending, but I can't promise when. Thanks for the heads up! Gbruin (talk) 15:21, 7 March 2013 (UTC)Reply

$wgGroupPermissions

In first excuse me for my bad english ((

Your extension seems to work : users are created. O.K

But I would to use it with ArticleToCategory2 extension who needs in LocalSettings : $wgGroupPermissions['*']['ArticleToCategory2'] = true;

Facebook extension needs  : $wgGroupPermissions['fb-groupie'] = $wgGroupPermissions['user'];

....... A group has been created in Facebook and it's name is "Wiki"

Can I replace "fb-groupie" by "fb-Wiki"

If you have understand my question !!! Thanks for your answer.

FacebookLanguage.i18n.php wrong as BOM coded

I use the facebook extention together with the bluespice extentions suite and run into some problems with pictures. The guys from bluespice project figures out that the file FacebookLanguage.i18n.php is wrong as BOM coded (see Sourceforge bug Tracking bluespice (german).

Fixed in Comit:388b042. Thanks for reporting! --Gbruin (talk) 16:51, 19 May 2013 (UTC)Reply

no need to verify emails with facebook connect users bypass $wgGroupPermissions['emailconfirmed']['edit'] = true;

I have $wgGroupPermissions['emailconfirmed']['edit'] = true; set on my site. I want users who log in with facebook to be able to override the 'email confirm' and be able to straight away edit on the site? There's no need to verify emails with facebook connect users. How do I do this? Thanks --Tech (talk) 09:02, 9 June 2013 (UTC)Reply

Facebook requires users to verify their email address, so I decided that verifying with the wiki also was redundant. If the wiki is still asking users to verify, it's a bug in the extension :) I'll look into this --Gbruin (talk) 12:24, 9 June 2013 (UTC)Reply
Sorry, there is no bug, facebook users do not need to confirm their email address. --Tech (talk) 10:23, 15 July 2013 (UTC)Reply

How can i post articles on facebook timeline

Hi i am new to mediawiki,

I can login using this extension and how can i post articles / images on my facebook timeline by facebook extension please help me

Thanks

Did you read the extension page? Extension:Facebook#Facebook_Timeline

Hi thanks for your reply. I have created app page in facebook and it is in sandbox mode.To verify that this process is working i called special page " Special:Connect/Debug " and i am getting this message No application information could be retrieved from Facebook. .

When will the article will upload in facebook timeline after created or edit ?

Can you give any sites integrated with facebook extension.

Thanks

Now its working...

Special:Connect/Debug - Facebook Application Debugger - No application information could be retrieved from Facebook

I'm having a bit of an issue finalizing my configuration. Everything is working except Special:Connect/Debug. That gives me: Facebook Application Debugger - No application information could be retrieved from Facebook.

I've tested and am able to log in with the extension. I've tried the "auth_dialog_description" fix above, but I get the same error. Can I manually set the "Deauthorize Callback URL" while we figure out what is happening?

Thanks!

Session set failure

After enter Facebook username & password in the popup windows, click 'ok' in the 'merge account' form, the webpage is redirected to previous page, and the whole site show as un-login status. When go to Special:preference, it shows as "you need to login". Does anyone ever meet this issue and know how to solve this issue? Thanks!

Same problem: when a NEW account is created via the "Log in with Facebook" button, the account is created successfully, but the user is NOT logged in. Instead, the user needs to click AGAIN in "Log in with Facebook" to be logged in to the already created account. --Sophivorus (talk) 02:54, 25 September 2013 (UTC)Reply

Send Admin and email the first time a user logs in with facebook.

I would like to send an email to an admin when a user logs in with facebook for the first time. Is there a way to do this? Thanks --Tech (talk) 10:19, 15 July 2013 (UTC)Reply

Facebook needs the CURL PHP extension

Problems:

Special:Version:

MediaWiki 	1.16.0 (r78352)
PHP 	5.3.2-1ubuntu4.10 (apache2handler)
MySQL 	5.1.41-3ubuntu12.8


Unexpected non-MediaWiki exception encountered, of type "Exception"
exception 'Exception' with message 'Facebook needs the CURL PHP extension.' 

Igottheconch (talk) 08:28, 10 August 2013 (UTC)Reply

I don't think any of my code requires CURL, it looks like the Facebook SDK is trying to pull in that dependency.
You can try updating the Facebook SDK (https://github.com/facebook/facebook-php-sdk), but it looks like the most recent version (April 2013) also requires CURL [3].
Check the network page and look for forks that remove the CURL requirement. Assuming none do, you should fork the Facebook SDK and make CURL optional, then send me an email with a link to your fork and I'll include it in the extension.
Or, you know, install CURL.
And thanks for updating the extension page
Gbruin (talk) 05:44, 14 August 2013 (UTC)Reply
Looks like i would install this: Extension:WikiCurl
thank you gburin. Igottheconch (talk) 16:49, 20 August 2013 (UTC)Reply
Extension:WikiCurl did not work. Same problem. Igottheconch (talk) 04:18, 22 August 2013 (UTC)Reply

Found this on web:

How to add CURL to Linode Ubuntu Apr 26

Need to install a facebook login plugin. It said I should install curl.

1. Run winscp, a SFTP and FTP client.

2. navigate to: /etc/php5/apache2/php.ini (screenshot)

3. download the php.inifile

4. Add the following code to the downloaded php.ini file:

extension=curl.so

5. Re-upload the php.ini file

6. On winscp, click the putty button (screenshot). Login to putty.

7. apt-get install php5-curl

Error:
apt-get install php5-curl
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package php5-curl

8. service apache2 restart

Done

Igottheconch (talk) 04:26, 22 August 2013 (UTC)Reply

Well, I can't add curl unless I upgrade Ubuntu:
It doesn't appear php5-curl is available for Ubuntu 9.10. Additionally, Ubuntu 9.10 went end-of-life on April 30, 2011.
You could try and find another mirror that still has repos. (repository?)
Alternatively, this guide would help with the upgrade:
https://library.linode.com/upgrading/upgrade-to-ubuntu-12.04-precise
Igottheconch (talk) 18:34, 22 August 2013 (UTC)Reply
older version

Looking on archive.org I downloaded 2011 version of this extension Igottheconch (talk) 03:00, 27 August 2013 (UTC)Reply

Connecting an existing Wiki account with FB?

I have an existing wiki account, but I would like to connect my Facebook account to it. I can only see "Login/Create with Facebook" methods, which I will assume create a whole new wiki account during the process. I would like to add my Facebook login to my existing Wiki login account? Is that possible?

Special:Connect/Debug returning <facebook-error-needs-convert>

Hi.

I have version 4.0.6stable installed on MW 1.19.5. When I go to the Special:Connect/Debug page I see <facebook-error-needs-convert> I assume this means something is not working right. I following the installation guide. What does this error mean?

I'm also seeing Fatal error: Class 'SpecialPageFactory' not found in /var/www/webapps/iow/extensions/Facebook/SpecialConnect.php on line 90 error when calling Special:Connect&returnto=Around_Isle_of_Wight

Any idea what the problem is here?

Thanks! Mitchelln 15:38, 22 October 2013 (UTC)Reply

Return to "Facebook/Archive 1" page.