Authentication Hacks

My first talk was on User Authentication with MU in Existing Ecosystems, all about integrating WP with LDAP/AD/CAS and other directory authentication schemes, as well as the hacks I did to make that integration bi-directional and deliver new user features. My slides are online (.MOV / .PDF), and you can read earlier blog post summing up the project.

Plugins Mentioned

• wpCAS (long description)
• Alternate Contact Info
• WordPress Ticket Framework
• wpSMS (long description)

Scriblio

I was most excited, however, to talk about Scriblio, a plugin that turns WordPress into a library catalog with faceted searching and browsing. Those slides are online as well (.MOV / .PDF). The core plugin is in the repository, but I’d recommend people join the mail list if they’re thinking of diving in to it.

Scriblio Sites I Demoed

• Collingswood Public Library
• Colby-Sawyer College Archives
• Beyond Brown Paper photo archive

Matt demanded accent-aware spell checking for the WordPress spell checking plugin his company acquired earlier this year. And just a little more than a month later, After the Deadline delivered. Now Beyoncé, café, coöperate, and even my resumé look prettier.

Separately, Wordnik offers a new take on online dictionaries, and they just launched an API.

Plugin Development

Will Norris‘ talk at WordCamp PDX introduces WordPress coding standards, common functions, and constants to would be plugin developers (and smacks those who’ve already done it wrong). Also notable: functions, classes, variables, and constants in the WordPress trunk.

Custom Installations

Just as WordPress has a number of hooks and filters that plugins can use to modify and extend behavior, it also has a cool way to customize the installation process.

Extending The WYSIWYG Editor

TinyMCE, the WYSIWYG editor in WordPress has a rich API to allow adding buttons and stuff, but the docs are hard to get into. We can get a jump on that by looking at how it’s implemented in other WP plugins. This code creates the buttons, while the function that responds to the button click and does the work is defined within the plugin. The TinyMCE plugins in core are also informative.

The one way relationship between our user accounts and the MIS database also makes it difficult to engage with new users online. If you can’t get an account until you become a student, how do you allow potential students to apply online if all your systems are integrated with single sign-on? And if you can’t authenticate the online identity of your users, how do you set initial passwords into your system? Or allow them to reset a forgotten password online?

Internet companies never struggled with this issue, as their customers could only approach them online, but most universities built systems around paper applications and have fond (and relatively recent) memories of offering their students their first internet experience. It’s still not unusual for universities to offer their students their campus computing account with a default password based on supposedly secret data shared between the user and the school. But your SSN, birth date, and mother’s name are no longer secret. A proposed change in FERPA policy (see the the top of page 15586 in the NPRM) would have barred the use of “a common form user name (e.g., last name and first name initial) with date of birth or SSN, or a portion of the SSN, as an initial password to be changed upon first use of the system” in systems that store academic data. The final rule excluded that provision, much to the relief of those schools with more lobbying clout than brains.

Platform Choices

Rather than wait to see how the ruling played out last year, we went to work trying to improve security while easing access to our systems (no, that is not self-contradictory). Our challenges were thus:

• Fix initial password assignment
• Fix password resets
• Allow users with a loose or undefined relationship to the institution to create limited accounts for the purpose of interacting with the institution or its members

We considered a number of paths to a solution, including hacking of our university portal (which hosts the CAS single sign-on in our environment), expansion of a limited home-built solution, and a review of commercial and open source products and frameworks. We simplified the problem by confirming that the FERPA rule did not require us to authenticate the “real life” identity of a person; rather, we had only to validate the online identity of a person (saving us from needing to do things like send confirmation PINs by postal mail to a person’s home address).

In the end, we chose WordPress MU. Significant factors were our experience with the software (all the MIS developers use it personally), the extensibility of it as an application platform, the development focus on user experience (especially in recent versions), and our interest in using it as a framework for other user-facing services (especially BuddyPress).

Our Needs vs. WordPress

• The system must serve as the front end to our single sign-on environment, using our AD and LDAP password stores to authenticate users who have accounts in those systems.
• External email addresses, once verified with some challenge/response, can be used to reset a password.
• Users who are presently affiliated with the school have a school-provided email address, but no external address with which to reset their lost passwords.
• Users who are not presently affiliated with the school have no school-provided email address, and must verify their external email address before their account is activated. They can then set their own password once they verify their email address.
• The ability to send password reset codes via SMS would be nice (especially considering the number of long-time employees of the university who do not have personal email accounts), though that also requires the verification of the user’s cell phone number.

After reviewing what we wanted to do, we surveyed WordPress’ code to develop an implementation plan. And, because a number of aspects of our application process were changing, we decided to focus on allowing current users to self-reset their password and postpone development of account self-creation features for new users. Still, a few issues quickly emerged:

