The result is a near-complete rewrite, released today under the name Simple Import Users. Instead of entering all sorts of information about username, password, display names, etc, Simple Import Users accepts only a single argument: email address. That makes it simple enough for anyone to use. Insert a list of email addresses into Simple Import Users, and it checks each email address in the following way:

• If a WP user is *not* found with the email address in question, SIU creates a new user with that address. The username is automatically generated from the part of the email address before the @-sign, which means that this plugin will probably work best for those setups where you can guarantee unique email prefixes (like schools). Passwords are randomly generated.
• Then the new user (or the existing user, if one was found) is added to the blog.
• The user is then sent a customized welcome email. All users get a message saying that they’ve been added to the blog, with information on how to access the dashboard. In the case of new users, it contains their login info as well.
• If you’re running BuddyPress, the email to new users also contains a message encouraging users to fill out their BP profiles, with a link to the Edit Profile page.

The plugin has no settings, and is intended for this very specific purpose. But if you’ve got a setup like Blogs@Baruch, it could save you a lot of time and effort.

Get the Simple Import Users here.

Related posts:

1. More Import from Ning goodness – ( Ning to BuddyPress / WordPress )
2. Blog-specific email plugin for WPMU users
3. Importing Ning users into WP

I recently modified Popularity Contest to do just that. The idea is simple: in order to keep network-wide stats, we need a network-wide table (instead of the default site-specific tables). How do you keep information about all networkwide posts on a single blog? I used Donncha O Caoimh’s Sitewide Tags as a bridge. All posts across the network are copied to the tags blog, and popularity data is indexed on the tags blog.

To make this work, several things are needed. I can’t just give you the files because I’ve altered them in other, irrelevant ways, but I will walk you through the process of setting it up. Also, keep in mind that we’ll be modifying the plugin code for both Popularity Contest and Sitewide Tags, modifications you’ll have to make each time you upgrade the plugins. Make sure you back up your work.

1. Install Sitewide Tags which can be downloaded from its website. You have to activate a few things in order to turn it on – read the readme carefully. Be sure to take note of the tags blog id number, as we’ll need that in a later step.
2. In sitewide-tags.php, look for the function sitewide_tags_post(). Near the end of the function is a line that says restore_current_blog();. Immediately after that line, enter the following code:

   update_post_meta( $post->ID, 'tags_post_id', $p );

   That line makes sure that every time a post is aggregated on the tags blog, the original post gets a piece of metadata noting the post id of the corresponding tags blog post. We’ll use that information in a later step.

