Will Facebook Connect Liberalize Data Retention Terms?

TechCrunch re-rumored the possibility of changes to Facebook Connect, including changes to FB’s data retention policy for developers, which (as the post points out) are a) onerous and b) unenforceable.

Facebook Connect’s current terms of service prevent any third-party applications from storing data obtained through the API for more than 24 hours. And what is available through the API? If you authorize a thrid-party application using FBC, then basically anything in your profile is available to that application or site, including things like your avatar, your friend network and lots of biographical data. Notably, your email address is not always directly available — developers only get access to a proxy unless you explicitly grant otherwise. In any case, all of this is cacheable for only 24 hours. After that you have to refresh the data from Facebook directly or delete it.

If this were to change, there would be much rejoicing among FB developers. Lots of effort is spent making sure that data is properly refreshed.   Many would also like to see default direct access to the person’s real email address.

It’s difficult to background-spoof a local account using unstable data (which is essentially what most Facebook Connect website integrations attempt to do) especially since a real email address is not always available, and moreover cannot be relied upon for more than 24 hours. This has caused many sites (see, for example Huffington Post Social News) to ask for additional information directly from the user (and sometimes a lot of it) at the time someone connects using FB, a requirement which vastly reduces FBC’s utility as a SSO technology, but allows the site to permanently retain that data, since it did not originate from FB.

So here, O Facebook, is my wish-list: a real email address by default, and the ability to permanently cache certain data as long as the user remains connected to my app. What else should be on my wish list?

Facebook Connect and Expression Engine: Two Options

It appears that EE developers now have two options when it comes to Facebook Connect. One is FabEE, developed by Purple Dogfish (UK). At Grist we’ve done quite a bit of tinkering around with this add-on and like aspects of it. (More on this in future posts I hope.) Just last week, however, Solspace released a beta version of their own Facebook Connect add-on. It looks quite promising, and with Solspace’s caché I’d expect that it turns out to be quite successful.  When it rains, it pours!

Here’s a basic feature comparison … but please check out each product for the details:

FabEE ($59.95):

- Provides SSO and linking of EE accounts with Facebook accounts.

- Batch-sends account info to Facebook application for quicker integration … hmmm.

- Possible to extend through custom plug-ins … this allows for the use of most or all of the available Facebook Connect API.

-  Implements a number of template tags, including some special conditionals.  Optionally includes JQuery 1.3.  Some examples of available tags:  {fabee:login_button}, {fabee:linked_profile_pic} etc ….

Solspace’s Facebook Connect Beta (also $59.95)

(Note:  I have not used this yet … just going off the Solspace docs:)

-  Three modes:  passive (provides SSO, and creates shell EE accounts in the background as necessary), a mode that requires EE accounts before sync and an intermediate mode where an abridged registration or sync is used.  This seems cool.

- also implements various template tags, including various facebook member data tags.  Could presumably be extended.

-  provides an account sync form tag to remove or add an account sync.

-  implements publishing items to facebook profiles.

It should be noted that both options require that your instance of EE be open to the world — ie not behind a firewall or other barrier — since Facebook will actually ping your site under certain conditions (such as if someone deauthorizes your application on Facebook.)  Also, both of these add-ons are subject to Facebook’s terms of service, which are a bit hard to understand, but include restrictions on caching data for more than 24 hours, and other restrictions, like 10 posts/account/day.

(This little post is in part due to a tidbit fed to me by the inimitable Natebot — thanks Nathan!)

Why I do not have an “iPad strategy”

Now that the iPad hysteria has calmed down somewhat … oh wait … has it?  At least in the circles in which I circulate, there has been much ado about whether or not we have an “iPad strategy”.  I’m taking this question to mean:  what do we have to do now to make our sites “iPad compatible”  … or something of that sort.

Is this just more hysteria?

No, according to many.  For example in an excellent post,  Martin Langeveld at Neiman Journalism Lab argues that the iPad’s impact will be disruptive on the scale of Facebook’s impact on online habits.  He says:

The iPad’s effects on how people use the web (and other media) will be similarly profound, and similarly unpredictable at the outset.

But most of Langeveld’s (and everyone’s) excitement really turns out to be about the commercial or cultural impact of the iPad, and not really it’s impact on web design and engineering.  Will the iPad kill newspapers?  Will it save them?  Will it change how people do everything online?  Maybe, maybe, and maybe … Apple has certainly built the iPad as an excellent web browsing device.  But from a web-builder’s POV, while I can vaguely imagine some design paradigms and practices that might come about because of the coming shift away from keyboard/mouse toward touch interfaces.  what I can’t really imagine that designers and developers will need to think about a vastly different set of best practices than those we are supposed to observe now.

However the web is consumed, application and site designers will still need to focus on the practices that produce positive, usable web experiences.  Standards and validation will probably be more important than ever.  Also, it remains to be seen how quickly, if at all, the iPad captures sufficient audience share for most sites to produce an iPad version, if that version even needs to be much different than the site in the first place.  And if it doesn’t, then it seems like the new technology will have a subtle, and not disruptive, effect on the way we design sites and interfaces.

So what’s my iPad strategy?  For now, it’s just to build a usable, humane website that does its job well.  I’ll stay tuned for the rest.

(Also, no flash.  Zing!)

Why I Love Drupal’s Caching API

So I was re-reading Jeff Eaton’s excellent article on Drupal’s method of caching.  I think they way the Drupal project has elected to handle caching is a model that other CMS’s, especially those that expect to be used for a a variety of purposes, could really learn from.  Briefly, caching refers to the temporary storage and reuse of data to increase the speed of an application or site.  It is most useful in situations where the cost of producing the data is relatively high, and where there is a relatively frequent need for the data.