• WordPress requires a username be assigned to each user, rather than relying on email address (this is likely to change in WP 2.9) Creating a new username for our users is unacceptable, but adding a large number of new users to our existing username space will quickly deplete the “good” usernames. And changing a user’s username as their affiliation with the institution is unacceptable.
• The core user authentication function can be replaced with our own function. (And in 2.8 it became filterable)
• WordPress MU will validate email addresses, but the system isn’t built to be extensible.
• WordPress only stores one email address per user, but the user meta system can be used to store a second one. Unfortunately (and in a manner inconsistent with post meta), only one value per meta key per user is allowed, making it difficult to allow users to have an arbitrary number of email addresses associated with their account.
• The function that identifies a user by a given email address can be replaced with a function that also checks the secondary address.
• WordPress user profiles have no phone field, but the user meta system can be used to store one. A function to identify a user by a given phone number must also be created.
• Unlike some settings pages, the fields on the user profile editor cannot be changed simply by modifying the $wp_settings_fields array.
• Upon doing a password reset, the user is sent a temporary password, rather than being allowed to set a new password. This contradicts University policy about how passwords are used and communicated and could train users that sending passwords by mail is acceptable.
• The various functions in wp-login.php cannot be replaced, and in WP 2.7 the code had no way to add or replace various login actions (WP 2.8 changed that).
• WPMU-specific functions don’t always follow WP coding standards or models.

(Note that we began our work and deployed the system under WPMU 2.7. WPMU 2.8 included a few changes that made the process easier. I’m proud to say that some of those changes were a result of code we offered back to WP during our development.)

What We Did

• We decided that email addresses (both PSU addresses and external addresses), as well as PSU usernames would be acceptable identifiers for an account, and that a person should be able to log in to our web services using any of those identifiers. So…
• We replaced wp_autenticate() with our own function that accepts either email address or university username, checks to see if the user exists locally, checks to see if they exist in AD or LDAP, confirms their password, provisions their WordPress account (for university users who’ve not logged in via this method yet), establishes a session with our university portal and redirects them there (unless $redirect is set to something more specific that the dashboard).
• We decided to replace WordPress’ usernames with a random string matching a pattern we established. This became the WPID. Doing this required us to hide references to username (easy if you set a preferred display name)
• To store phone numbers and secondary email addresses, and allow users to edit those within their profile, I created the Alternate Contact Info plugin (browse source). This requires more use of output buffering than I’d like, but it gets the job done.
• To confirm email addresses and phone numbers via a challenge/response message (and support other interactions), I created the WordPress Ticket Framework plugin (my introduction, browse source).
• To send messages via SMS, we used my wpSMS plugin (in the plugin directory, browse source).
• Matther Batchelder re-skinned the login screen via a plugin that inserts our custom CSS.
• After determining that our university portal could not be made to authenticate via CAS, I gave up work on my wpCAS Server plugin and developed another method to initiate the portal session (which then establishes a CAS session using the portal’s CAS server).
• We replaced most of the functionality of the wp-login.php page (by hacking core at first, then taking advantage of the action hook in 2.8). In doing so we were able to change the password reset behavior to allow users to immediately change their password after entering their reset code (which was sent to their email address or phone via SMS).

Over time we extended the system to host multiple domains and replace our CMS. Soon we’ll consolidate our  public blogging instance into it, and we’re building an invite system that we can use to invite people to join our community.

What It Looks Like

The re-skinned WordPress login

Entering an email address or username to get a password reset code

SMS text with password reset code

Enter the password reset code from the SMS text message here, or follow the link from the email

Extended contact information in the WordPress profile

And that’s how we replaced our authentication system with WordPress, gained self-service password resets, and built the foundation to invite new users into our system.

• site.org/blogname1
• site.org/departments/blogname2
• site.org/departments/blogname3
• site.org/services/blogname3

The association between blog IDs and sub-directory paths is determined in wpmu-settings.php, but the code there knows nothing about nested paths. So a person planning to use WordPress MU as a CMS must either flatten his/her information architecture, or do some hacking.

Challenge: hacking WordPress MU to support arbitrary directory paths for each blog

As with my multi-domain hack, the following assumes that you’re using the vhost=no setting, that you have access to and know how to manipulate your MySQL, that you have control over your DNS and know how to use it, and that you know how to configure Apache or similar. You’d also be smart to turn off any object caching you may have running, at least until we’re done doing direct database manipulation. The following also assumes that your wp-config.php sets the DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE constants — if you’ve done a fresh install recently, it probably does, or you can check my domain mapping hack.

Hack The Path Mapping

Right at the top of wpmu-settings.php you can see how it strips all but the base of the URL path, but rather than mod that file, we can take advantage of an obscure MU hack: sunrise.php, which gets executed after some important WordPress components like the database class get loaded and before wpmu-settings.php.