3. Download Popularity Contest from its website. I don’t recommend that you activate it yet, especially not networkwide, because it will create a lot of tables that you don’t really need.
4. The next few steps will require mading some modifications in the main Popularity Contest plugin file, popularity-contest.php. The first modification is to change all references to $wpdb->posts (which, when activated networkwide, will refer to the posts table for the individual blogs) and change them to point to the tags blog post table. A search and replace that replaces $wpdb->posts with wp_posts (or wp_x_posts, if your tags blog is not site number 1 but is instead site x.
5. The next modification involves the function akpc_init(), near the end of the plugin file. That’s where the table names for the Popularity Contest custom tables are found. We need to make sure that they point to the tags blog. Replace the existing function with this:

   function akpc_init() {
   global $wpdb, $akpc;
   
   $wpdb->ak_popularity = 'wp_ak_popularity';
   $wpdb->ak_popularity_options = 'wp_ak_popularity_options';
   
   $akpc = new ak_popularity_contest;
   $akpc->get_settings();
   }
   

   If your tags blog is something other than blog 1, you could change these table names to match (e.g. wp_15_ak_popularity) but it isn’t really necessary.

6. Now we have to make Popularity Contest aware of the identity relationships between the tags posts and the original posts. Two snippets of code should do it in most places. First, find the function record_feedback, which starts around line 700. Right before the switch($type) line, insert the following:

   if ( $tags_post_id = get_post_meta( $comment_post_ID, 'tags_post_id', true ) )
   $comment_post_ID = $tags_post_id;
   

   Next, find the function akpc_api_record_view(), which starts around 2550. Right after array_unique($ids); (around line 2555), insert the following:

   $tags_ids = array();
   foreach ( $ids as $id ) {
   $tags_ids[] = get_post_meta( $id, 'tags_post_id', true );
   }
   $ids = $tags_ids;
   

   These two modifications make sure that Popularity Contest knows which post on the tags blog corresponds to the post being visited/commented on on the child blogs.

7. At this point, you can activate the popularity plugin networkwide. Here’s what happens, very roughly:
   • The plugin creates the necessarily popularity tables – just one set for the whole installation.
   • When you publish a new post on any site, it gets copied to the tags blog. Our modification from step 2 makes sure that the copied post ID (let’s say 36) is saved to the original post.
   • When someone visits the original blog post, Popularity Contest fires (because it’s been activated network wide). Our modifications in steps 4 and 5 make sure that the plugin knows to record the activity to the tags blog index, and step 6 make sure that the plugin know which post the activity belongs to.
8. You’ll need another modification to get the data out, since you’ll want to display it on your site somewhere. The default function for this is called show_top_ranked(). We need to modify so that it gets the requested data from the right place. Replace the stock function with this one:

   function show_top_ranked($limit, $before, $after) {
   switch_to_blog( 1 );
   if ($posts=$this->get_top_ranked_posts($limit)) {
   foreach ($posts as $post) {
   $ud = get_userdata( $post->post_author );
   print(
   $before. get_thumbnail( $post->post_author, 36 ) .'<a href="'.get_permalink($post->ID).'">'
   .$post->post_title.'</a><br /><strong>'. $ud->display_name . '</strong>' . $after
   );
   }
   }
   else {
   print($before.'(none)'.$after);
   }
   restore_current_blog();
   }
   

   Make sure you change the number in the switch_to_blog() call to the id of your tags blog.

I think I’ve remembered everything. Good luck!

Bonus!

For my project, I was moving from a single WordPress site to a multisite situation. The popularity plugin had been running on both setups for a while, so the data was totally messed up and needed to be combined (which meant finding the corresponding post data and adding it together – yeesh!). Here’s the script I used – be careful with it, and keep in mind that it was designed for a *very* specific use. Do not use this code if you don’t understand exactly what every line does!

global $wpdb;

$query = "SELECT * FROM {$wpdb->blogs} WHERE site_id = '{$wpdb->siteid}' ";
$blog_list = $wpdb->get_results( $query, ARRAY_A );

foreach( $blog_list as $blog ) {
//print_r($blog); continue;
if ( $blog['blog_id'] == 1 ) continue;
//if ( $blog['blog_id'] != 83 ) continue;

$tn = 'wp_' . $blog['blog_id'] . '_posts';
$tnmeta = 'wp_' . $blog['blog_id'] . '_postmeta';

$query = "SELECT ID FROM {$tn} WHERE post_type = 'post' AND post_status = 'publish' ";
$posts = $wpdb->get_results( $query, ARRAY_A );

foreach( $posts as $post ) {
$id = $post['ID'];

$query = "SELECT meta_value FROM {$tnmeta} WHERE post_id = '{$id}' AND meta_key = 'tags_post_id' ";
$tags_post_id = $wpdb->get_results( $query, ARRAY_A );
$tpid = $tags_post_id[0]['meta_value'];

$query = "SELECT * FROM wp_ak_popularity WHERE post_id = '{$id}'";
$old_data = $wpdb->get_results( $query, ARRAY_A );
$old_data = $old_data[0];

$query = "SELECT * FROM wp_ak_popularity WHERE post_id = '{$tpid}'";
$new_data = $wpdb->get_results( $query, ARRAY_A );
$new_data = $new_data[0];

if ( $old_data && $new_data ) {
$combined_data = array();

$combined_data['post_id'] = $new_data['post_id'];
$combined_data['last_modified'] = $new_data['last_modified'];

foreach( $old_data as $key => $d ) {
if ( $key == 'post_id' || $key == 'last_modified' )
continue;

$combined_data[$key] = (int)$d + (int)$new_data[$key];
}
}

$query = 'UPDATE wp_ak_popularity SET ';
foreach( $combined_data as $key => $cd ) {
if ( $key == 'post_id' )
continue;
$query .= "{$key} = '{$cd}', ";
}

$query = substr_replace( $query, '', -2 );
$query .= ' ';

$query .= "WHERE post_id = '{$combined_data['post_id']}'";
$wpdb->query( $query );
print_r( $old_data ); echo "<br >"; print_r($new_data); echo "<br>"; print_r($combined_data); echo "<br>"; echo $query; echo "<br /><br /><br />";

}

echo "<pre>";
//		print_r($posts);
echo "</pre>";
}

Related posts:

1. Making Sitewide Tags work
2. Sitewide Tag Suggestion in WordPress MU 2.8+
3. Blog-specific email plugin for WPMU users

Read more about the changes in 0.4-alpha.

Questions or thoughts about Anthologize? Visit the Anthologize home page or the Anthologize users group.

Related posts:

1. Introducing Anthologize, a new WordPress plugin
2. Help me alpha test BuddyPress Forum Attachments
3. Hiding WordPress custom post type menu items without disabling edit access

For instance, the ‘show_ui’ parameter of register_post_type() is a little bit too coarse-grained for our purposes. For Anthologize, we wanted to allow the user to edit custom post types with the standard Edit page, but we didn’t want users to be able to access most of these post types through the menu items automatically created by register_post_types (all links to the edit pages would appear on our custom Dashboard panel, in order to reduce redundancy and confusion). With ‘show_ui’ set to true, users could access the edit screens, but they could also access the unwanted menu items; with ‘show_ui’ set to false, the menu items were hidden, but navigating to the Edit pages (directly, via URL) threw a “You don’t have permission to access this page” error.

Here’s how we resolved the dilemma. Note that it’s a bit hackish at the moment. In the future, I hope the WordPress team will split ‘show_ui’ gets into multiple, separate arguments.

1. In your register_post_type() call, set ‘show_ui’ to true. Here’s an example from Anthologize:

   	register_post_type( 'library_items', array(
   		'label' => __('Library Items', 'anthologize' ),
   		'public' => true,
   		'_builtin' => false,
   		'show_ui' => true,
   		'capability_type' => 'page',
   		'hierarchical' => true,
   		'supports' => array('title', 'editor', 'revisions'),
   		'rewrite' => array("slug" => "library_item")
   	));
   	

2. To remove the unwanted menu items, we’ll take advantage of the fact that WordPress has built-in support for custom menu order. First, we have to tell WordPress to expect a custom menu order. (The following two functions are modified from Anthologize, where they’re methods on a loader class.)

   	function toggle_custom_menu_order(){
   		return true;
   	}
   	add_filter( 'custom_menu_order', 'toggle_custom_menu_order' );
   	

3. Once custom_menu_order has been set to true (step 2), WordPress makes a new filter hook available, menu_order. As the name says, it’s really meant to reorder menu items, but we’ll use it to erase menu items altogether.

   	function remove_those_menu_items( $menu_order ){
   		global $menu;
   
   		foreach ( $menu as $mkey => $m ) {
   			$key = array_search( 'edit.php?post_type=library_items', $m );
   
   			if ( $key )
   				unset( $menu[$mkey] );
   		}
   
   		return $menu_order;
   	}
   	add_filter( 'menu_order', 'remove_those_menu_items' ) );
   	

   Here’s what’s happening. The filter hook is meant to modify $menu_order. That’s why remove_those_menu_item() takes $menu_order as an argument, and returns it back to WordPress untouched on the last line of the function. On the first line of the function, we’re taking advantage of the fact that the $menu variable – where menu items are stored for construction into markup later on – is in the global scope. Once we’ve declared that we’ll be using $menu on the first line, we loop through each of the menu items, and when we find one that matches our custom post type (ie, when we find one that contains the string ‘edit.php?post_type=library_items’ – you’ll have to replace the post_type with your own, obviously), it gets removed from the $menu global.

