I have been an avid user of WordPress since 2004. When you use any tool for that long, inevitably it changes. Assumptions you had built up can become obsolete without you realising.
I have always been adept at getting WordPress to do what I want at any given time. But if I take my eye off the ball for a year or two the software will have changed a lot.
Although I have been maintaining multiple WordPress sites for more than a decade, I don’t always have the time to dedicate to keeping up to date with all the latest developments. So when it comes to doing some work on these sites, sometimes there are nasty surprises.
This has happened to me a few times over the years. So it proved to be the case this month when I finally bit the bullet and decided to move to WordPress multisite.
Multisite is the function within WordPress that enables you to maintain multiple separate websites on a single WordPress installation. Moving to multisite has been on my to-do list for literally years.
I am responsible for seven different WordPress sites that I run (or ran) in my spare time as a hobby. They are all a little different.
Juggling those sites worked OK while I was a student with too much spare time and not enough social life. But nowadays I don’t have the time to maintain seven separate WordPress installations.
But setting up WordPress multisite requires considerable time investment in itself. I knew there were going to be bumps along the way.
Here are some of the things that I learned while setting up WordPress multisite.
1. It’s simple to split your export files properly
There used to be a joke about the WordPress’s “famous five minute installation”. What they didn’t tell you was the fifty minute long upgrade process.
Back in the early days moving host — and sometimes even simply upgrading to the latest version — required getting your hands dirty by working directly with the database via phpMyAdmin. Ick.
Thankfully, those days are now long gone with one-click upgrades.
Importing your content is also easy-peasy with the built in export tool. All of your content can be downloaded as a special type of XML file called WordPress extended RSS, or WXR.
The problem comes when it’s time to import that into your new environment. Most hosts will restrict your upload size. For me, the maximum import file size is 1MB.
But of the six sites I have moved across, only one of them had an WXR file that small.
The solution? WordPress Codex advises you to split up the file into multiple separate files. But that requries great care. And when you are dealing with six WXR files that are up to 24MB large, you can quickly lose the will to live.
Thankfully there is a fabulous tool called WXR Splitter that does it all for you.
It’s easy to use. You simply tell it what your maximum file size should be, and point it at your WXR file. It then automatically generates smaller WXR files for you to individually import into your new site. Job done.
2. Links are now hidden by default
This made me feel old. The links manager was always a core part of WordPress. It was the standard way for adding a blogroll to your sidebar. Blogrolls were such a fundamental part of what blogs were all about.
Now the link manager is hidden by default in new installations. This is a measure of how much both blogging and WordPress have changed in the past decade.
Is blogging dead? You bet. WordPress considers the once-ubiquitous blogroll to be such a fringe feature that it hides it away.
Meanwhile, WordPress has grown from being a hardcore blogger’s tool to the user-friendly content management system of choice for almost a quarter of the web.
@DuncanBSS Just put add_filter('pre_option_link_manager_enabled', '__return_true'); into functions.php to enable it.
— Heather Burns (@idea15webdesign) February 18, 2016
Links are not included in the WXR export file, so I had to manually add them all back in again.
3. Multisite bans some HTML by default
This is a gotcha that took me a while to notice. Some HTML is outright banned by default in WordPress multisite through a function called kses.
The security and sanity reasons for wanting to strip out certain types of code are obvious, particularly on multisite. But given that this includes common parts of the modern web such as YouTube videos embedded via iframes, I would have liked it to be clearer that was going to happen.
To put the videos back into the content, I had to delete everything I had imported and start again. But not before I had tweaked some code (in core, naughty me) to disable the kses filter.
If you trust all of the users in your multisite instance, Automattic have created the Unfiltered MU plugin. This restores the ability to add the banned HTML.
4. Bulk deleting posts is easy with care
When it came to deleting the content so that I could start afresh without completely reinstalling WordPress, I dreaded having to delete page after page of posts. Nor did I want to touch the database — I’m too old for that.
Luckily, there is a wonderfully powerful plugin called Bulk Delete. Obviously when you are using a plugin with two scary words like “bulk” and “delete” in such close proximity, you must take great care. But this did the trick for me beautifully.
5. Image paths are different in multisite
This is another one that caught me out. Because multisite necessitates media files being stored in a different path (with a subdirectory for each subsite), links to your images will break after you have imported the content.
I had assumed that the default htaccess code would sort this all out. But seemingly not.
For this, I needed to use yet another scary but useful plugin: Search & Replace. This enables you to do a search and replace across all posts on your site without having to touch the database yourself.
Again, it’s a scary concept, but I found the plugin to be idiotproof. It allows you to do a dry run first to double check you aren’t doing it wrong. Then it gives you an SQL file to download, then re-upload.
What had been a frightening prospect became a quick and easy job that I felt comfortable doing for each site.
6. Domain mapping is easier than you might think
The thing I was most worried about going into this project was domain mapping. In other words, despite moving all these sites into subdomains of my main site, I needed them all to still appear to the outside world as separate sites.
Domain mapping was scheduled to be part of core WordPress by now. But for the time being it still requires the use of the Domain Mapping plugin. Again it’s a scary idea. But I have had little trouble with it, and certainly nothing that wasn’t fixable with a little trial and error.
Yay for WordPress!
Also published on Medium.