To use sunrise.php, create a PHP file at /wp-content/sunrise.php and set define('SUNRISE', TRUE); in your wp-config.php.

Here’s the sunrise.php code I’m using:

if( defined( 'DOMAIN_CURRENT_SITE' ) && defined( 'PATH_CURRENT_SITE' ) ) {
	$current_site->id = (defined( 'SITE_ID_CURRENT_SITE' ) ? constant('SITE_ID_CURRENT_SITE') : 1);
	$current_site->domain = $domain = DOMAIN_CURRENT_SITE;
	$current_site->path  = $path = PATH_CURRENT_SITE;
	if( defined( 'BLOGID_CURRENT_SITE' ) )
		$current_site->blog_id = BLOGID_CURRENT_SITE;

	$url = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );

	$patharray = (array) explode( '/', trim( $url, '/' ));
	$blogsearch = '';
	if( count( $patharray )){
		foreach( $patharray as $pathpart ){
			$pathsearch .= '/'. $pathpart;
			$blogsearch .= $wpdb->prepare(" OR (domain = %s AND path = %s) ", $domain, $pathsearch .'/' );
		}
	}

	$current_blog = $wpdb->get_row( $wpdb->prepare("SELECT *, LENGTH( path ) as pathlen FROM $wpdb->blogs WHERE domain = %s AND path = '/'", $domain, $path) . $blogsearch .'ORDER BY pathlen DESC LIMIT 1');

	$blog_id = $current_blog->blog_id;
	$public  = $current_blog->public;
	$site_id = $current_blog->site_id;
	$current_site = sl_get_current_site_name( $current_site );
}

function sl_get_current_site_name( $current_site ) {
	global $wpdb;
	$current_site->site_name = wp_cache_get( $current_site->id . ':current_site_name', "site-options" );
	if ( !$current_site->site_name ) {
		$current_site->site_name = $wpdb->get_var( $wpdb->prepare( "SELECT meta_value FROM $wpdb->sitemeta WHERE site_id = %d AND meta_key = 'site_name'", $current_site->id ) );
		if( $current_site->site_name == null )
			$current_site->site_name = ucfirst( $current_site->domain );
		wp_cache_set( $current_site->id . ':current_site_name', $current_site->site_name, 'site-options');
	}
	return $current_site;
}

The first few lines of the code do pretty much the same as the start of the wpmu_current_site() function in wpmu-settings.php, but starting with line 8 it takes a big departure.

That’s where it splits the requested URL path like /path/to/blog/and/stuff/ into pieces and constructs an SQL query against the wp_blogs table to identify the correct blog to serve the request. The following example shows how:

SELECT *, LENGTH( path ) as pathlen
	 FROM wp_blogs
	 WHERE domain = 'domain.org' AND path = '/'"
	  	 OR (domain = 'domain.org' AND path = '/path/')
	 	 OR (domain = 'domain.org' AND path = '/path/to/')
	 	 OR (domain = 'domain.org' AND path = '/path/to/blog/')
	 	 OR (domain = 'domain.org' AND path = '/path/to/blog/and/')
	 	 OR (domain = 'domain.org' AND path = '/path/to/blog/and/stuff/')
	 ORDER BY pathlen DESC
	 LIMIT 1

Optimization note

Setting a maximum depth (and array_slice( $patharray, 0, $maxdepth )) would allow the query to be cached up to that depth. Otherwise, the query must be executed for every page load. The $maxdepth could either be set arbitrarily, or could be determined automatically based on the maximum path length of registered blogs.

Setting Up New Blogs

Once you’ve hacked the path mapping (and tested that it didn’t break your current site), you can add a new blog at a nested path.

Create a new blog in the MU blog admin.

Unfortunately, MU strips the slashes from the URL path you just tried to set.

The new blog you just tried to create, but with a very different path.

Fortunately, you can set the path correctly in the MU blog editor, and it won’t break the path when you save there.

Set the blog path in the MU blog editor, MU won't break it when you save it this time.

Once you create the new blog, try to load it in your browser. You’ll quickly notice the stylesheet is missing, though the blog works and functions properly.

Hack The .htaccess

WPMU uses the following .htaccess rewrite rule to properly direct requests for files on the real filesystem:

RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]

Obviously, that rule won’t work for deep paths, so I’ve replaced it with this rule:

RewriteRule  ^(.+)?/(wp-.*) /$2 [L]

And with that, you should be done.

WordPress MU is a solid CMS to support a large organization. Each individual blog has its own place in the organization’s URL scheme (www.site.org/blogname), and each blog can have its own administrators and other users. Groups of blogs in WPMU make up a “Site” and one or more Sites can be hosted with a single implementation. (I’m capitalizing Site for the same reason WordPress docs capitalize Page) Each Site has a defined set of administrators and options controlling various features. You might, for instance, lock down the plugins on your blogs.site.org, while keeping it open on your www.site.org. Or maybe you’d like to let your helpdesk staff create new blogs at blogs.site.org, but not at www.site.org. That’s what WPMU’s notion of Site can help you control.