You can iterate this for as many different custom post types as you’d like – just add more potential keys to the foreach loop in remove_those_menu_items(), eg

	$key = array_search( 'edit.php?post_type=library_items', $m );
	$keyb = array_search( 'edit.php?post_type=some_other_post_type', $m );

	if ( $key || $keyb )
		unset( $menu[$mkey] );
	

Related posts:

1. Introducing Anthologize, a new WordPress plugin
2. Anthologize 0.4-alpha is released
3. Enabling Popularity Contest for WordPress networkwide use

Anthologize

The product of One Week | One Tool, a one week digital humanities tool barn raising hosted by CHNM and sponsored by the NEH Office of Digital Humanities, is Anthologize. Anthologize is a WordPress plugin that lets you collect and curate content, organize and edit it into a form that works for you, and publish it in one of a number of ebook formats.

As I said in my last post, I was the lead developer for Anthologize. This stemmed from the fact that, for reasons of market penetration and ease of use, we’d chosen WordPress as a platform, and I was “the WordPress guy”. As such, I was the natural person to oversee the various parts of the development process, and to make sure that they fit together in a neat WordPress plugin package. It was an incredible and humbling experience to work with a group of developers who were, to a person, more talented and experienced than I am.

Anthologize PDF output

Today, the plugin is shipping with four different formats for exporting: PDF, ePub, RTF, and a modified version of TEI that leaves most content in HTML form. None of these export processes are perfect. Some require that certain libraries be installed on your server; some do not offer the kind of layout flexibility that we like; some are not great at text encoding; etc. This release is truly an alpha, a proof-of-concept. The goal is to show not only what a group of devoted individuals can conceive and develop in six short days, but also to provide the framework for further development in the world of independent authorship, publishing, and distribution.

