So, I hacked in a hard-coded link to Dashboard in bp-core-adminbar.php. This worked, but meant I had to remember to re-hack the file after running a BuddyPress update. I forgot to do that right after I ran the last upgrade, and got emails from users asking WTF?

I decided to figure out the best way to add in the Dashboard link without hacking the actual plugin files. Turns out, it’s drop-dead simple. Yay, WordPress.

In your /wp-content/plugins/ directory, create a file called bp-custom.php (if it’s not there already), and drop this code into it:

<?php
  // custom functions for tweaking BuddyPress
  function custom_adminbar_dashboard_button() {
 	// adds a "Dashboard" link to the BuddyPress admin bar if a user is logged in.
 	if (is_user_logged_in()) {
 		echo '<li><a href="/wp-admin/">Dashboard</a></li>';
 	}
   }
  add_action('bp_adminbar_menus', 'custom_adminbar_dashboard_button', 1);
 ?>

When in place, your BuddyPress adminbar will look something like this:

Yes, I know I should do something to properly detect user levels and privileges, rather than just providing the Dashboard link all willie-nillie to anyone that’s logged in, but the link itself just provides access to whatever Dashboard features the user is allowed to see, so there’s no security risk. Better to just say that a user can see the Dashboard for any site they’re logged into, and let WordPress deal with restricting access properly.

I should also deal with the possibility of WPMU being configured as a subdirectory vs. subdomain (the /wp-admin/ link will bork if you’re using subdirectories – better to use the real code to sniff out the base url of the current site…)

Apparently, the solution, of course, is to navigate in the Finder to /System/Library/CoreServices and click on Java WebStart.app – an entirely intuitive and obvious solution. This triggers some hidden magic to somehow restore access to JWS. Who knows. It works after doing this.

BuddyPress was acting up because it was creating tables in each blog’s database tableset. But MultiDB makes it easy to declare tables as belonging to a shared global database, so they don’t get recreated for each blog and are common across the entire service.

Thanks to a reminder by Andrew on the premium.wpmudev.org forum!

I edited my db-config.php file to declare the BuddyPress tables as being global, and copied the tables from the database where they had been collecting, into the global database.

// BuddyPress
add_global_table('bp_activity_sitewide');
add_global_table('bp_activity_user_activity');
add_global_table('bp_activity_user_activity_cached');
add_global_table('bp_friends');
add_global_table('bp_groups');
add_global_table('bp_groups_groupmeta');
add_global_table('bp_groups_members');
add_global_table('bp_groups_wire');
add_global_table('bp_messages_messages');
add_global_table('bp_messages_notices');
add_global_table('bp_messages_recipients');
add_global_table('bp_messages_threads');
add_global_table('bp_notifications');
add_global_table('bp_user_blogs');
add_global_table('bp_user_blogs_blogmeta');
add_global_table('bp_user_blogs_comments');
add_global_table('bp_user_blogs_posts');
add_global_table('bp_xprofile_data');
add_global_table('bp_xprofile_fields');
add_global_table('bp_xprofile_groups');
add_global_table('bp_xprofile_wire');

It seems to be working fine. I’ll do some more testing, but it’s looking promising. If it’s really working, I’ll be spending some time to BuddyPress-enable the main theme for the WPMU service, and roll it out properly.

The premise is this – I created a Page called, creatively enough, “Winter 2009″ – and each of the groups is to create a page (or set of pages) and add them to the site – and selecting “Winter 2009″ as the parent page for the main page of their presentation. They are free to create as many other pages as they like, and can set those to use their first page as the parent, thereby generating a table of contents.

Works great. Except that the WP-Sentry plugin hijacks the “Private” state of pages, and the tree of Pages available in the Parent selector is based on “Published” pages.

Conflict. Confusion. Frustration.

The students could either collaborate on the pages, or organize them in the tree structure.

Of course they could create the pages and add them to the tree structure and THEN enable the WP-Sentry-managed group editing controls, but YOU try explaining that process to 250 undergrads, all stressed out about building web pages as part of a geology course.

So… I dug into the code to see what was yanking “Private” pages from the Parent list. Turns out, it’s in wp-includes/post.php, waaaay down on line 2618 (as of WPMU 2.7). All I did was remove the " AND post_status = 'publish'" bit, and it now appears to be listing all pages.

I’m quite sure I borked something else, but for now I’m leaving the Parent list wide open until the students are done publishing their presentations.