Challenge: setting up service on multiple (sub-) domains

WordPress MU makes it easy to host both blogs.site.org and www.site.org within a single implementation, but there’s little documentation for how to do it.

Once you get WPMU up and running on one of your domains you can add another. The following assumes that you’re using the vhost=no setting (correct: I really mean vhost=no), that you have access to and know how to manipulate your MySQL, that you have control over your DNS and know how to use it, and that you know how to configure Apache or similar. You’d also be smart to turn off any object caching you may have running, at least until we’re done doing direct database manipulation.

Some might ask why I’m not simply using Donncha’s plugin, and the answer is simple: it only works for vhost=yes sites. For my own use, I find that sub-directories are easier for users to make sense of (go ahead, try to tell your mom to go to “myblog.sub.domain.org“).

Set up your web server

If you’re using Apache, you’ll either need to create an IP-based virtual host or manually configure your name-based virtual host for every (sub-)domain you plan to serve. Why: WordPress will handle the domain mapping for you, so it’s better to keep Apache out of the way and let WPMU own the entire IP.

Set up your DNS

Point each subdomain you plan to host in WordPress to your webserver. You can use a wildcard domain, but you don’t have to.

Create a new blog in WPMU

It doesn’t matter what you call it or what the path is, just create one. Now go edit it in the Site Admin:

Change the domain and path to match your new domain.

One quirk of WPMU is that it strips “www” from any domain name you enter (or is requested), so don’t bother trying to enter it (unless you’re willing to do some hacking to make it work). WPMU stores domain and path information in three locations: the wp_#_options table for the blog, the wp_blogs table, and the wp_sites table. When you edit a blog in the Site Admin, you’ll get a chance to edit the domain and path for both the wp_#_options and the wp_blogs tables. Clicking the helpful checkbox above will do most of that for you, but you’ll need to manually update the Upload Path.

Now make sure the new domain is shown in the blog's options as well.

You might be able to load the blog at the new URL as soon as you update those settings, but recent versions of WPMU set some constants in wp-config.php that can get in your way.

Reconfigure wp-config.php

Your wp-config.php might have something like this:

$base = '/';
define('DOMAIN_CURRENT_SITE', 'sub.site.org' );
define('PATH_CURRENT_SITE', '/' );
define('SITE_ID_CURRENT_SITE', 1);
define('BLOGID_CURRENT_SITE', '1' );

Those constants override the database checking that goes on in wpmu-settings.php to map the requested domain to a site. You have three choices: leave it as it is (and use only one “Site”), remove it and have WPMU do the mapping against the database, or expand the hard-coded mapping to include other sites.

I’ve used code like the following to do just that:

if( preg_match( '/(.+?\.)?([^\.]+?)\.site.org/i', 'www'. $_SERVER['SERVER_NAME'] , $matchedsubdomains ))
{
	switch( array_pop( $matchedsubdomains )){
		case 'connect':
			define('DOMAIN_CURRENT_SITE', 'blogs.site.org' );
			define('PATH_CURRENT_SITE', '/' );
			define('BLOGID_CURRENT_SITE', '1' );
			break;
		case 'www':
		default:
			define('DOMAIN_CURRENT_SITE', 'site.org' );
			define('PATH_CURRENT_SITE', '/' );
			define('BLOGID_CURRENT_SITE', '2' );
			break;
}
}
else
{
	define('DOMAIN_CURRENT_SITE', 'site.org' );
	define('PATH_CURRENT_SITE', '/' );
	define('BLOGID_CURRENT_SITE', '2' );
}

Set up your new Site

Once you have your new sub-domain working with one blog, you can create your new Site. Even if you don’t plan to create separate management policies for the different sites, it’s easier to create new blogs at each sub-domain if they each have their own Site.

Go in to your MySQL tool of choice and browse the wp_site table. There you’ll see just one row, but if you’ve made it this far you can also probably figure out how to create a new row representing the site at the new sub-domain. And once you do that, you can change the entry in the wp_blogs table to associate it with your new Site.

Set up the admins of the new site

Creating the new entry in wp_site doesn’t set the options for the new Site, and that means there are no Site administrators yet. Once again in your MySQL tool of choice, open up the wp_sitemeta table and look for an entry with meta_key = 'site_admins'. The meta_value for that entry is a serialized array containing WordPress usernames of the people who have site-wide administration privileges on the first Site. I’m assuming that if you have MySQL access you’re also a Site admin, so the easy thing to do is copy that row and change the site_id to match the auto-increment value from the new wp_site entry you made in the last step.