As such, the plugin is designed, and will continue to be developed, with an eye toward maximum flexibility and modularity. Content can be created in WordPress or pulled in by RSS feeds, providing for greater choice of authoring platform. Export formats are generated by translators that work not with native WordPress data, but with an intermediary layer structured with TEI metadata markup. That means that you don’t have to know anything about WordPress to build a new export translator for yourself – you only have to know some PHP and XSLT. And we’re working on expanding Anthologize’s action and filter hooks to allow for true pluggability in the manner of WordPress itself.

I’m hoping that Anthologize will be a useful tool that draws development interest from folks who might not otherwise be interested in WordPress or web development, especially those who are working in the academic, cultural heritage, and digital humanities worlds. Get involved by checking out our Github repository at http://github.com/chnm/anthologize, our development list at http://groups.google.com/group/anthologize-dev, or stop in and chat with the dev team at #oneweek or #anthologize-dev on freenode.

Related posts:

1. Anthologize 0.4-alpha is released
2. New BuddyPress plugin: BuddyPress Group Email Subscription
3. New WordPress plugin: Simple Import Users

There’s much to blog about regarding my experience at One Week, much of which I’ll be able to divulge more fully after the veil of secrecy has been officially lifted. (Yikes! So secretive.) One of the things I can talk about now is the workflow of the team over the course of the week, something Jana has already discussed nicely in her blog.

Whiteboard spoilers!

We arrived at CHNM with no idea what we were going to build over the course of the week. Monday was spent getting to know each other, hearing from the CHNMers about they develop and sustain open source software, and brainstorming ideas for our own project. By the end of the day Tuesday, the project had been decided and teams had been divided up. I didn’t sleep very well that night, both from excitement and from nerves: the tool we’d decided to build would rely on a set of technologies that would make me the de facto lead programmer.

And therein lies the first remarkable thing about the event. By many objective accounts – breadth and depth of knowledge and experience – I was, at best, the fifth or sixth most talented developer in the group. (Not trying to be overly humble here: one look at the One Week “People” page and you can see that the deck was stacked with incredible talent, folks with whom I’m happy to be in even the same ballpark.) Differently-focused projects require different kinds of talent, and it so happened that this very focused project required just the sort of skills that I possess. So the first lesson I take away from One Week is that leadership doesn’t necessarily follow, or require, the greatest technical skill or experience. It might be that the notion of “best leader” reduces to “best leader right now”, which is to say that “best” is highly relative to particular needs and circumstances. It’s a realization that highlights how leadership roles are not (or maybe should not) be merit badges gifted to those who have “earned” them, but instead are necessary aspects of a structure – like the One Week crew – aiming to acheive an independent goal.

