Brandon Muramatsu

Preparing for the Jump to WordPress 3 Multisite for OEIT

OEIT

[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

OEIT

OEIT

This post details some of the things I’ve learned while examining how to run WordPress 3 multisite (Network) for OEIT.

Peter and I decided not to migrate the individual sites now, pending a further investigation of how to handle the hostnames and Shibboleth integration.


For the purposes of this post, let’s assume the main site is accessible via http://oeit-tsa.mit.edu/ and the files are located in /var/www/oeit/ subdirectory on the server.

In no particular order:

  • Converting OEIT’s existing WordPress blogs over to a single WordPress multisite install changes the type of administration needed to maintain the blogs. It shifts the burden to keep multiple instances of WordPress running and up-to-date to keeping a single instance of WordPress up-to-date, with the potential to affect all sites with a single update. So, if there are a small handful of sites, that are getting constant use, then maintaining them separately is less hassle than the migration. If the number of sites grow, or the sites administrative usage goes down, and there’s desire to keep them functioning, it’s better to move to a single multisite. Or, for example, OEIT gets in the business of hosting and supporting a limited network of sites for users across campus as some universities do (e.g, the University of British Columbia (1) or University of Mary Washington (2). There are some additional considerations in the consolidation that I’ll cover below.
  • With a “Network” (WordPress’ term, I’ll also use the phrase “multisite”) of sites, there will be a main site and a number of network sites.
  • The multisite version of WordPress wants to run in the document root of the main server. This means the main server name is pretty important from a branding perspective. Ideally the hostname would be oeit.mit.edu.

    The WordPress Codex on Create a Network says:

    • Giving WordPress its own directory will not work in WordPress 3.0 with multisite enabled. It interferes with the member blog lookup.
    • You cannot create a network in the following cases:
      • “WordPress address (URL)” is different from “Site address (URL)”.
      • “WordPress address (URL)” uses a port number other than ‘:80’, ‘:443’.
  • Most of our work is done on virtual servers hosted by MIT’s IS&T. As part of that process they’ll configure the servers to a certain degree for us. When we request a new hostname, IS&T usually likes to give us individual IP addresses for each hostname. This means, that on our server oeit-tsa.mit.edu, we actually have a number of different IP addresses assigned as DNS A records. For example:

    spokenmedia.mit.edu. 3600 IN A 18.9.60.213

    However, running a multisite WordPress 3 (using sub-directories) instance implies that there is a single IP address for the server, and that the network of sites is accessed from the main hostname/IP address pair. This is a bit of a departure for us. There are two ways to address this…either change the DNS entries for the individual hostnames to the main server IP address and use the WordPress MU Domain Mapping plugin, or create and maintain custom Apache rewrite rules to take requests for http://spokemedia.mit.edu/ and resolve them to the site at http://oeit-tsa.mit.edu/spokenmedia (or vice versa, I couldn’t figure out which way to write this and not be confusing).

    In discussing things with Peter, we’re still not certain which way to go…and there’s an outstanding issue to consider.

  • If we want to integrate with MIT’s Touchstone service via the Shibboleth plugins and server configuration, we may need to do Apache rewrites.
  • WordPress 3 Multisite allows for centralization of the management of themes and plugins. This means there’s a single place to update both for all blogs in the network–and also one place to screw up all blogs in the network. It also implies that there is a single set of themes for all network sites. And, unless not restricted, a single set of plugins for use by all network sites. It is possible to either globally allow network site administrators to add site specific plugins or not–there doesn’t seem to be a great middle ground. One way around this is to have selected site admins also be Super Admins, they can then add plugins and activate them. This some site admins as super admins workaround works for the current (August 2010) usage of WordPress at OEIT.
  • Our paid theme, Thesis 1.7, will require a customization to allow each site in the network to have it’s own custom variables for this theme.

Some good references:

[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

/by