With the database manipulation done, you should now be able to go to the WP dashboard at your new Site, visit the WPMU admin options screen, and set the other options as necessary. You could decide to make one of your Sites open registration (remember, however, that users are shared across all Sites), while making other Sites more closed. And, obviously, you can delegate different Site admins for each Site.

Sub-domains or just different domains?

It’s worth noting that the instructions so far apply to both sub-domains and domains. You can use a single implementation of WPMU to manage content at both lolzors.org and tehsite.org. The detail about sub-domains really only applies to the next part. It’s also worth noting that you can support an arbitrary number of blogs, sites, and domains; I’m just using two sub-domains as an example.

Challenge: unified log in cookies

What’s the point of hosting multiple sub-domains with one WPMU implementation if you’ll need to log in separately at each one?

Set your cookie path

Setting a cookie path that that’s broad enough to cover the entire domain will solve this:

define('COOKIE_DOMAIN', 'site.org');
define('ADMIN_COOKIE_PATH', '/');
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');

Avoid conflicts with other WordPress installations at your domain

But having such a broad cookie domain can interfere with other WordPress implementations. You’ll have to solve that by setting a unique cookiehash:

define( 'COOKIEHASH', 'asdf_arbitrary_string' );

You’d do better to keep it shorter than that, though.

Challenge: unified log in location/URL

WordPress MU is happy to handle authentication requests wherever it hosts a blog, but some organizations prefer to funnel all authentication requests through a single location. The idea is to provide some protection against fishing (assuming users can ever be taught to look at URLs) and make it easer to integrate external applications.

Filter login_url and logout_url

Set the log in and log out path to whatever you want, just make sure the destination knows how to create (or destroy) the WordPress cookies.

$hack_base_domain = 'site.org';

function hack_login_url( $path ){
	global $hack_base_domain;

	return preg_replace( '/^.+?\/wp-login.php/' , 'https://login.'. $hack_base_domain .'/wp-login.php', $path );
}
add_filter( 'login_url' , 'hack_login_url' , 10 );
add_filter( 'logout_url' , 'hack_login_url' , 10 );

Filter allowed_redirect_hosts

WP will normally block redirects outside the web root of the active blog, so you’ll need to tell it about your other sub-domains.

function hack_allowed_redirect_hosts( $allowed_domains ){
	global $hack_base_domain;

	$allowed_domains[] = $hack_base_domain;
	$allowed_domains[] = 'www.'. $hack_base_domain;
	$allowed_domains[] = 'blogs.'. $hack_base_domain;

	return $allowed_domains;
}
add_filter( 'allowed_redirect_hosts' , 'hack_allowed_redirect_hosts' , 10 );

The description to David McNicol’s URL Cache Plugin raises more questions than it answers:

Given a URL, the url_cache() function will attempt to download the file it represents and return a URL pointing to this locally cached version.

Where did he plan to use it? Does he envision the cache as an archive, or for performance? Why hasn’t it been updated since 2005?

It caught my interest because I’ve long been interested in a solution to link rot in my blog. A real “perma-permalink” would be very useful.

The Hanzo Archives Wordpress plugin is something I’d be very excited to use. Ironically, it’s disappeared from the web (though the blog post hasn’t):

We’ve released a Wordpress Plugin which automatically archives anything you link to in your blog posts; it also adds a ‘perma-permalink’ for the archived version adjacent to each original link.

An Amazon Web Services case study put me on to Hanzo a while ago, and in May 2008 I actually spoke with Mark Middleton (the markm who posted the entry above). Mark revealed that community take-up on the plugin and other general purpose web archiving services was below expectations. The company has since refocused on legal matters (even their blog tag-line has changed to “web archiving for compliance and e-discovery”).

I wonder if, now that the number of people and companies that have been blogging for years has grown, there might be more of a market for such a service.

Lorelle is a big fan of Scott Reilly’s Customizable Post Listings:

Display Recent Posts, Recently Commented Posts, Recently Modified Posts, Random Posts, and other post, page, or draft listings using the post information of your choosing in an easily customizable manner. You can narrow post searches by specifying categories and/or authors, among other things.

In line with yesterday’s discovery of the Viddler WP plugin, Riffly Webcam Video Comments also supports video or audio comments within WordPress:

Riffly is a free service that easily plugs into your site allowing visitors to create video and audio comments.

The service is advertising supported. We cover all the costs for bandwidth, servers, and maintenance. Optionally, we also offer Premium Riffly accounts that provide you with additional benefits, such as advertising removal, control panel access, analytics, and much more.

The Viddler Wordpress plugin promises to “Enrich your site’s commenting experience by enabling video comments….” Users can record direcly from a web cam or choose a video they’ve previously uploaded to Viddler.com.