Update: Unintended consequence #242: Looks like with the tweak, Private pages show up where they’re not expected. I’m disabling the tweak for now until I can find a better way (if that’s even possible).

While reading the documentation, I was rather confused by the term “global” – which appeared to be used in slightly different ways. Eventually, I plugged through, and got it working. The key is to test it all on a local copy of the database before running the migration script on the production server. Thankfully, the script doesn’t delete anything, so I was confident that if anything borked I could just back out the multi-db files and revert to single database config without losing anything.

“Global Tables” are tables that will be stored in a shared, common database rather than in each blog’s database in one of the 16 databases used by the multi-db code. These are things that are accessed by all blogs on the WPMU install, and include administrative stuff.

In the db-config-sample-16.php file that ships with multi-db, it also mentions “global-db”, “globaluser”, and “globalpassword” – those are just the database server address, username, and password to use when connecting to the “Global” database containing the “global tables”. They used “global-” in these parameters because it’s possible to configure each of the 17 databases to use different database servers, different usernames, and different passwords. For simplicity, I used the same database server and account for all 17 databases.

My db-config.php file was edited as follows:

<?php
//	Plugin Name: Multi-DB
//	Plugin URI: http://premium.wpmudev.org/project/Multiple-Databases
//	Author: Andrew Billits (Incsub)
//  Version: 2.7.0
//------------------------------------------------------------------------//
//---DB Scaling-----------------------------------------------------------//
//------------------------------------------------------------------------//
//	16,256,4096
define ('DB_SCALING', '16'); // use 16 databases for the blogs
//------------------------------------------------------------------------//
//---DC IPs---------------------------------------------------------------//
//------------------------------------------------------------------------//
//	Usage: add_dc_ip(IP, DC)
//	EX: add_dc_ip('123.123.123.', 'dc1');
add_dc_ip('127.0.0.1', 'dc1'); // DN: change this to the IP address of your WEB SERVER
//------------------------------------------------------------------------//
//---Global Tables--------------------------------------------------------//
//------------------------------------------------------------------------//
//	Do not include default global tables
//	Leave off base prefix (eg: wp_)
//
//	Usage: add_global_table(TABLE_NAME)
//	EX: add_global_table('something');
// DN: These are tables that will be stored in the global database configured below (wpmu_global)
//     rather than in the 16 blog databases.
add_global_table('mass_mailer');
add_global_table('registration_log');
add_global_table('reports_comment_activity');
add_global_table('reports_post_activity');
add_global_table('reports_user_activity');
add_global_table('signups');
add_global_table('support_faq');
add_global_table('support_faq_cats');
add_global_table('support_tickets');
add_global_table('support_tickets_cats');
add_global_table('support_tickets_messages');
add_global_table('domain_mapping');
add_global_table('comment_activity');
add_global_table('blog_activity');
add_global_table('user_activity');
add_global_table('post_activity');

//------------------------------------------------------------------------//
//---DB Servers-----------------------------------------------------------//
//------------------------------------------------------------------------//
//	Database servers grouped by dataset.
//	R can be 0 (no reads) or a positive integer indicating the order
//	in which to attempt communication (all locals, then all remotes)
//
//	Usage: add_db_server(DS, DC, READ, WRITE, HOST, LAN_HOST, NAME, USER, PASS)
//	EX: add_db_server('global', 'dc1', 1, 1,'global.mysql.example.com:3509','global.mysql.example.lan:3509', 'global-db', 'globaluser',  'globalpassword');
// DN: NOTE: change 'dbserver.com' to the address of the mysql server,
//   'username' to your mysql username,
//   'password' to the appropriate password.

