I am currently the lead back-end developer over at Highrise Digital, in charge of a large (over 500 sites) multisite installation of WordPress. Each site in the install has its own custom mapped domain, rather than using a subdomain of the primary site. In this post, I discuss how I set up domain mapping to websites in the WordPress multisite install, without pointing the domains to the servers IP address.
Currently I am in the middle of developing an Intranet at work using WordPress. At first the Intranet consisted of one site, with many pages and over 200 users that simply needed to view the site. Over time it has grown and I now have several sub sites doing different things, for less users. It has become a pain to manage all these sub sites and therefore this is how I went about migrating a single site into a Multisite environment with WordPress 3.4.2.
First of all it is important to say that I am using a Windows based IIS7 server for the hosting environment. Being a corporate network environment Windows is heavily used, in fact we only have 1 or 2 linux based boxes left. This poses some challenges, however as I have found over the course of working with IIS7 it has many advantages. The main advantage is being able to offer a single sign on experience, combining WordPress with Windows Active Directory Authentication. This was a crucial part as it means users don’t have separate logins for the different sites, network login and also their email addresses using Exchange server. Also password changes are replicated across platforms.
To achieve the above, after much searching I came across the excellent wpDirAuth plugin. As the IIS7 server is on the same network as the domain, users are connected to it means that authentication to login to WordPress sites can be done using Windows Active Directory logins and this plugin allows this to happen. The hardest part of getting the plugin to work is getting the settings correct as some of the defaults such as Account Filter and Base DN needed specific inputs from the network admin (although you should really do this alongside your network admin). To keep it simple, what the plugin does, is when a user logs in with their AD network login credentials it checks whether they are a valid [network] user. Then if they are, and they are not a user in WordPress it creates that user with the default role as set in the settings page. If they are already a user then it checks whether the WordPress user password matches the AD network login password. If not is changes it to match. This way the users password is always the same as their AD login password.
I know that had little importance with the title of this post, however I feel it is of paramount importance when using WordPress in enterprise and therefore needed saying. That out of the way, lets get onto the migration.
For the purposes of this example I going to assume that we have a single install of WordPress at mainsite.mydomain.com. This has lots of content (in my case there were 84 pages, 15 custom post type posts and 18 [normal] posts). We could of course activate the multisite component in the WordPress installation on this domain, however as there is already content present WordPress will only allow you to use sub domains rather than sub folders for additional sites in the network. This is to avoid breaking any existing permalinks that are in place. This didn’t really appeal to me as I did not want multiple sub domain address such as site1.mainsite.mydomain. Therefore the only option is to start a fresh install of WordPress and migrate mainsite.mydomain.com across. However we have a problem, in that the domain we actually want to use for the multisite is already used – mainsite.mydomain.com, which contains are single site install.
To get around this we have to migrate the mainsite.mydomain.com to another location first. What I did was to create another sub domain (for example) called mainsiteone.mydomain.com. I then migrated the site to this domain (an exact copy) making use of Interconnectit’s excellent script.
Now I have an exact copy I can wipe the content and database from mainsite.mydomain.com ready to start a fresh install of WordPress. Set up WordPress as normal and then follow the instructions on the codex here for setting up WordPress as a network or multisite environment.
Now we need to import all of the content from the newly created copy at mainsiteone.mydomain.com to the new multisite environment at mainsite.mydomain.com. The only way to do this is to use the WordPress export functionality on the tools menu. Then at mainsite.mydomain.com we can use the WordPress import functionality, to import all of the content and the attachments of all the posts and pages etc. This worked well for me and brought across all of the media too, which was good, although I have had mixed results from this in the past.
You will of course have to upload any themes and plugins that were being used when the site was a single site but this does not take a long at all, and as you do you will see your site come back to life!
In the past I tended not to use Multisite but I am giving it another go. The main reason is that I have an Intranet of websites that need to look the same, and therefore using the same core code and user base seems to make sense to me. Maybe I will regret it but so far all seems well.
The next thing to tackle is domain mapping, however not all the sites on my networks I will want to map to another domain, which may be the challenge.