Viddler evangelist Colin Devroe has it on his site, where I can see it requires would-be commenters have a Viddler account. That last bit is too bad. I like Viddler, but I can’t force my readers to like it and get accounts as a prerequisite to commenting.

What is the current status of web servers…Is Apache 2.x “fast enough?”
Automattic uses Lightspeed (for PHP), nginx (for static content), and Apache (for media uploads). For WordPress-generated content, all server options are approximately the same speed.

What about APC?
Automattic uses beta versions of APC, and provides a 3-5x performance increase. It’s tied closely to the PHP version, so Automattic recently switched from PHP 4 to PHP 5.

Databases?
MySQL scales well and is easy enough to use that there’s little reason to consider other DBs for WordPress content. Other applications may have different needs. Note: FriendFeed uses MySQL to store schema-less data. Single-table key lookups in MySQL are faster than getting the data from Memcached.

Caching?
Automattic uses Batcache for full-page caching (.002 to .003 second), Memcached persistent object cache, very limited MySQL query cache (never larger than 256MB), sufficiently large key buffer.

HyperDB?
HyperDB solves DB scaling problems.

Backups
User-data backed up every hour, if something changed. Every blog backed up every 12 hours. Dedicated MySQL slaves do LVM snapshots for backups.

Why BuddyPress? “Build passionate users around a specific niche.”

Do you have to become a social network? “No, look at GigaOM Pro,” a recently launched subscription research site based on BuddyPress.

But, yo do get “BYOTOS: bring your own terms of service.” That is, you get to control content and interactions. And your service won’t be subject to the whims of a larger network like FaceBook (or vagaries of their service — think Ma.gnolia)

It’s pretty easy, Andy says, to create a custom BuddyPress component, and there are already a number at the BuddyPressDEV Community.

jQuery 1.3.2 is in WordPress 2.8, but the most exciting changes are in the automatic concatenation and compression of scripts via the script loader.

Andrew Ozz says “This feature can easily be extended to include scripts added by plugins and to use server side caching, however that would require some changes to the server settings (.htaccess on Apache).”

I have yet to figure out how to extend that feature to scripts in my plugins, but I’m working on it.

90% of WordPress blogs he sees are spam. But for those who aren’t spammers and want to do better in Google….

“WordPress automatically solves a ton of SEO issues…WordPress takes care of 80-90% of SEO.”

Still, he recommends a few extra plugins:

• Akismet — reduce spam comments
• Cookies for Comments — reduce spam comments
• FeedBurner FeedSmith
• WP Super Cache — improve performance

“We crawl roughly in order of PageRank…higher ranked sites get crawled faster and deeper.”

“What is PageRank? The number and importance of links pointing to you.” But “avoid BO (backlink obsession). You want to be relevant and reputable.”

Relevant is what you say on your page/site.

Reputable is what others say (link) about you.

Be relevant: Blog about what you love. Blog about what you’re really good at doing (or, I suppose, what you want to be really good at). Blog in your own voice. Write often, write every day.

Think about the keywords that users will type. Include them naturally in your posts

Avoid jargon mismatch. Be sure to include language that non-expert users may use to find information. Include relevant information for beginners on the front page. Try Google Keyword Tool to understand what people are searching for.

Recommends /%postname%/ permalinks. And use slightly different terms in the permalink and title. Other URL tips:

• Use categories that are also good keywords
• keywords in URL paths
  • dashes best
  • next best is underscores
  • no spaces is worst
• Should I change old URLs? No.

Ferris’s law: don’t do it if it’s not fun.

Gaining Reputation?

• Be interesting
• Update often
• Apply Katamari Philosophy — start small, build up, don’t over reach. Start in a niche, then “ambigining” that niche.

Build an audience:

• Provide a useful service
• Do original research or reporting
• Give great information
• Creative niche
• Write some code
• Live blogging
• Make lists
• Create controversy
• Meet folks on Twitter, Facebook, etc
• Make a video

Consider using:

• Google website optimizer (a/b testing)
• <!– google_ad_section_start –> and <!– google_ad_section_end –>

In your content:

• Identify and leverage “evergreen” content
• Show related content
• Avoid shortcuts and scams
• Avoid paid posts

Keep your WordPress updated! Don’t let spammers hack your site.

LifeHacker: productivity porn, read about it more than you do it

This plugin is the next step after my proposal for a common invite API. Here’s how I described it when requesting hosting at the plugin directory:

A common framework for registering tickets that will be acted upon later. Use it to manage challenge/response interactions to confirm email addresses, phone numbers, IM screen names, Twitter accounts, etc. Build an invite system around it, or use it as the foundation of a short URL system. It’s an extensible framework that takes cues from WordPress’ cron and admin Ajax functions.

