#wcpdx: WordPress Multisite

These are my notes from the 4:15 session I did at WordCamp Portland. It’s a quick introduction WordPress multisite, and why you might want to consider using it.

What is it?

WordPress Multisite is a way for using one instance of WordPress to host as many sites as you’d like. Originally known as WordPress MU, the multisite functionality was merged into WordPress in WordPress 3.0.

Disclaimer

Danger, danger, danger! You’re entering the realm of advanced WordPress user and, by editing files, the database, etc. you can potentially break your site so it will cry. Make sure to back everything up before you get started. And know that you’ve been warned.

Why is it useful?

WordPress Multisite is especially useful for those who have to administer multiples sites. If you meet all of the prereqs, it can make keeping WordPress up to date, installing new functionality, backing your data up, etc. a breeze. Instead of having to manually update each website you’re responsible for managing, you simply update one.

How do I set it up?

There is documentation you can follow in the WordPress.org Codex. Basically, what you need to do is configure DNS if you plan to use subdomains, make a change to your wp-config.php file, change .htaccess values if you’re using Apache, and then run through the guide in the admin. Boom, you’re done.

What should I be aware of?

Converting a single instance of WordPress to WordPress Multisite creates and alters database tables, and isn’t recoverable.

Hosting a lot of websites with WordPress Multisite means you should scale the resources available to WordPress accordingly. Otherwise, all of your sites will be slow.

Plugins and themes are installed once, so any changes you make are incurred for all of the users across your site. For this reason, if you’re using any WordPress.org or premium themes, you should make all modifications to the theme as a child theme (or, better yet, just CSS changes).

You can make some themes available to all sites, and other themes available to just specific sites.

If you plan to install a lot of themes, it would benefit you in advance to establish a scheme for storing them (e.g. setting up /wp-content/themes/woothemes/ and /wp-content/themes/wporg/)

Usernames are unique across the network. If you’ve set up a multisite instance for all of your clients, create usernames as firstnamelastname or similar.

Network activating plugins means they’re activated across all the sites in your network, functionality is available by default, and it’s not possible for the site admin to deactivate it.

WordPress Multisite isn’t magic, it’s technology that makes your life awesome.

What tips do you have for me?

Use a plugin like Restrict Multisite Plugins to make certain plugins conditionally available to sites.

Map custom domains to sites on your network with the domain mapping plugin.

When importing content with embed codes into a site on your WordPress Multisite network, make sure to disable the KSEs filter. As of WordPress 3.2.1, you need to do so with a special filter (which didn’t exist before 3.2).

You may want to disable some of the email notifications that go out.

Keep your users from needing to modify theme template files with the WordPress.com Custom CSS plugin. This is the same code that formerly ran on WordPress.com, is super awesome, and keeps a revision history of all your changes.

Configure your admin bar to include network admin links for super admins so you can easily access management functionality. You can also expose additional functionality for your users (e.g. custom CSS) where it makes sense.

Write your short plugins to customize the admin interface, and put them in /wp-content/mu-plugins/ to have them automatically loaded.

Other useful management plugins:

  • Term Management Tools – WordPress plugin allowing you to easily move terms between taxonomies, among other things.
  • Unconfirmed – See a list of invited but unconfirmed network users.
  • Plugins for Publishers – A list I put together back in April with other plugins I like

What questions do I have for you?

What doesn’t make sense about the network admin UI?

What features or functionality would you like developed as plugins?

What features or functionality would you like included in core?

What I’d like to talk about at WordCamp Portland

In the spirit of being prepared, here are a few things I’d like to talk about at WordCamp Portland:

WordPress Multisite – In a nutshell, how it works and why it will make your life infinitely more manageable. If we have a group of people who quickly get their heads around the basics, I’d also love to share tips and tricks for pimping a multisite instance. For instance, using plugins like Restrict Multisite Plugins and customizing your admin bar to give easy access to the network admin for super admins. (People I should bump in to: Emma McCreary, Kayleen)

Test-driven Development – WordPress doesn’t do it, and I’m terrible at it. I should find a mentor with fountains of knowledge. (People I should bump in to: Michael Fields, Than Taintor, Toby McKes)

WordPress for Publishers – More and more newsrooms are using WordPress for all parts of their workflow. From experience, I know that journalists tend tolerate crappy technology. I’d love to hear from users about their current frustrations and pain points. (People I should bump into: Joe BoydstonToby McKes)

Dogfooding It – We love WordPress and sell to our clients, but a lot of us developers don’t actually use it on a regular basis. Why? How should we fix this? (People I should harass to no end: Nacin)

If you see me there on Friday, Saturday or Sunday, say hello! I look like this but with much shorter hair.

Unrealized ideas from my time at the J-School

