Some people have been forwarding me this email message that they received from Facebook:
The Simple Facebook Connect plugin has not used the FeatureLoader.js script since before version 1.0, which was released 5 months ago. Version 1.2 of SFC fully integrated OAuth 2.0 authentication, and it was released 5 weeks ago.
So if you’re getting this email from Facebook, upgrade SFC to the latest version. Problem solved.
Still getting emails about this one, so here’s a quick rundown on how to do it.
First, if you were already using a Fan Page, then you are not affected at all and don’t have to do anything. Please stop emailing me and asking for confirmation. Thanks.
Now, if you were using your Application’s Wall as your Page (like I was doing and even recommended), then Facebook is killing off the “Wall” of your Application. This is not a big deal, actually, and you can migrate your Fans to a new Page rather easily.
Step One: Create a new Page. Visit this page to do so. Note: You MUST select “Brand or Product”, and in the dropdown you MUST select “App”. This is not optional. You have to do this to migrate your Fans.
Also note that you must make the name of the Page EXACTLY THE SAME as the name of the application. This is important, don’t try to rename your stuff yet.
Step Two: After you’ve created the page, you’ll want to connect it to your site (using SFC, naturally). First, get the ID number of your new Page. You can find this in the URL of the “Edit Page” link on that Facebook Page. Once you have the ID number, put it into the “Facebook Fan Page” field on the SFC Settings screen and save. While you’re on this Edit Page link on Facebook, you can upload your logos, configure it, etc. Note: Do NOT select a new Vanity URL. The migration will migrate your old one if you had one.
Step Three: Configure SFC. If you’re using the Publisher, for example, you may have to click the grant permissions button again to have it get the new access token for the page. You may need to turn on auto-publishing to the page. Stuff like that. For the most part, SFC is pretty good at configuring itself for this, the Fan Box will automagically switch over, etc.
Step Four: Test. Make a new Post and see if it publishes to your Page. Try the Manual Publisher boxes. Verify that it’s working, basically. While you’re at it, you might go and manually publish some of your older posts to the Page, since the migration will not migrate the content on the wall.
Step Five: Migrate. Visit your application’s profile page. If you don’t see the box below, wait a day or two and it will eventually appear:
Use that migrate link and you’ll get a popup box allowing you to select a Page.
WARNING: If you get a popup that says “You don’t have any eligible Facebook Pages to migrate to”, then STOP RIGHT NOW. Do NOT click migrate. You only get one chance at this, if you mess it up then it’s broken forever.
If you have a Page, and it’s a “Brands or Products/App” page, and it has the EXACT same name as your Application, then you will be given a dropdown to select that Page. Otherwise, you’ll get the bad message. Click Cancel in such a case, fix your Page, and then try again. Only when you have the dropdown and have selected your page should you continue.
Step Six: Patience. Once you’ve selected your new Page and clicked Migrate (and remember, you only get one shot at this!), then after a while, a few things will happen:
a) Your Fans of the Application will slowly be migrated to be Fans of the new Page instead.
b) If you had a vanity URL on the Application Page and did not have one on the Fan Page, then the vanity URL will get migrated too.
c) Your Application Wall will disappear forever (this happens instantly) and any links to it will redirect to your Fan Page.
And that’s it. You’re done. Works fine with SFC. The next version of SFC will remove the publishing to Application Pages entirely, as well as the (now misleading) wording.
Facebook is getting rid of Application Profile Pages, and allowing people who are using them to transfer their subscribers to normal Fan Pages. SFC will be changing soon to adapt to this change, but the existing Fan Page support in SFC works fine and can be used right now.
I’ve tested out this migration process on one of my pages, and it works fine. Here’s what you have to do to make it work with SFC if you were not using a Fan Page already (note, if you were using a Fan Page already, then you’re done and must change nothing at all).
1. Create a new Fan Page in the Brands/Product -> App category.
2. Give it the same name as your App (exactly the same, mind you).
3. Set up the new fan page however you like. Take its ID number and put that into SFC, then use the Manual publisher to fill out the wall with some of the older posts (the wall content will NOT be migrated when you do the migration).
4. When you visit your app’s wall, you’ll get the migration message (eventually). You can use this to migrate all the people who have liked your application to having liked the new Fan Page. If you used a vanity URL, this will transfer also *if* you don’t put a vanity URL on the Fan Page.
After you’ve migrated the likes and changed SFC to be publishing to the Page, you can continue on as normal. Nothing else about SFC changes. Since Facebook will be eliminating App Profile Walls entirely in February, I’ll be removing support for them from SFC entirely before then. Expect that change to be in SFC 1.3.
I frequently get emails from users of SFC saying that their Like/Send buttons or Publish buttons are putting in weird content, or getting the wrong images, or things like that. Many presume it to be a bug in SFC itself or some kind of plugin incompatibility. Actually, it’s neither of those. You’re running into what I call the Facebook Cache.
See, Facebook does more than simply let you send things to their pages and so forth. More and more, they’re becoming a search engine. Facebook actually crawls the web, to some degree.
When you click a Facebook Like button, Facebook’s servers retrieve the webpage you’re viewing, and parse it for the OpenGraph meta tags. These tags tell Facebook what content to display for a link. The title, the image, maybe audio or video, etc. SFC does a pretty good job of automatically populating your entire website with these OpenGraph tags, invisibly (side note, Google+ will use these same tags, although they also have their own set of tags you can use too).
Generally, users who email me about this problem are just using SFC for the first time, and have previously had Like buttons on their page manually, or have been sharing their links on Facebook manually at some other point. This is where they run into the issue: Facebook caches the results of this crawl, usually for a long time. So when somebody clicks a Like button, it doesn’t have to pull the contents of the page if it’s already pulled those contents once before. So since SFC is now populating the OpenGraph meta tags, but FB is reading the cached version instead, the data doesn’t match up.
There’s a simple one-time fix for this problem. Facebook has made an OpenGraph debugger tool:
On this page, you’ll find a simple box asking for a URL. Put in the URL of the page having the problem, and the tool will go and force retrieve the content of the page and display the parsed OpenGraph meta tags.
Now, this is meant to be a debugging tool for people trying to add OpenGraph tags to their site, but it has a rather nice side-effect. When it forcibly retrieves the page, it also updates Facebook’s cached info for that URL. So all you have to do to make Facebook see your updated content is to take the problem URL, put it in there, and hit the Debug button. Now go back to the page, refresh it, and try the Like/Send button again. Voila, it’s magically fixed to show whatever the Debugger tool saw.
So if you’re having trouble getting some particular page to work in the way you’re expecting, try the debugger tool on the URL first.
Just a quick note to state this as a fact, in case anybody was wondering (and since I’ve had a few emails about it lately).
Under no circumstances will I ever implement Facebook’s “frictionless sharing” in Simple Facebook Connect. If you want such a thing, I recommend using another plugin.
Facebook’s frictionless sharing is a privacy invading, oversharing, useless-result creating nightmare. I block websites that use it from appearing in my News Feed, I remove Applications and services that implement it (hey Yahoo!, you’ve been axed from my life entirely because of your use of this crap), and I will not help anybody to implement it or even provide them with useful advice.
In my opinion, this is by far the worst thing Facebook has ever created. Even if you ignore the privacy implications entirely, Facebook has finally succeeded at doing something that they have been trying to do for ages: Make Facebook’s main feed almost completely worthless.
I will continue to add other features to SFC, but I use FB a lot less than I did before (and am now focusing more on Google+ anyway). However, this is one “feature” that I will not be adding.
Oh, and I’m not the only one who thinks this idea sucks rocks, BTW.
Facebook recently made a breaking change to the developer process, which makes it impossible for new applications to get the correct API keys. Since this essentially broke all previous versions of SFC, I went ahead and pushed the beta version public. It’s still unfinished, but Facebook didn’t really give me a lot of choice.
So, this is a quick walkthrough of some of the new features of SFC 1.0.
The upgrade process is slightly more involved for this one. It is recommended that you deactivate the old SFC plugins before upgrading. Why? Well, if you don’t, you’ll get a bunch of errors when visiting the Plugins screen later, saying that all the old SFC plugins either don’t exist or have an invalid header. These errors are normal, because of the next feature:
One plugin only
No more sub-plugins
Simple Facebook Connect is now a single plugin, with modular features. If you examine the plugins screen, you’ll find only one entry: Simple Facebook Connect.
The many-plugins-in-one was a useful experiment, IMO, and I still think it’s a better way to do things. But many people find it confusing, and some have disagreed with the notion. A lack of useful core support for plugin dependencies and user feedback convinced me to switch it up. So now, SFC is one plugin. But it’s still modular!
As you can see in the image, you can still turn on and off pieces of the plugin. Why have a piece running and consuming valuable resources if you’re not using it? Turning a module off completely disables it in the code. And the core of SFC itself is still written modularly, for maximum performance (since integrating Facebook itself is such a drag on performance for a site to begin with).
Support for new Facebook code
Over a year ago, Facebook stopped supporting the original Facebook Connect libraries. This was a major problem for sites, however the old code still worked. So as time went on, and the old Connect libraries started to degrade and become less and less useful, SFC was rewritten from the ground up to use all the newer supported libraries. Facebook’s JS SDK is used. FB’s Graph API is used. The old Facebook REST Platform code is completely gone, as are the older incompatible Facebook Connect libraries. OpenGraph meta tags (including embed info for images and video) are inserted into the entire site, completely automatically, allowing Facebook to see the content of your site and act accordingly.
Many of the plugins themselves have been rewritten fairly extensively as well, but with this comes some removal of older code.
Faux Share button settings
The Share button is gone. It was previously implemented using the older Connect libraries, but with the newer libraries from Facebook, it’s been completely removed. There was just no good way to retain it, Facebook has simply dropped any and all support for it. So, in it’s place (because it was so handy) is a modified Like button, which can still look sorta like the old Share button. The SFC module is still named Share, for ease of transition. The Like button itself is still around too, so you can use both Like and Share to get two Like buttons on the same post, perhaps for different placement.
The Bookmark widget is gone. It simply isn’t supported anymore, and didn’t work anyway.
The Find on Facebook widget is gone. This didn’t do really anything special to begin with, other than place the Find Us image into a widget, with a link to the Facebook Page. The image it once used is still included in the plugin, for people that want to do this themselves via a text widget.
The Connect widget is gone, but may make a return in the next version, as soon as some bugs are sorted out.
The Upcoming Events widget is gone. It rarely worked properly to begin with, and the newer XFBML libraries doesn’t have support for it anymore. A alternate approach to this may make it back into the next version.
All the remaining widgets have been combined into a single module for use on the widgets screen. In addition, most of them still have a way to access them directly, such as from a function call in a theme.
The Publisher has been simplified greatly. For one, auto-publishing now works even for Applications! The confusing permissions dialogs have been reduced to one. Colored indicators have been added, showing when the plugin has the necessary “tokens” from Facebook in order to be able to publish properly. The manual publishing functionality is still on the edit post screens too. And for those people using the auto-publish, a new system for pulling Facebook comments on their published posts back into the blog has been implemented.
For those who wanted it, Custom Post Type support has been added to the publisher as well. Any CPT marked as “public” gets shared like everything else.
The Register system has been completely rewritten to take advantage of Facebook’s new register plugin functionality. It can handle standalone registrations, or registrations using Facebook information. It even adds a Facebook created captcha to prevent spam registrations.
Login has been improved. One of the most common complaints was “What does ‘User not recognized’ mean?” This should be severely reduced now, since the Login module will auto-detect existing users and automatically connect their local WP accounts with their FB accounts, when they try to login. This follows Facebook’s own Registration Flow Models for connecting users to sites.
There’s a lot more too. I’ll be updating this post with new stuff soon!
Another new thing in SFC 1.0 is the new Login and Registration mechanism. The login mechanism in the older SFC worked, but it was slightly buggy and didn’t work very well. The new mechanism works quite well indeed.
Login screen with Facebook popup
For starters, it will auto-connect existing accounts to Facebook, based on matching email addresses. Just Login with your FB credentials, and if you’re using the same email in both sites, then it auto logs you in based on that. Your account gets automatically connected to your Facebook Profile, and this appears in the “Howdy” dropdown as well as on your Profile.
This may seem insecure to some, however the mechanism behind the scenes is that Facebook sets a cookie in your browser, and cryptographically signs it. Your Application Secret is the key used to decode this signature, thus proving it came from your Facebook application, and eliminating the risk of having users log in without your valid credentials.
However, this does point out something everybody should know: Secrets are supposed to be secret. So keep your Facebook Application Secret a real secret. This applies anytime you’re setting up interconnected web applications. Secrets are called that for a reason.
In order to integrate Login and Registration using Facebook, Facebook came up with what is essentially a flow diagram explaining the steps an app should use to login and register somebody to a third party site.
Facebook's rather complex registration flow diagram
This rather complex looking flowchart shows how a site which has its own login and registration mechanism can implenent Facebook. I’ve followed this chart as best as possible, and thanks to FB’s Registration plugin, it works quite well now. Here’s how it breaks down.
For existing users:
You click the Login button.
You login to Facebook if needed.
If your email on Facebook matches your email in WordPress, you’re logged in and your account is automatically connected.
If your email doesn’t match, then you can log in normally with WordPress instead, and connect your account manually, on the Users->Your Profile screen.
For new users:
You click the Login button.
You login to Facebook if needed.
If no account can be found for you from the login process, you get redirected to the Register page.
There the Facebook register plugin shows up and lets you register for the WordPress site, using your Facebook credentials. All it asks for is a username and to solve a CAPTCHA (to prevent spam registrations).
You get a new WordPress account, already connected to Facebook for you. It even emails you a password.
Some have expressed concern that Facebook seems required for registration. This is not actually the case, because after all, not everybody uses Facebook. One of the nice things about the FB Register plugin is that it has different methods for Facebook connected users vs. non-Facebook connected users. Both types of users can register for the site. Facebook users get some advantages like having their account automatically connected and not having to type in an email address, but the basic process is the same.
For new users not using Facebook:
You click the Register link.
The Facebook register plugin shows up and lets you register for the WordPress site. It will ask for a username and your email address, as per the normal registration process. It does have the CAPTCHA too, and tells you that you can login using Facebook as well, if you want.
You get a new WordPress account, and it emails you a password.
And after logging in and having it recognize you, the user will be automatically connected to their account on their Profile page.
Progress on the new SFC continues. Added a new plugin to it this morning: Photos. It’s a simple little plugin, and not pretty yet, but it does work.
Here’s a couple of example screenshots:
The selection screen (not pretty, but functional)
Example of the result
The plugin itself turns out actually to be quite simple. It turns out that adding to the media tabs is fairly straightforward with the existing WordPress functionality, and making links that insert things into the post code is not nearly as difficult as I thought it might be.
You can use the SFC beta version if you like. There’s a copy in the WordPress SVN directories. However, it’s buggy and unfinished and doesn’t have all the same functionality. But most of it works okay. Still needs polish before releasing it.
Note that all development on the old SFC 0.25 has ceased. I’m not making any further patches to it. If you want to upgrade now to the 0.999 beta version, feel free. Also, patches welcome.
One picture that sums it up for me is the Insights functionality Facebook can give you:
Facebook Insights Page for ottopress.com
That’s not for my app on Facebook, that’s for clicks on Like/Share buttons on this site, right here. You can drill down further and get clickthrough ratios, likes for individual pages, etc… Along with a whole bunch of other detailed information.
Because the “site” is separate from the “App”, I can get similar stats for likes on my Facebook Page (really an app) and such too.
BTW, if you’re using SFC and haven’t enabled this sort of thing, then it’s really easy to do. You can do the same thing without SFC, it’s just that SFC makes it easy for you by putting all the proper header codes into your page to make it work seamlessly.
Sorry for the several updates over the last day. Somebody pointed out that I hadn’t pushed a new version of SFC in several months, and that the fixes in trunk had gotten a ways ahead of those in the released version. Unfortunately, I didn’t actually go and test properly, so versions 0.22 and 0.23 had minor but critical bugs in them. Version 0.24 should push shortly with the fixes for those bugs as well as the enhancements over the last several months.
A short list of the changes/fixes:
Thanks to Burak Tuyan, the whole plugin is now more i18n capable, for people who want to translate it.
Added an sfc_img_exclude filter, to let others add their own image classes to exclude from the automatic image finder for share and publish and such.
The sfc_like_button() functions now supports a url parameter to add a like button to a specific URL.
A couple of patches by Jamie Zawinski: Publish now sends up to 1000 chars from the post to Facebook.
Also thanks to jwz, publish now gets images correctly in more cases.
If you enable login avatars (by uncommenting that code), it will show them for comments now too.
Eliminated deprecated calls to Facebook functions (xid and register users calls)
Custom Post Type support for automatic publishing (any CPT with public=>true will get auto-published).
Custom Post Type support for manual publishing (any CPT with public=>true will show the meta box in its edit screen).
Contextual help added to SFC Settings page.
Improved error messages
Numerous other minor optimizations and bugfixes
Version 1.0, which will ditch the old Connect code entirely, isn’t quite ready yet. The new registration stuff will be in there though, eventually. It will probably be after I get back from the core developers meeting though. Sorry for the excessive delay on that. I know lots of people want it, I never seem to have the time. I’ll try to find the time and finish it up soon. Really.
Note to users: If you got the “Breaking change: API deprecations” email from Facebook today, then you are probably using the SFC-Login plugin, or have at some point. Version 0.24 removes the code they are deprecating from the SFC-Login plugin. So upgrade and you’ll be fine. However, note that SFC is no longer compatible with WordPress versions prior to 3.0. Upgrade WordPress to 3.0 or later before upgrading SFC.
Note to international users: And with all that, there’s still a bug. If you’re seeing weird characters in your FB Published posts, edit the sfc-publish.php file. On line 179 you’ll find return utf8_encode($text);. Change it to return $text; to fix the problem with the double encoded characters. The next version will have this fix as well, but I didn’t think it was major enough to push a whole new version right away.