Tickets are unique 1-32 character strings associated with actions and some stored data. Upon receiving a ticket, the matching action is executed with the stored data as an argument. After receiving the action, a plugin can destroy the ticket (as for challenge/response actions), or or leave the ticket in place for repeated use (like redirecting to longer post permalinks for a short URL resolver).

Here’s how it works:

Registering a ticket requires three things:

• The unique string that identifies the ticket
• A string representing the action that will be executed when the ticket is called
• Some data that will be passed to that action when the ticket is called

And here it is in action:

$ticket = $wptix->register_ticket( 'action_name_string', $wptix->generate_md5(), array( 'data' => 'val', 'more_data' => 'another_val' ));

To actually do anything with that ticket you’ll have to also register a function associated with the action name you gave when you registered it:

add_action( 'action_name_string', 'my_function_name' );

WP Ticket Framework registers a URL base in the form of http://site.net/do/any_ticket_string, so you can call a ticket simply by visiting that URL, or you can call tickets within your code. The following demonstrates one method of handling ticket inputs as part of a larger form submission.

if( ( $ticket = $wptix->is_ticket( $_POST['phone_confirmation'] )) && $ticket->arg['user_id'] == $current_user->ID ){
 $wptix->do_ticket( $_POST['phone_confirmation'] );
}else{
 $errors->add( 'user_phone', __( "<strong>ERROR</strong>: The confirmation code is invalid." ), array( 'form-field' => 'phone_confirmation' ) );
 return;
}

Caveats:

• Tickets don’t have any built in expiration mechanism. You can, however, include an expiration time in data saved in the ticket and act on that accordingly.
• Tickets don’t have any built in security mechanism. If only a certain user should be allowed to call a ticket, your code needs to be aware of that and enforce it.
• Tickets are deleted after being called, though you can suppress that by calling $wptix->clean_up_after( FALSE );.
• Tickets can only be queried by ticket string. If your application needs to keep track of open tickets for each user (as an example) it should also make a user meta entry about it.

There’s a hole in the wall at about head level next to my desk.

I’ve spent most of the day trying to track down a bug with some code I’ve been working on to add fields to a user’s profile in WordPress. The problem is that upon trying to save the profile I’d get an error like the following:

Catchable fatal error: Object of class stdClass could not be converted to string in /wp-includes/wp-db.php on line 472

Line 472 in my install is in the wpdb::escape() function. After poking around the wrong side of the problem, I finally broke down and rewrote the function along these lines:

function escape($string) {
 if( !is_object( $string ))
 return( $string );

 echo '<h2>'. $this->get_caller() .'</h2><pre>';
 print_r( $string );
 echo '</pre>';
 die();
}

That’s how I finally learned that wp_update_user() was at fault. I also opened a ticket for add_magic_quotes(), as both probably need independent fixes.

For now, however, I'm just converting the object to an array and avoiding the mess.

A few weeks ago I said I no longer needed the Wufoo embedding code that I’d put into bSuite. I was wrong. So I’ve taken another look, fixed the code from my old post, and coded it up into a stand-alone plugin. I’ve added installation and usage instructions to the bottom of the original post.

I’m a fan of Batcache, the Memcached-based WordPress full-page cache solution, but I’ve discovered that it ignores the content-type header set when the page is initially generated and re-sends all content with content-type: text/html. I posted a note about this at the WordPress support forums, but then I realized what the problem was: apache_response_headers() doesn’t return the content type, but headers_list() does.

The solution is to replace apache_response_headers() with headers_list() in the code, though headers_list() is PHP 5+ only, so it might be a while before we see a change like this committed. Still, I’ll shamelessly tag Andy Skelton (Batcache’s author) on it.

The BuddyPress forums have a number of threads about handling invitations (two worth looking at: one, two), but no real solution has emerged. At the same time, there’s also a need for some means of confirming other actions such as password resets, email changes (both of those are already handled by WPMU, I know), cell phone numbers to receive SMS messages, and other actions that need to be confirmed later.

So I’m proposing a generic API to handle things like this. The built-in WordPress cron and ajax functions seem to offer a clear pattern for creating such an API: Simply, plugins and core code could register an action and a function to be called when that action is executed. The API could also store data to be sent to that function when it is executed.

Among the things I’d do with this?

• Confirm email addresses
• Confirm cell phone numbers via text message
• Confirm IM accounts
• Confirm Twitter accounts
• Confirm password reset requests
• Confirm invitations in BuddyPress

Anybody else interested?

There’s a WordPress has-patch marathon going on now and I’m hoping one of my recent patches gets some attention. I’m hoping to fix the user meta functions to allow them to accept multiple values per key, per user.

It’s listed there among the other has-patch tickets in Trac, and there’s been some discussion in WP-Hackers. Why not take a look?

I tossed this together a while ago, and it even made it in to bSuite for a time, but I don’t have a need for it anymore, and I’m cleaning house.