What follows is a laundry list of all of the things I planned out but never got around to doing at the J-School. Some are crazily creative while others are to be expected. I’m writing them out because I want to retain a record of them for the future (and now they mostly live in a Basecamp account I’ll no longer have access to).

WordPress networks

At the time of this writing, the J-School has two WordPress multisite instances. One, at journalism.cuny.edu, subdomains of the primary domain, and various custom domains, offers managed websites for students, faculty, staff, and alumni. The other, CUNY Campus Wire, is managed hosting for CUNY student publications.

  • Post by email – Create new posts, let them be blog posts, galleries, links, etc., via email. Also, offer the ability to respond to a comment thread by email.
  • Search across all sites in the network – Have a dedicated URL like http://search.journalism.cuny.edu/ to run a query across all sites in the network, and offer faceted filtering to limit result types to specific content, authors, topics, etc.
  • Dynamic homepage for logged-in users – For J-School community members, the homepage becomes their dashboard for the school, including assignment information, upcoming events, discussion notifications, etc.
  • Ingest users’ social media content – Pull in and make available tweets, Flickr photos, video, and other social media from WordPress users. Offer BuddyPress profile fields for users to enter their identity information or, better yet, allow them to authenticate against the website using their third-party accounts. Use this data to build features like a realtime map of where community members are based on geo-tagged tweets or Foursquare checkins.
  • Community tagging – Any user of the network can suggest tags for a content object, including people, topics, and places.
  • Contextual documentation based on Tech website content – In the WordPress admin, replace the generic help tab documentation with custom documentation from the Tech website. Optionally allow users to create a new support ticket from the WordPress admin.
  • Soundslides WordPress plugin – Make it easier for students to publish Soundslides projects by allowing them to upload publish_to_web projects through the admin and embed with a shortcode.
  • Take a screenshot of each website homepage once a month – Offer a visual archive of how sites are evolving over time.
  • Network usage stats plugin – Track usage across the network. Data points like:
    • Total number of sites and users
    • Posts published, media content uploaded
    • Links used per post, by site and globally
    • Total embedded rich media
    • Users active within the last week
    • Number of sites using a given plugin or theme; see which is using what from the network admin
    • Distribution of custom CSS modifications by site, possibly correlated to theme
    • Most popular CSS property for custom CSS modifications

Tech website

For the last few months, we’ve spent a significant amount of time revamping our tech website. The focus now is producing documentation on every subject the team deals with, but eventually the vision is to have the website be the primary way for clients to access resources and interface with the tech team.

  • “Was this helpful?” – At the end of every piece of documentation, allow the reader to indicate whether it was helpful or not. If they mark “No”, display a small box for them to submit a comment. Optionally, enable the document author to define what the question is.
  • Content notifications – Alert authors by email if their documentation hasn’t been updated in a while.
  • Public plugin and theme directories – Make it much easier for users to see which plugins and themes they have available to use by building a directory for each into the tech website. Both single views would have details about the object, related documentation and blog posts, usage stats, and links to examples.
  • Support ticketing – Move support ticketing from the ever-awful Web Help Desk into WordPress. Users could create new tickets directed towards staff, or towards other users in the system (when creating a ticket, users would be suggested based on relevance). Tickets can be private or public, and sortable by tags so we can pull out metrics and see history easily (i.e. 163 students didn’t know how to log into WP in the last two months). A ticketing system should empower you to be proactive about support.
  • Issues as a custom post type – Create “issues” as a custom post type (network downtime, failure, classroom equipment outages) and build a view for open, pending, and past issues.
  • Equipment availability – See what equipment is available for checkout when.
  • Live refresh on search results – A la the 37signals documentation site and Google Instant.

CUNY J-Camp website

CUNY J-Camp is the brand for the J-School’s continuing education workshops. We launched a redesign in June 2011 that is well-positioned for additional improvement.

  • Support WordPress galleries – Allow for the instructor to upload images after the event and, optionally, for participants to upload their content as well. Add theme support for galleries, with a nice interface for going through all of them
  • Calendar view – By default, events are presented on the homepage in a nice grid view. A secondary view could be a month-by-month calendar so visitors can see what workshops were held in the past and what’s coming up in the future.
  • Registration through WordPress – J-Camp workshop registration is handled through Eventbrite. This is functional, but we could do so much more, like track user participation over time, if it was handled within the theme.

Digital media management odds and ends

Officially, my title at the J-School was “Digital Media Manager.” I always introduced myself as “the internet guy at the J-School”, and the job included everything from server admin to designing print ads to managing digital media…

  • Web interface for accessing Aperture – Build on the Aperture’s database of media metadata, and make those assets available through a web interface so stakeholders can view and download content without having Aperture installed on their local machine. The syncing offered in Aperture 3 really isn’t functional.
  • Digital signage WordPress theme – Design and build a WordPress theme to power the digital signage in the newsroom, on the first floor, and other places to be determined. Inspiration is Macaulay College’s implementation. Ours should rotate through events, photos, student work, “Did you know?” facts, news items, and J-School branding. Could also incorporate other network content like posts and updates.

