Extension:Facebook

This is the README file for the Facebook extension for MediaWiki software. The extension can only be installed by the administrator of a MediaWiki installation. Please note that this extension was developed by a third party and the Wikia development team.

The Facebook Platform enables you to make your wiki more social. With this extension installed, users can log in with their Facebook accounts and access other features enabled by this extension.

Follow this extension
Social networking is the very nature of this extension. I realize that most people who see the potential of this extension are probably members of social networking sites themselves. To better cater to their ADHD-riddled, seat-hanging cravings for nanosecond updates, I've set up several ways to interconnect with my anthropomorphized lines of code.

SourceForge
The primary repository for this extension is at http://sourceforge.net/projects/fbconnect4mw/.

GitHub
This extension also has a github page. I hope this makes it more accessible for developers looking to try out new things. Unfortunately, the GitHub repo is not synced with the primary one, so your best bet is still the old SourceForge page.

Twitter
This fully-automated feed was created as a convenience for those described above. http://twitter.com/fbconnect4mw

Connect account with Facebook
 This wiki is enabled with Facebook Connect, the next evolution of Facebook Platform. This means that when you are Connected, in addition to the normal benefits you see when logging in, you will be able to take advantage of some extra features...

Features

 * "Single Sign On" experience via Facebook Connect
 * On a successful Connect, allows the user to choose a nickname and creates a new account for that user on the wiki
 * Updates the wiki user's information from Facebook upon login (opt-out soon to come)
 * Logging out of Facebook logs you out of the wiki and vice versa
 * And more...

User Rights from Facebook Group
Instead of using the built-in special pages to manage user rights, this extension enables users to manage rights using a Facebook group. By simply creating a group and providing the group ID, Connected users will automatically be promoted to any of three implicit groups:
 * Group member: This right will be attached to people belonging to the Facebook group or "awaiting reply."
 * Group officer: Making someone an officer of the group will automatically give them Bureaucrat rights.
 * Group admin: Likewise, admins of the Facebook group will inherit Sysop rights on the wiki.

A fourth group is also provided: Facebook Connect user. All accounts created by Facebook Connect belong to this group.

On my personal wiki, I set $wgFbConnectOnly to true and $wgFbUserRightsFromGroup to a secret Facebook group. In LocalSettings.php, I put the following user rights code after including FBConnect.php. This allows only members of the secret Facebook group to read or edit the wiki.
 * Example

XFBML
XFBML in wiki text is enabled by default. Non-secure tags and attributes are excluded from the final page output. Due to a bug in MediaWiki, the facebook-logo attribute of  is also dropped from the final page output. Applying the patch posted to this bug report resolves this error. Hopefully the patch will be included in MediaWiki's code in the future.

If XFBML is enabled, then  maybe be used as an alternative for $wgAllowExternalImages with the added benefit that all photos are screened against Facebook's Code of Conduct and subject to dynamic privacy.

Tags that work

 * Activity Feed 
 * Comments 
 * Facepile 
 * Like Button 
 * Live Stream 
 * Login with Faces </fb:login-button>
 * Recommendations <fb:recommendations></fb:recommendations>

Tags that don't work
Works now for me! Just use <fb:like-box href="http://www.facebook.com/name">
 * Like Box <fb:like-box profile_id="185550966885"></fb:like-box>

No more annoying xd_receiver.php!
The new JavaScript SDK doesn't require a xd_receiver.php file for cross-domain (xd) communication. For those wondering how it accomplishes this magic, read on...

The new library circumvents the need for a xd_receiver.php file via a dynamically-constructed Flash object or the PostMessage feature of HTML5. Unfortunately, these two features are not available in every environment. In this case, a page is still required to implement Facebook's xd communication functions (like xd_receiver.php used to do). Their fall-back solution: they use the current page in an iframe (which, of course, links to the Connect functions), but with an extra hash (#) and special token. The technique is known as fragment.

The same Connect code on the reused page falls back into "xd_receiver" mode upon seeing the token in the fragment. It skips the initialization of the beefy Connect library and part of the document-rendering process (document.body.style.display = 'none';</tt>). Voila! The result: a perfectly functional xd_receiver.php, fabricated out of the current page by reusing the URL, trashing the DOM and only loading the necessary JS. Ingenious! ref1, ref2.

Wanted Features
OK, so the propaganda at the start of the article isn't all true (yet). Someday, the following events may be implemented:
 * Proxied Email instead of requiring users to enter an email

In Progress

 * Publish Feed story dialog when saving a wiki page (opt in or a PHP setting)
 * This might could get implemented, but I would feel a lot more assured if Facebook's development slows down. A month after I published this extension, Facebook killed off the "News Feed" itself and replaced it with the "Open Stream" (blog announcement), and then deprecated every single one of their feed story api calls. If someone can point me to an existing MW extension that does something similar, I might implement this, but otherwise I'll have to leave it to a more talented PHP programmer who wants to take on the risk. Gbruin 22:34, 28 March 2010 (UTC)
 * This feature just got cooler and more complicated to code: (January 2010 blog announcement, opens up the possibility of getting a non-proxied email address from the user).
 * Entire preferences tab overhaul (This may suck to code).
 * Bugfix checked in to the MediaWiki SVN. Progress can now be made on adding FBConnect preferences.

Configuration settings
This extension's default configuration settings are defined in config.default.php. These should be overridden in LocalSettings.php by putting new settings after the require_once line.

Sample configuration code for Localsettings.php
The developer of the extension uses the following code in Localsettings.php. The configuration initializes the extensions and restricts browsing and editing to members of a secret Facebook group.

Download
You are always better off with the most recent SVN release:
 * 1) Download SVN files via SourceForge tarball
 * 2) Browse the source code
 * 1) Browse the source code

Installation
First, like any extension, you will need to place the folder containing the PHP source files into the extensions folder of your MediaWiki installation. Make your wiki aware of the extension by including it in your Localsettings.php.

Database update
Your database will need to be updated to work with Facebook. This process will probably be made much simpler for MediaWiki 1.17, but until then the update must be done from the command line. It will only work with PHP 5. Some web servers still default to PHP 4, which you can check using the following command:

$ php --version PHP 5.2.15 (cli) (built: Dec 15 2010 14:09:31)

Assuming PHP 5, run MediaWiki's update script.

$ cd path/to/site/w/ $ php maintenance/update.php

Configuration
The file config.default.php contains the steps for creating a new Facebook application and different ways to customize your setup. You may edit config.default.php directly, but in order to preserve changes across updates it is recommended that you save the modified file as config.php. Alternatively, you may include your settings in Localsettings.php after the  statement above.

Upgrading
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. Updating from r100+ is safe and recommended. When updating from an older version, consider bumping $wgStyleVersion.