My second One Week lesson is closely related to the first: leadership doesn’t work without humility and trust. The way we built our tool was like digging the Chunnel: developers at home with one part of the tool’s functionality (like the British on British soil!) tunnelled toward developers who were digging from the other direction. I was in charge of making sure that the several tunnels met in the middle to make for a navigable whole. But, as you’d expect, there’s no way that one person (even one as dashing and wonderful as I am) could really know what was happening in all parts of the project at the same time. There were simply too many technical details to keep track of. Making sure that the tunnel got built, and our code got merged, meant putting a good deal of trust in the diggers, and accepting – even embracing – those moments when their work was beyond my ability to understand technically.

All this is to say nothing of the equally crucial folks who were not writing code, but we doing what we called “user experience” and “outreach”. In those cases even more trust was required: the dev team trusts the outreach team not to write checks that the code can’t cash; the UX team trusts the dev team to remain true to the needs of the end user; and so forth. Here too, in a less technical but no less accurate way, we were digging a tunnel from opposite directions. The outreach and UX teams were developing an increasingly detailed vision of what the tool needed to do, and the dev team was cranking out code that would fulfill that vision. There was a magical moment when, on Thursday afternoon, Jason and Scott from the UX team – coders by trade who had found themselves in a non-coding position in our particular development project – merged in a totally organic way with the dev team to flesh out some of the UX that they’d been conceptualizing for the previous two days. That too demonstrated a kind of trust between One Weekers, where team boundaries were mutable when circumstances required it, and no one blinked an eye when two more people started committing code to the repo.

Much more to come, I’m sure.

No related posts.

Several weeks ago, Ning released its Ning Network Archiver, which (finally) allowed network admins an easy way to take their content with them. On the heels of this release by Ning, today I am releasing version 2.0 of Import From Ning, which imports the content from a Ning Network Archive.

Read more about the updated plugin here. And to those Ningsters who are coming over to WordPress and BuddyPress: good on ya!

Related posts:

1. More Import from Ning goodness – ( Ning to BuddyPress / WordPress )
2. Importing Ning users into WP
3. New BuddyPress plugin: BP Import Blog Activity

JUNE 14: Hudson’s Smokehouse, Columbia, SC

We’d just finished a stint in Eastern Tennessee, where we’d enjoyed some bodacious relaxation but no phenomenal barbecue. We knew we’d have to make up for it on this comparatively short stay in the Carolinas. Our first stop en route to Charleston was chosen largely for convenience’s sake: it was not too far off our course, and we’d be passing by around lunchtime (unlike some of the more well known SC barbecue joints), and they’d be open on a Monday afternoon (again, unlike some of the more traditional joints, which are often open Thurs-Sat only).

With these conditions in mind, a bit of internetting led us to Hudson’s Smokehouse, which had gotten favorable reviews on the sites I’d checked. They had a lunch buffet that looked pretty good, but the idea all-you-can-eat fullness in the 100-degree heat followed by a few hours in the car didn’t strike us as the wisest dining decision. So we ordered off the menu: we each got the pork platter, and I got green beans and baked beans while Rebecca got sweet potato fries and collards.

Hudson's Smokehouse

Here’s the thing: OMG. One small bite of the pork and I was rushed back to our previous barbecue vacation, when we ate our way across North Carolina, hickory smoke coursing through our veins, on a kind of high that can only be sustained with two or three different barbecue joints every day for a week. It’s not so much that Hudson’s was the best pork ever, but it had all the trappings of the great barbecue: the smoky aftertaste, the balance of cider vinegar and Texas Pete’s, the salty outside brown. It was awesome. And the sides were very, very good as well, though the sweet potato fries didn’t stand up to the rest. Evidence:

Hudson's, terminé

Nom nom nom.

June 15: Bessinger’s Barbecue, Charleston, SC

Charleston was blazing hot. Heat indices into the 110s. This is ideal weather for barbecue. Indeed, any weather is ideal weather for barbecue. We were in South Carolina, and we wanted some of the local stuff.