add_db_server('global', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_global', 'username', 'password');
add_db_server('0', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_0', 'username', 'password');
add_db_server('1', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_1', 'username', 'password');
add_db_server('2', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_2', 'username', 'password');
add_db_server('3', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_3', 'username', 'password');
add_db_server('4', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_4', 'username', 'password');
add_db_server('5', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_5', 'username', 'password');
add_db_server('6', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_6', 'username', 'password');
add_db_server('7', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_7', 'username', 'password');
add_db_server('8', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_8', 'username', 'password');
add_db_server('9', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_9', 'username', 'password');
add_db_server('a', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_a', 'username', 'password');
add_db_server('b', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_b', 'username', 'password');
add_db_server('c', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_c', 'username', 'password');
add_db_server('d', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_d', 'username', 'password');
add_db_server('e', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_e', 'username', 'password');
add_db_server('f', 'dc1', 1, 1, 'dbserver.com', 'dbserver.com', 'wpmu_f', 'username', 'password');

//
//	Note: you can also place this section in a file called db-list.php in wp-content
//  EX: add_db_server('global', 'dc1', 1, 1,'global.mysql.example.com:3509','global.mysql.example.lan:3509', 'global-db', 'globaluser',  'globalpassword');
//------------------------------------------------------------------------//
//---VIP Blogs------------------------------------------------------------//
//------------------------------------------------------------------------//
//	Usage: add_vip_blog(BLOG_ID, DS)
//	EX: add_vip_blog(1, 'vip1');
// DN: I didn't add any VIP blogs.
?>

To create the databases, I used the script at http://db-tools.wpmudev.org/db.php and it generated the code below, which I ran on the MySQL server to create the databases:

CREATE DATABASE `wpmu_global` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_0` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_1` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_2` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_3` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_4` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_5` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_6` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_7` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_8` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_9` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_a` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_b` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_c` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_d` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_e` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `wpmu_f` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

After copying the db.php and db-config.php files into place as per Jim’s instructions, it all Just Worked™. New content was being stored in the 16 blog databases, and sites were behaving as expected, but with slightly less table explosion bloat as before.

One thing that makes me a little nervous is that the multi-db code isn’t core to WordPress, and is part of the premium.wpmudev.org subscription. This means that it can break in the future – there is no obligation for WordPress to continue to work with it, and if for some reason premium.wpmudev.org decides to abandon the plugin or stop updating it, I’m locked into WordPress 2.7. Neither of these made me lose too much sleep. Worst case scenario, I can always recombine the tables from all 17 databases back into a single überdatabase, assuming we haven’t outgrown the physical limits of a single MySQL database by then.

rsync -rtlzv --ignore-errors -e ssh . username@hostname:/path/to/directory

What that basically says is, “run rsync, and tell it to recursively copy all directories, preserving file creation and modification times, maintaining proper symlinks (for aliases and stuff like that), compress the files as they’re being copied in order to save bandwidth, and provide verbose updates as you’re doing it. Use SSH as the protocol, to securely transfer stuff from the current directory to the server ‘hostname‘ using the username ‘username‘. On that destination server, stuff the files and directories into ‘/path/to/directory‘”

What you’ll need to change:

• . – if you want to specify a full path to the source directory, put it in place of the . (which means “here” in shellspeak)
• username – unless your username on the destination server is “username” – you’ll be prompted for the password for that account after hitting return and starting the program working.
• hostname – the IP address or domain name of the server you want to send the files to.
• /path/to/directory – I’m always a bit fuzzy on this. Can it be a relative path? from where? So I just specify the full path to where I want the files to go. Something like /home/dnorman/

Because it compresses files, it’s actually pretty efficient at moving a metric boatload of stuff between servers. I’ve used this technique to easily migrate from Dreamhost to CanadianWebHosting.com and I use it regularly to move files around on campus. I use a variation of this technique to regularly backup servers as well – the beauty of rsync is that it only copies files that have been added or modified, so backing up a few gigs worth of server really only involves transferring a few megabytes of files, and can be done routinely in a matter of minutes or seconds.

Do support that batch creation of users, I installed the “Import Users Plugin” which, surprisingly, provides a way to import users into a site. All you need to provide is a username and email address for each student and it will create the account, generate a password, assign the specified user Role, and send an email to the student so they can login. It doesn’t create blogs for each student, but for our current use-case, it’s ideal – adding users to a single blog in a WordPress Multiuser service.

If you need to batch create a bunch of users, first enable the “Dagon Design Import Users” plugin on your blog, then follow these instructions:

The list of users could be pulled from Blackboard or Peoplesoft, but needs to be reformatted into

username|email address

structure so the plugin can make use of it.

Nope. Turns out the problem is much more difficult and complex than I initially thought.

Taxonomies won’t work, because of the need to tie a number of values together, namely the year the degree was awarded (say, “1992″), the type of degree (say, “BSc”), the specialization of the degree (say, “Zoology”), and the granting institution (say, “University of Calgary”).

That could be an easy thing to solve with CCK – just add four text fields. Done.

BUT – people can earn more than one degree. Of different types, in different years, from different institutions.

Taxonomies fail. Generic CCK fields fail.

What I came up with is a new CCK field type, cryptically named “University Degrees”, that defines the four values that describe a degree. This solves the problem quite tidily, and supports multiple values, predefined valid sets of values, and can integrate with Views to be used as filters and sorting fields.

In building this module, I leaned heavily on a couple of web pages (CCK Sample and What is the Content Construction Kit?) that describe how parts of the module should work, and provided some sample code. In the spirit of contributing back what I learned, I’m going to document the module to help others needing to do similar things.

To start with, I just created a new folder to hold the module, and called it “universitydegrees“. Into this folder, I copied the .install and .info files from another module and customized them to suit my needs (the universitydegrees.install file doesn’t actually do anything, and the universitydegrees.info file is just for listing the module in the Drupal admin page). If you want to follow along (or use the files as a starting point to make something else) the files for my lame alpha version of the module are available here.

The file where all the fun stuff happens is universitydegrees.module

The first method, universitydegrees_field_info(), defines how the field shows up in the CCK admin interface.

function universitydegrees_field_info() {
  return array(
    'universitydegrees' => array('label' => 'University Degree'),
  );
}

This method works with the universitydegrees_widget_info() method, and will list any available widgets under the “University Degree” field type. In this case, I just added a simple widget description, like this:

function universitydegrees_widget_info() {
  return array(
    'universitydegrees_text' => array(
      'label' => 'University degree earned',
      'field types' => array('universitydegrees'),
    ),
  );
}

So, a new field called “University Degree” will be available, like this:

Before actually adding the field to any content type, we need to define what data it’s going to store. This happens in the universitydegrees_field_settings() method:

function universitydegrees_field_settings($op, $field) {
  switch ($op) {

    case 'save':
      return array('year', 'degreetype', 'programme', 'institution');

    case 'database columns':
      $columns = array(
        'year' => array('type' => 'int', 'not null' => TRUE, 'default' => '2008', 'sortable' => TRUE),
        'degreetype' => array('type' => 'varchar', 'length' => 255, 'not null' => TRUE, 'default' => "''", 'sortable' => TRUE),
        'programme' => array('type' => 'varchar', 'length' => 255, 'not null' => TRUE, 'default' => "''", 'sortable' => TRUE),
        'institution' => array('type' => 'varchar', 'length' => 255, 'not null' => TRUE, 'default' => "''", 'sortable' => TRUE),
      );
      return $columns;

    case 'filters':
      return array(
        'default' => array(
          'list' => '_universitydegrees_filter_handler',
          'list-type' => 'list',
          'operator' => 'views_handler_operator_or',
          'value-type' => 'array',
          'extra' => array('field' => $field),
        ),
      );
  }
}

The 'save' portion defines what values will be saved. The 'database columns' portion defines the MySQL code to generate the fields in the database to store each of the values. In this case, 'year' will be an int and the remaining values will be varchar(255) text strings.

Now, to define how the widget that is used to edit the values should behave. This is the universitydegrees_widget() method.

function universitydegrees_widget($op, &$node, $field, &$items) {
    $options_year = _universitydegrees_values_year();
	$options_degreetype = _universitydegrees_values_degreetype();
	$options_institution = _universitydegrees_values_institution();

   switch ($op) {

      case 'form':
        $form = array();
        $form[$field['field_name']] = array('#tree' => TRUE);

        if ($field['multiple']) {
          $form[$field['field_name']]['#type'] = 'fieldset';
          $form[$field['field_name']]['#description'] = t('Degrees Earned');
          $delta = 0;
          foreach (range($delta, $delta + 2) as $delta) {
			$item = $items[$delta];
			$form[$field['field_name']][$delta]['#type'] = 'fieldset';
            $form[$field['field_name']][$delta]['year'] = array(
              '#type' => 'select',
              '#title' => t('Year'),
			  '#default_value' => array_search($items[$delta]['year'], $options_year),
			  '#options' => $options_year,
            );
            $form[$field['field_name']][$delta]['degreetype'] = array(
              '#type' => 'select',
              '#title' => t('Degree Type'),
			  '#default_value' => array_search($items[$delta]['degreetype'], $options_degreetype),
			  '#options' => $options_degreetype,
              '#required' => ($delta == 0) ? $field['required'] : FALSE,
            );
            $form[$field['field_name']][$delta]['programme'] = array(
              '#type' => 'textfield',
              '#title' => t('Degree, major or concentration'),
			  '#default_value' => $items[$delta]['programme'],
              '#required' => ($delta == 0) ? $field['required'] : FALSE,
            );
            $form[$field['field_name']][$delta]['institution'] = array(
              '#type' => 'select',
              '#title' => t('School'),
			  '#default_value' => array_search($items[$delta]['institution'], $options_institution),
			  '#options' => $options_institution,
              '#required' => ($delta == 0) ? $field['required'] : FALSE,
            );
          }
        }
        else {
			$form[$field['field_name']][0]['#type'] = 'fieldset';
            $form[$field['field_name']][0]['year'] = array(
              '#type' => 'select',
              '#title' => t('Year'),
			  '#default_value' => array_search($items[0]['year'], $options_year),
			  '#options' => $options_year,
			  '#required' => $field['required'],
            );
            $form[$field['field_name']][$delta]['degreetype'] = array(
              '#type' => 'select',
              '#title' => t('Degree Type'),
			  '#default_value' => array_search($items[0]['degreetype'], $options_degreetype),
			  '#options' => $options_degreetype,
              '#required' => $field['required'],
            );
            $form[$field['field_name']][0]['programme'] = array(
              '#type' => 'select',
              '#title' => t('Degree, major or concentration'),
			  '#default_value' => $items[0]['programme'],
              '#required' => $field['required'],
            );
            $form[$field['field_name']][0]['institution'] = array(
              '#type' => 'select',
              '#title' => t('School'),
			  '#default_value' => array_search($items[0]['institution'], $options_institution),
			  '#options' => $options_institution,
              '#required' => $field['required'],
            );
        }
        return $form;

      case 'process form values':

        foreach ($items as $delta => $item) {

			// don't store empty stuff.
			if (empty($items[$delta]['year']) && $delta > 0 ) {
				unset($items[$delta]);
			} else {
				// do an array lookup to store the actual value of the selection, not just the number of its index position.
				$items[$delta]['year'] = $options_year[$items[$delta]['year']];
				$items[$delta]['degreetype'] = $options_degreetype[$items[$delta]['degreetype']];
				$items[$delta]['institution'] = $options_institution[$items[$delta]['institution']];
			}
        }
  }
}

The $options_year, $options_degreetype, and $options_institution variables are just calling methods that return arrays of values. I did this initially to separate the options from the various places they are used so I could change where the data comes from more easily (it’d be really cool to tie these into taxonomies or something more user-editable…)

The 'form' portion generates the portion of the form that is used to edit the content associated with an instance of the field. It has two sub-portions, one for handling multiple values, and one for single values. I’m really not sure why that isn’t collapsed into a single chunk that can grok both single and multiple values, but I was following a recipe and left it that way. For now… The only portion I really cared about was the multivalue stuff anyway, because that’s how I’ll be using the content type.

The code for that portion defines a fieldset, called “Degrees Earned” and starts pumping out chunks of forms to present editors for each value. It creates a nested fieldset for each value, and presents a Select field for “Year”, “Degree Type” and “Institution” – and a textfield for “Degree, major or concentration”.

One thing that I didn’t like in the out-of-the-box widget behaviour was that it stored the index of the value, rather than the actual value itself, in the database. While that worked, it wasn’t ideal – if I changed the list of options, the index values would be invalid. So I modified the code to lookup the actual value selected and store that for the select widgets. (the #default_value portions of the code present the current value, if any, while editing).

The 'process form values' portion does any processing of the values prior to saving in the database. This is where I convert the stored values from plain, dumb, indexes to a more meaningful text string containing the actual selection.

Here’s what the form looks like, with the widgets in place:

Now that we have a field defined, have provided a way to save values in the database, and described how the form widgets should behave, we need to display values on the node page. I took a shortcut and only defined a single hard-coded way to present the values. I’ll eventually work in a way to customize the display using a list of formatters. In the meantime, the universitydegrees_field_formatter() method handles the conversion from raw data into displayable text.

function universitydegrees_field_formatter($field, $item, $formatter, $node) {
	$text = '';

	$text = $item['degreetype'] . ' ' . $item['programme'] . ' (' . $item['institution'] . ', ' . $item['year'] . ')';
	return $text;
}

With the formatter in place, a node with this CCK field type will look like this:

And that’s it. Now, I can add a University Degree to any CCK content type, and be able to define all four values that describe a degree awarded to an individual. This pattern could easily be generalized for other compound data types, as well.

Next, I need to expose full Views functionality, so each value can be used for filtering and sorting Views. And, I need to provide a more flexible way to display the values, using the formatters. And, I need to abstract the lists of Years, Degrees and Institutions so that they are editable by users without having to modify the source code for the module…