At OEIT, I recently worked on a new website in support of a symposium bringing together leaders from Haitian higher education and MIT faculty and staff to discuss partnerships and projects to assist in the rebuilding of the Haitian higher education infrastructure.
This is a report detailing what I did and things to remember for the next time!
As part of this project, Peter and I decided that we should try and collapse all of our existing WordPress sites into a single WordPress instalation using the multisite feature. Also known as a “network”, WordPress 3.0 now includes the capabilities that were once available as a separate installation via WPMU (WordPress Multi User). The installation is both straightforward and obscure at the same time. The instructions available on the WordPress Codex are easy enough to follow and then get very vague when they describe how to setup the domain names, and/or Apache server information.
Here are a few sites I found useful in preparing to do the setup:
So this is one of those areas where the instructions are detailed enough–either directly from WordPress or from the recommended plugin to handle domain mapping.
In our setup, we’re running a virtual server with dedicated IP addresses, some of our hostnames have their own A DNS record, and others have a CNAME DNS record. In this case, I was trying to setup haiti.mit.edu as a CNAME pointing at oeit-sites.mit.edu (well the IP address that is).
WordPress MU Domain Mapping, http://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/
The WordPress MU Domain Mapping plugin seems easy enough to use, but I managed to get it into a state where both it and I were confused. I managed to the dreaded “white screen of death”, no amount of searching (ok like an hour or two spread across two different attempts, one a trial run and the other the actual install) seemed to really resolve the issue. In the end, I just ended up deleting the plugin and also the database tables and then re-adding the plugin. On the second attempt I followed the instructions line by line and did not attempt to “check” the mapped domain as I went. I get the feeling that I foobarred something in one of the configuration entries the first time through. After that hour or three hiccup, I got things working.
There are some limitations, it seems, to the plugin.
- Password protected pages (and I assume posts) seem to redirect the user to the general login screen even though WordPress has successfully granted access to the page. So the way this works is go to a password protecte page, enter the password and you’d get the general WordPress login screen. If you then went back to the page and hit refresh, you’d see the content. I posted this question to the WordPress Multisite forums but haven’t heard anything yet.
- The plugin doesn’t seem to mask all the references to the multi-site URLs. In my case, I setup the site in a subdirectory of the form http://oeit-sites.mit.edu/haiti. This URL continued to show up when I inserted images from the Media library and also from in some of the page navigation. I’m guessing this is either a misconfiguration on my part or a limitation of the plugin.
The password protected page was a big show stopper for us, so I tried another domain mapping plugin.
Professional Domain Mapping, http://wpebooks.com/professional-domain-mapping/
Ultimately this was a $25 well spent. This plugin is by the folks that seem to be effectively the WordPress Multisite community moderators. It handles the domain mapping, and appears to have key differentiators:
- Only the SuperAdmin can do domain mapping. This allows the administrator complete control over the site, and masks the process from the local administrators of the subsites.
- The plugin masks/rewrites all of the links, including the ones that were annoying me when inserting images from the media library.
The setup was even easier than the other plugin, and while the manual was nice (and sorta technically what I paid for), it wasn’t really all that necessary. The code itself is GPL’d, the manual has different access rights (so let me know if you want the code 🙂 ).
One of the design considerations was that the website should support multiple languages. Since we used WordPress there were a number of options available to us. Our initial discussions revolved around providing key posts/pages in Creole and English. And that we might be able to leverage Michel and/or translators in Haiti or the Boston area to translate the text.
WPML Multilingual CMS, http://wpml.org/
This provides the basic translation infrastructure for the site. We’re using relatively few of the features but this plugin would allow us to have a fully multilingual site. For languages it supports natively I could choose to have the user interface elements displayed in the alternate languages, or for languages it didn’t support it provided me a way of creating a translation file.
Since Creole wasn’t one of its supported languages, I had to use the “Edit Languages” feature to add Creole. I also created a custom 18×12 pixel Haitian flag icon by modifying the Wikipedia Haitian flag.
Google Ajax Translation, http://wordpress.org/extend/plugins/google-ajax-translation/
We used the Google Ajax Translation plugin to provide “live” translation capabilities to every post and page. Just after the Earthquake, Google added an “alpha” version of the Creole translator to their website. Unfortunately the plugin hadn’t been updated to include the links to this capability so I extended the capability of the plugin by adding in Creole as an option.