At Hudson’s the day before, the barbecue was Lexingtonesque, by which I mean that it was pork shoulder, served with a vinegar sauce that had just a bit of ketchup in it for color and sweetness. That’s how they do it in the western part of NC, centered around Lexington. When you talk about South Carolina barbecue, though, the mind usually goes to mustard sauce instead of ketchup. Charleston, from what I understand, is known for having a variety of native barbecue styles, but since we were in SC we wanted mustard, and my research told me to get it at Bessinger’s.

I got the pork plate, with baked beans and cole slaw. Bessinger’s is notable for throwing in an enormous onion ring with every meal as well. Let me tell you something about that onion ring: It was something else. Enormous and battered beyond recognition, it was hard to tell, even when looking closely, where the batter ended and the onion itself began. You know that problem you sometimes have where the onion and batter don’t stick to each other, and you end up pulling the whole (scorching hot) onion out on your first bite? At Bessinger’s, the onion and batter had truly become One. Was it the best onion ring I ever had? No. But I have to give them some real points for technique.

Bessinger's

The barbecue was a bit disappointing. By itself, it had just a trace of smoky flavor, and not much of the salty fatness that would have to be present to make up for the relative lack of smoke. The mustard sauce on the table was too sweet for my liking, with none of the vinegary kick that, frankly, I expect even out of a bottle of Plochman’s. The cole slaw was a generic, mayonaissey, Midwestern affair. The beans were on the sweet side for my taste, but otherwise pretty well executed. Maybe I was coming off of a high from the day before and expecting too much, but with the exception of that exceptional onion ring, I walked away a bit disappointed.

For reasons related to heat and pork fatigue and the otherwise awesome food in Charleston, this was the last barbecue meal we had in South Carolina.

June 17: Skylight Inn, Ayden, NC

Unless you are on the way to the bustling burgs of Hookerton or Vanceboro, Ayden is not on the way to anything. After getting off of I-40 North 45 minutes north of Wilmington, we spent about an hour meandering the highways of the beautiful North Carolina countryside before we started seeing signs for the small town. And when I did see those signs, I felt the kind of excitement that an adult man, having outgrown birthdays and Easter baskets, doesn’t get to feel very often. For the second time in as many years, I was headed to the Skylight Inn.

Skylight Inn, capital of my heart

My first time at the Skylight was a very special day. We were near the beginning of our barbecue trip, and already I think we were doubting the wisdom of eating So Much Pork. We drove a long way for what we had described as the best barbecue there is, and we were a bit perplexed to find a shack with a faux rotunda and a huge billboard bragging about how Ayden was the barbecue capital of the world. The menu is three lines long: 1) Sandwich. 2) Platter (small, medium, large). 3) By the pound. The platter was a paper tray heaped with chopped pork and a bit of uninspiring slaw, and laid over the top was a slab of what I would describe as corn brick.

But: That pork.

That Pork, 2008

That first bite might have been the most delicious thing I ever tasted, either before or since. Fatty, smoky, and strewn with crispy little bits of skin – the cracklins. It was so good, I washed it down with a sandwich.

My return to the Skylight thus had a lot to live up to. And, as such things often turn out, it didn’t live up. Don’t get me wrong, the pork was good, but I think that our 3pm arrival meant that we got stuff that’d been sitting under the heat lamp a bit too long. Also, they’d gone a bit light on the salt. By the end of my sandwich this time around, I had figured out the amount of vinegar and salt that needed to be added to each bite to make it great. And then: I tasted a piece of the pound I’d gotten to go, to bring back to my brother in Brooklyn. It was better, like it’d been picked from a non-dried-out part of the pork pile.

Skylight Inn, 2010

Looking back now, I really want to go back to Skylight. Like, right this instant.

June 17: Bum’s Restaurant, Ayden, NC

Bum’s, like Skylight Inn, has no website. That’s the first good sign.

After leaving the Skylight, we headed downtown (about eight blocks) to Bum’s, a joint we’d missed on our previous pass through Ayden. It was awesome. Unlike the Skylight, there were multiple steam tables of various down-home sides. We got a couple of barbecue sandwiches, along with some butter beans, collards, and beef stew to share. Everything was excellent. The pork was arguably, on that day, better than Skylight’s, and was even better when topped with the stagnant-water-colored sauce kept in a repurposed glass ketchup bottle on our table. I remember that the collards in particular were outstanding, with a great balance of vinegar tang, smoked porkiness, and bitter greeniness.