function shortcode_wufoo( $arg ){
 // [wufoo id=z7x4m0 domain=place.wufoo.com]

 $arg = shortcode_atts( array(
 'id' => FALSE,
 'domain' => FALSE,
 'height' => 500,
 ), $arg );

 if( !$arg['id'] || !$arg['domain'] )
 return( FALSE );

 return( str_replace( array( '%%id%%','%%domain%%','%%height%%' ), array( $arg['id'], $arg['domain'], $arg['height'] ), '<iframe height="%%height%%" allowTransparency="true" frameborder="0" scrolling="no" style="width:100%; border:none" src="https://%%domain%%/embed/%%id%%/"><a href="http://%%domain%%/forms/%%id%%/">Fill out my Wufoo form!</a></iframe>' ));
}
add_shortcode( 'wufoo', 'shortcode_wufoo' );

Download the simple plugin here: wufoo_shortcode.php. Save it as wufoo_shortcode.php, upload it to your WordPress’ wp-content/plugins/ directory, then activate it.

To use it you’ll have to have a Wufoo account and forms. Then simple put in a shortcode like this [wufoo id=z7x4m0 domain=place.wufoo.com] in one of your posts or pages. The result will look like this.

I’m cleaning house in bSuite, and I’ve decided that this shortcode function for embedding Slideshare items in WordPress needs to go. Rather than totally toss it away, however, I’m posting it here in case somebody else finds it useful.

	function shortcode_slideshare( $arg ){
		// [slideshare id=211578&doc=misty-holland-1198496990903941-2&w=425]
 
		$arg = shortcode_atts( array(
			'id' => FALSE,
		), $arg );
 
		if( ! $arg['id'] )
			return( FALSE );
 
		return( str_replace( '%%id%%', $arg['id'], '
<div id="slideshare-%%id%%" class="embed slideshare"><object width="425" height="348" data="https://s3.amazonaws.com:443/slideshare/ssplayer.swf?id=%%id%%" type="application/x-shockwave-flash"><param name="wmode" value="transparent" /><param name="src" value="https://s3.amazonaws.com:443/slideshare/ssplayer.swf?id=%%id%%" /></object></div>
' ));
	}
 
	add_shortcode('slideshare', array(&amp;$this, 'shortcode_slideshare'));

This article comparing the usability of Joomla vs. WordPress has already been linked by everybody’s uncle, but it’s still worth a look.

I find it amusing, however, that none of the comments so far on that blog post mention the commitment that the core WordPress team appears to have on making blogging fun. If you start with the goal of making something fun, then add sophistication to make it flexible without being complex, you’ll get a very different result than you would if you started with different goals.

My slides for my presentation yesterday at code4lib are available both as a 2.7MB QuickTime and a 7.8 MB PDF, while the gist of talk went something like this:

Scriblio is an open source WordPress plugin that adds the ability to search, browse, and create structured data to the the popular blog/content management platform. And WordPress adds great ease of use, permalinks, comments/trackbacks/pingbacks, and other social and web-centric features to that structured data. But that’s not news. The news is that Scriblio now has an internal data model that supports much more sophisticated uses (slides 3 and 4). Whereas previous versions of Scriblio were mostly just display and social interaction interfaces to data that’s created or managed elsewhere, this new version supports soup to nuts creation and management of collections. Colby-Sawyer College’s archive (slide 5) is the first to implement this (take note of how the horizontal search layout makes the facets more visible and usable).

And that new data model also improves the usefulness of Scriblio to regular libraries (Collingswood (NJ) Public Library is shown on slide 6). Because Scriblio has an internal awareness of the metadata, it can automatically merge records from multiple sources (or multiple copies of the same record from the same source). The source of each piece of metadata in a record is identified and preserved (see the sourceid column in slides 7,8,9), allowing records to contain data from multiple sources (each with, perhaps, its own licensing terms). A practical example is enriching book records with data from LibraryThing’s Common Knowledge web service, making that data part of the index and facets in the local catalog, while also properly crediting the service when a record contains that data.

The automated merging of records enables a few new applications. Among them: the merging of an A to Z periodical list with the ILS’s inventory, or the creation of a union catalog from several systems. Slide 11 shows a prototype union catalog that shows materials (and their real-time availability) from three institutions in New Hampshire. Assembling that catalog was as easy as entering each ILS’s hostname and record number range in the harvester (slide 12).

I didn’t mention it during the presentation, but Scriblio is now built to work well in both regular WordPress as well as WordPress MU, the multi-user version of WordPress that allows a single installation to host many different sites (think WordPress.com) at a marginal cost to the hosting organization that approaches zero. The work to make Scriblio compatible with WordPress MU was supported in part by the National Endowment for the Humanities (there’s lots more to say about that project soon).