Almost all CMS’s have a caching layer.  Expression Engine and WordPress (the two I work with daily) have theirs.  Here’s a summary:


  • Built-in caching behavior for both templates and template tags.  Available query caching.
  • One major DB caching module (Solspace morsels)
  • No caching abstraction or API


  • Caches objects and other stuff in mysql.  Minimally used by default.  Does not cache entire pages or parts of pages by default.
  • File caching can be enabled through a configuration change.
  • Various powerful plugins are avaialable that implement page caching.

Both of these approaches are reasonable, and work well enough to enable high traffic sites to run properly on these platforms.  They also don’t require you to think that hard while developing themes or templates for either WP or EE, since you can apply caching later.  but there is a certain lack of flexibility.  Essentially, there’s a default behavior, and you then rely on various configurations or plugins to improve that default behavior.  Let’s contrast that with Drupal:

Drupal has a caching API — a single set of functions for setting to, getting from and destroying cache that are then used across the entire CMS.  Two good things about this:  1.  you can think avtively about setting and getting cache in the normal course of developing modules and have an expectation of unified, predictable behavior whenever you invoke cache.  2.  the caching system is an API, abstracted from the details of what your application actually does, and you can change the behavior of all of your site’s caching by simply replacing the code that implements the cache.  For example, you could decide to do your caching using memcached, or through a DB, or using file based caching.  These three implementations are well known and immediately available (I think they even come with the standard Drupal 6 install.)  Says Jeff Eaton:

If you’re really hoping to squeeze the most out of your server, Drupal also supports the use of alternative caching systems. By changing a single line in your site’s settings.php file, you can point it to different implementations of the standard cache_set(), cache_get(), and cache_clear_all() functions. File-based caching, integration with the open source memcached project, and other approaches are all possible. As long as you’ve used the standard Drupal caching functions, your module’s code won’t have to be altered.

Don’t get me wrong — different caching behaviors are available in WP (and maybe even EE) as well, the problem is just that to fundamentally change cache behavior requires hacking.  Drupal intentionally throws open a world of caching choices by completely abstracting its main caching mechanism.

Dear Google, Thanks for Dissing IE6

Ben Parr at Mashable made my heart flutter the other day when he posted about Google’s announcement of the beginning of the end of IE6 support across their product suite.  Good timing for me, since it came on the very day that we here at Grist were scheduled to make a decision about IE6 support for a bunch of new designs and features that will be coming out over the next number of months.  So I feel validated Google — thanks … though I think based on our audience stats and the general way the wind is blowing, we would have made a similar decision in the end.  It seems that MSFT itself is intent on supporting IE6 until it stops supporting Windows XP, an event which won’t occur until 2014.  Most depressing job:  responsibility for this release path.

WordPress is a CMS

This is a really interesting video about wordpress-as-CMS. The line between blogging platforms and full-on CMS’s is getting blurred … ExpressionEngine, for example, has navigated the transition from its bloggy roots to its most recent incarnation as the only PHP-platform-built CMS.  Drupal powers various blogs.  And this guy is talking about how WordPress was chosen to power the dozens of sites associated with PBS station and content producer WNET.


Image: Leslie Camacho of Ellis Labs announces the upcoming release of EE 2.0.

I was lucky enough to attend EECI2009 in the Netherlands last week. Overall, the strongest EE/CI conference I’ve attended so far, which is perhaps a good sign for the growing community around these products. It was an interesting thing to have both EE and CI people in the same building. I hadn’t thought about it all that much, but these two communities are very different, and it was sort of amusing to see all of the EE people (designer-ish, stylish, expensive bags) mix with the CI people (nerdy, large brains, beer, blunt.)

There are also a growing number of EE developers who extend and modify that platform. Chief of this tribe is no doubt Solspace‘s Paul Burdick. He gave an excellent presentation on add-on development which clarified a number of issues about the future of this important activity for EE. Here, in PDF form, are the slides. Paul is responsible for a number of major add-ons, including the tag module. He is one of the original developers of EE itself, having been the main dev at Ellis Labs for quite a while. The other major emerging EE add-on developers were at the conference as well. These folks include Brandon Kelly and Leevi Graham. In true Australian form, Levy wore a outback-looking hat for the duration of the conference. (My apologies Leevi if it was in fact some other sort of hat.)

The big news at the conference was that EE 2.0, the new codeigniter-based version of the product will be released on December 1, 2009. There was much rejoicing when this long-delayed announcement was made. Now, after the rejoicing, I’m sure that there’s quite a bit of hand-wringing/scrambling going on across the community. Many people who rely on EE for their business (Grist included) are now trying to figure out if/when/how to integrate this new development into our work. Part of what I heard from the likes of Paul made this easier to think about — it’s now clear that a) EE1.6 will continue to be supported for quite a while yet and b) many important add-ons for EE may not be ready for EE2 any time very soon. So there’s certainly no pressure to upgrade, and plenty of reason to wait, play with the new product and see what happens. We also heard about a planned EE 2.1 release, which sounds like a more stable basis for an enterprise-upgrade.

EE Performance Guidelines from Paul Burdick at Solspace

Paul Burdick at Solspace has written a totally awesome document about EE Performance Guidelines. With his permission, I’m sharing it. Please contact Paul or Solspace directly for updates or a site evaluation.

While I’m on the subject, here’s the two add-ons currently in Solspace’s new performance suite. This includes Morsels — a new DB-based acceleration method, and Page Caching, a method to cache entire pages as flat files.