Bum's

Bum’s was a great way to wrap up the barbecue-fueled portion of our honeymoon adventure. Now I’m just looking for another excuse to get myself to the Carolinas. Or, at least, to find some decent pork here in NYC.

Related posts:

1. Honeymoon barbecue, part 1: the West
2. Totonno’s burns, Boone mourns

Please note that this workaround is very much a hack. It shouldn’t cause any security issues (see explanation below), but it will break the next time you upgrade WP.

Joe’s problem was that the plugin was only working for Super Admins. Administrators of single Sites could not copy new Userthemes, and they were redirected to the dreaded wp-admin/?c=1 when they tried to access the Edit Userthemes panel on the Dashboard. I figured it was a problem with permissions, and it was: all of those functions are triggered only for those users with the capability edit_themes, but for some reason only Super Admins, and not Administrators, were showing up as having that ability. (The weird thing – when I did a var_dump of WP Roles, I saw that Administrator *did* have edit_themes.) Maybe there’s some setting in WPMS that allows users to edit themes, but I couldn’t see it.

So the solution is to change the edit_themes check to something else. switch_themes seemed like an obvious choice to me, since anyone with the ability to switch themes on a given blog would also have had the ability to edit themes on that same blog. So there shouldn’t be a security problem – only blog admins should have the ability to make userthemes.

You’ll need to modify the plugin, as well as a few lines in the WordPress core.

1. Back up. I’m not responsible for anything that goes wrong!
2. Open the userthemes.php file. (I’d link to it, but I can’t find it anywhere on the web. When I’m at a better internet connection, maybe I’ll upload a version for you to edit. Maybe someone out there has a copy to share.) Search for all instances of ‘edit_themes’ and replace with ‘switch_themes’.
3. From your WP root directory, open wp-admin/theme-editor.php. On line 12, change ‘edit_themes’ to ‘switch_themes’.
4. From your WP root directory, open wp-admin/menu.php. On line 173, change ‘edit_themes’ to ‘switch_themes’.

Related posts:

1. Making Sitewide Tags work
2. Sitewide Tag Suggestion in WordPress MU 2.8+
3. Setting up a WordPress/BuddyPress development environment on OS X

Afterwards I went on a honeymoon with my lovely bride through the southeastern US. Unlike a North Carolina vacation we took a few years ago, the focus of this trip was not barbecue. That said, we still had quite a few good barbecue meals. (I mean, it’d be a downright sin to go through North Carolina without stopping at some of the shacks.) Without any further ado, then, here is a retrospective of my wedding and honeymoon through the lens of smoked meats. Part 1, appearing here, deals with what I’ll call “the West” – or more specifically, barbecue in the style of the west-of-the-Appalachians, which dominated the first part of our trip. Part 2, “the East”, will come later in the week.

June 5, the wedding day: Dinosaur Bar B Que, Syracuse, NY

When Rebecca and I decided to tie the knot (and to celebrate with a real party instead of eloping), the first thing we decided was that we wanted to have extremely awesome food at the wedding reception. Since the in-laws live near Syracuse, the home of Dinosaur Bar B Que – a joint that we’ve enjoyed very much both in Syracuse and here in NYC – it seemed a perfect fit. Dinosaur brought out a smoker rig:

Smoker

The menu was ribs, pulled pork and chicken for the meats. For sides, we had baked beans, cole slaw, and macaroni salad. Unfortunately, I don’t have a lot of great pictures of the food – everyone seemed to be too anxious to eat it to be able to take good pictures, and I haven’t gotten the files from the photographer yet – but here are a few pictures I could scrounge up. My own take on Dinosaur, and this meal in particular, is that their ribs (the meaty St Louis cut) are really top-notch, the best I’ve had here in NYS. The sauce is a traditional KC-style tomato sauce. Dinosaur also provided a spicier sauce with a bit of mustardiness that went well with their unsauced pulled pork.

Dinosaur

I’ll leave it to some of my gentle readers who were in attendance to give more feedback on the quality of the food. IMO it was pretty effin good for wedding grub.

June 9: Ridgewood Barbecue, Bluff City, TN