WP.org trac tickets you should follow

One of my goals this summer is to contribute more to WordPress, the open source project we all know and love. To kick this off, I’ve started tickets for small improvements I think will make the software significantly more usable. You should follow the tickets if you want to help make them reality.

#18031 Add a “Network Admin” link to WP Admin Bar

Currently on a multisite instance, the super admin must first navigate to the dashboard (using a link on the left in the admin bar) and then use a dropdown menu all of the way on right of the dashboard that requires a click to access the Network Admin. In short, this is frustratingly complex; there should be a way to easily access the Network Admin from the admin bar. I propose we add a “Network Admin” link for Super Admins in the account dropdown. Optionally, we could also add sub menus to the primary sections of the Network Admin.

#18082 Reset screen options button

It would be nice to have a “Reset” button in screen options to restore any given admin view back to the factory defaults.

#18160 Auto-suggest usernames on views for adding user to site

In a multisite network, it’s often difficult to try and remember usernames, or a pain to search the users table, and then copy and paste the username you’ve found into the window with the form. Furthermore, site admins have no access to a global table of users to search and add from. If we can solve the scaling issues, it would be much better to be able to auto-suggest usernames when a site admin or super admin is adding a user to a site.

#18161 Bulk action: Add user to multiple sites

Currently, to add a single user to multiple sites, the super admin has to edit each site, add the user to the site, and then go on to the next site. To improve this workflow, it would tremendously useful to be able to add a single user to multiple sites in the network admin.

#18163 Include more usermeta fields in the Network Admin’s “Add User” view

The view for adding a new user in single site instances includes many useful fields (e.g. first name, last name, a checkbox for whether the user should be emailed the password, etc.). We should replicate this in the network admin to keep the super admin from having to edit each individual profile.

P.S. If you can see this blog post, you’re reading it from a brand new server powered by Rackspace Cloud. Galleries didn’t make it in the import but I’ll fix those shortly.

Idea: WordPress software update notifier

I’m going through the process of upgrading any number of the 139 themes and 76 plugins we have available on the J-School network. One thing I do on a regular basis is write a short blog post listing the affected software and what’s new. Unfortunately, I think few people actually read through these.

What would be more awesome is a personalized email to site admins listing the software updated and notices from related change logs (all automated, obviously). This is completely doable.

Idea: Register your WordPress site with a hub

When you activate the WordPress.com Stats plugin on a self-hosted install, it asks you whether you want to register the site with WordPress.com as well. This makes it show up in the admin bar that appears across the entire network.

I have an identity on the J-School network that’s much more relevant than my WordPress.com identity. I should be able to register my website with the J-School’s multisite instance in a similar fashion, and have my identity within the J-School network reference my self-hosted data (posts, status updates, photos, links and so on).

This would be neat.

Disable new site creation email notifications for WordPress multisite

In multisite, WordPress 3.0.5 will send new site creation email notifications to the site admin by default. There’s also no super admin option to disable them. Fortunately, a short code snippet in /wp-content/mu-plugins/ achieves the same effect:

function db_remove_new_site_notification_email( $blog_id, $user_id, $password, $title, $meta ) {
return false;
}
add_filter( 'wpmu_welcome_notification', 'db_remove_new_site_notification_email' );

Behind the scenes, we’re hijacking a filter in wpmu_welcome_notification() to invalidate the method and disable the email. With this approach, the option to email the network administrator is still functional.

Disabling HTML/kses filtering in WordPress Multisite

Last week, I learned the hard way that WordPress Multisite secretly strips out embedded videos and other HTML objects. With a single WordPress instance, you can easily import WordPress eXtended RSS files containing YouTube videos, iframes, etc. Then, when creating or editing a post, it’s simple to drop embed code in the body text, hit publish, and move on with your life. In WordPress Multisite, much of this HTML is stripped out by default.

If you aren’t migrating content into your new WordPress Multisite instance, a common fix to this problem is a plugin called Unfiltered MU. Unfortunately, it wasn’t a solution for me. It doesn’t work reliably, takes a roundabout approach to the problem by temporarily adding user permissions, and limits the fix to administrators and editors.

Because the J-School network is a controlled environment, I’m fine with giving authors and contributors the ability to embed videos. I put together a quick plugin called Unfiltered HTML which disables the kses filters when activated and declared mission accomplished.

Whoops, not entirely. Thanks to Andrew Nacin, last night I discovered that there’s actually a hard-coded call to the kses filter when importing into Multisite. This means all of your glorious embedded videos will be stripped out unless you comment out that line. Andrew committed a fix, though, which adds a method for disabling the filter.

Today’s project? Going through all of the content I imported into a couple dozen sites and manually adding the missing embeds by hand.