We spent a few days in Washington, DC near the beginning of the honeymoon, and from there we traveled to eastern Tennessee and the foothills of the Smoky Mountains. Knowing we’d be traversing the whole diagonal of Virginia, I pinged my SW VA pal Jeremy for a recommendation. Before he had the time to respond, my research had led to the same recommendation that he ended up delivering: Ridgewood Barbecue, just inside of Tennessee. We knew we had entered the South when a fellow in the parking lot gave us the unsolicited advice to try the beef, even if we normally preferred pork barbecue.

Ridgewood

This is an appropriate place for me to step back and make some commentary on barbecue snobbishness. I grew up in northeastern Wisconsin, an area that might excel in venison summer sausage and fried cheese curds but has little in the way of local barbecue. As a result, I haven’t been raised with any deep prejudices about the nature of barbecue: that it must be pork, that it must be smoked over hickory, that it must not have tomato in the sauce, what have you. While I can’t out-and-out claim that I’m glad I grew up not eating barbecue, I can say that a pleasant side effect of my barbecueless youth is that I’m willing to take it on its own terms. (As an aside, I think I enjoy a similar position with respect to pizza, though living in Brooklyn for the better part of a decade has probably warped me a bit.) This is in stark contrast to other barbecue fanatics whose rantings I have so often come across on the web, whose hearts and hatches are closed to a large portion of the wonders that the world of smoked meats has to offer. I feel sad for them.

And I feel glad that I was able to take the gentleman’s advice seriously, and order both beef and pork barbecue sandwiches at the Ridgewood. That’s because, while the pork (unusual in that it’s sliced ham, rather than chopped or pulled shoulder) was really delicious, it was a bit overwhelmed by the amount and the character of the sauce on the sandwich. The sauce is a weird mix of a couple of different styles: far more tomatoey body and sweetness than a Carolina sauce, far more vinegary tang than a Western sauce. Really good, but too much for the relatively delicate pork. (Order it on the side, if you can.) The beef, however, was really something to behold. A huge beefiness and a punch of smoke flavor punched through the sauce. It was awesome. And the sides were pretty great too, especially the baked beans: with more onion and peppers than you expect in barbecue beans, these were possibly the best baked beans I ever had. Perfect balance of sweetness and spice. Worth the trip in themselves, really.

Ridgewood beef

The second clue that we were really in the South was when the waitress, without asking, brought enormous styrofoam cups of soda to the table as we were finishing our food – “refills to go”, she said. Wowza.

June 10: Bennett’s BBQ, Pigeon Forge, TN

As I said above, the honeymoon was not intended to focus on barbecue. If it had been, we wouldn’t have travelled to eastern TN, which is not to the best of my knowledge particularly well known for its barbecue. That said, we did drive past a number of places bragging about their ribs (pandering to northern tourists, maybe?), so we decided to succumb. A bit of research showed that Bennett’s was perhaps the most reliable in the area.

Rebecca got the baby-back rib meal, and I got a platter with brisket, pulled pork, and ribs. I was not expecting much from the mini-chain and its Applebeeesque decor, but I was pleasantly surprised. The St Louis ribs, which were sauced with a mercifully light hand, had enough meat on them to see (and taste!) the smoke ring. The pulled pork (again, unsauced – thank you!) was even better: after the initial sweetness of the pork fat, a very nice smokiness took over. And they weren’t stingy with the burnt ends (or outside brown, or whatever you want to call the brown stuff on the outside of the shoulder). You can see a strip of it in the picture below:

Bennett's

The brisket was disappointing, especially coming from the incredible beef experience we’d had the previous day at the Ridgewood. The fat was gristly, the meat was underseasoned, and there wasn’t much in the way of smoke flavor. As for sides: as at the Ridgewood, the standout was the dish of baked beans. The beans were very straightforward and traditional, but really nicely executed, with a bit of smoke, a bit of sweet, and beans that didn’t have the texture cooked out of them.

It’d be a few more days before we traversed the Great Smokies and managed another barbecue meal. But that’s a subject for another post.

Related posts:

1. Honeymoon barbecue, part 2: the East
2. Totonno’s burns, Boone mourns