Profile pictures are noticeably missing from WordPress profile pages in the dashboard. AP Gravatars is a new plugin that will add a user’s profile picture directly below the new password settings, exactly where one might naturally look for it.
It looks like a native part of WordPress, doesn’t it? I’ve tested it and it is fully multisite-compatible if you want to activate it across your network. Please note that this does not add gravatar support to your theme – it’s just a utility for your profile page. If the user doesn’t yet have a gravatar, the plugin displays a link to create one. This is very useful for new users who may not know how to add an avatar.
Download the free AP Gravatars plugin from the WordPress plugin repository.
Today we continue our semi-regular series of interviews with WordPress Multisite owners.
The following interview is with Mark de Scande, who runs BlogLines.co.za with his wife Charissa. BlogLines is a freemium-style site (free blogs with paid upgrade options).
Can you tell us a little bit about yourself before you got into running your site? What is your background in?
I was in the car audio trade years back. I was fitting sounds system, and so then I started selling car audio online. All was good until I got hit by a scam and got taken for R 30K (South Africa Rand).
Then I started to play with WordPress and started selling paint ball equipment online. Then I opened a shop in Port Elizabeth but closed it down about three years later. At that time I started my BlogLines site.
When did you start the site?
2008-09-28
Why did you start the site?
Needed to make money from Google Adsense (ha-ha).
Do you have other sites?
Lots. :) About 90 customer sites.
RUNNING THE SITE:
Do you run the site alone?
Yes (with my wife), but i have the power of WPMU DEV. :) love you guys.
How much time do you spend on it (per day/week)?
I am always on there. That is how I make money — keeping tabs on things.
How do you control splogs? / How much time spent? / Are they hard to spot?
Splogs? I love them as they make me money. I use ProSites to limit the number of posts. Then they have to upgrade, and yes they do.
I was wasting my time killing them, but now I know to work with them to make me money.
How do you deal with people posting unwanted content?
I only remove content if I get an email asking me, but if there is porn, they get banned for life.
Ever had issues?
Yes, some fat ass attorneys wanted to take me to court for their customer’s content. I just removed it, and the problem was solved.
How did you first attract people to the site when it was new?
Goolge Webmaster tools (it showed me where to look for more traffic), and I used some JUNK link software. I also used Google Adwords. Don’t waste your money, just keep working on your site. :)
How do you attract people to the site now?
I don’t. They just come as we have so much stuff listed on Google. It is easy. Just post something on BlogLines.co.za, and go google it. You will see it popping up on Google page 1. :)
And guess what — our Page Rank is only 3 with Google, but I guess content is KING.
What do you find works best for attracting new members?
Just post on your Facebook. It always works :)
NUMBERS
How many sites do you have on your install?
I have 79,355 sites and 76,388 users.
How many new sites do you typically see per day/week?
About 100 + per day
Have you seen the number of new members increase over the years per
day/week? If so, what would you attribute this to?
Yes, from 1 to 10 new sites and now about 100 + per day – not all paying, but here and there you get guys payinf $30 for their new sites per year.
Can you give us an idea about how much the site makes?
We also do websites for customers for $339, so about $50 per day. It is still a lot of money in South Africa. :)
Where do you find your customers for websites?
Through Facebook and friends of friends (99% of the site we do are customers of customers).
So at least indirectly you get your website customers through running BlogLines?
Yes.
So the sites you build for customers – are they separate from BlogLines, or do you just put them on the site and use domain mapping?
They are part of BlogLines, and then I use domain mapping.
Mark and Chrissa de Scande – The team behind BlogLines.co.za
FINAL QUESTIONS/ADVICE
What are some things you like best about running the site?
Love WordPress and love playing with new stuff from WPMU DEV.
What are some things you like least about running the site?
There is not a thing. I love it all. It is just hard work.
What advice would you give to someone that is thinking of starting a multisite? (Maybe the three most important things you would want to tell them.)
Interested in other interviews? Try the one with Harmony Coburn.
NOTE: If you run a successful Multisite install, or you know someone who does who might be interested in participating in an interview, then drop me a line at joe@incsub.com. Interviews are conducted by email, so you can do them at your convenience.
Ever made a long list of changes to your WordPress site and then something breaks and you have no idea how it happened? Perhaps you’re performing some routine updates, creating content and adjusting plugins all at the same time. You may not get an error that gives you any useful information. There’s a new tool that will help you to retrace your steps so that you can find the root of the problem.
The WP Changes Tracker plugin allows you to track changes to the WordPress core, network, plugins and options. It’s even multisite-compatible, so the network admin can track changes that happen on the network.
After you activate the plugin go to Settings > WP Changes Tracker to view the log. You can sort the log by user, time, type of change, and message.
Sorting by user can be especially useful so that you can track and communicate with the user who caused the problem in the first place. You can turn the sorting off if the log is too heavy and causes a performance issue. In the future the developer plans to add the ability to track theme changes as well, which will greatly expand its usefulness for troubleshooting problems with your installation.
Perhaps you’re a developer who performs regular maintenance for a client. If your client likes to play around in the dashboard, break things and then call you on the weekend, then you may want to consider setting up the WP Changes Tracker. Instead of spending an hour hunting around, trying to figure out where something went wrong, you’ll have a clear record of changes that have been made on the site or network.
Download the WP Changes Tracker plugin from the repository and get it set up as a safeguard on your most active sites.
Managing a very active multisite network can be fairly intense and time-consuming. Between answering user support emails and troubleshooting network issues, you also have to keep the core and all the plugins updated and in working order. Here are 16 plugins just released this year that will save you tons of time in managing your WordPress multisite network. Grab a cup of coffee and install all of your new favorites.
Class Blogs
Class Blogs is a plugin that simplifies the process of blogging as a class by making it easier to find, organize and analyze the work created by students. It comes with teacher admin pages, student admin pages, themes and tons of widgets to show recent student posts and comments.
AP Gravatars is a simple plugin that adds a user’s gravatar to his profile page. If the user does not have a gravatar account, the plugin will display a link to create one. It’s multisite-compatible so that you can use it across your network.
This plugin creates a workflow approval process within WordPress. If a user doesn’t have permission to publish a post, an email is sent to one of the approvers when a post is submitted to be published. It also works within multisite so that sub-sites can take advantage of the approval workflow as well.
Network Shared Media is a very useful plugin that lets you access media across the network through a new tab in the media library. This can be very convenient if you find yourself posting to multiple blogs or simply want to make a set of images or documents available to other users.
This plugin adds a Terms of Service agreement field on the multisite signup form, similar to the wordpress.com TOS field. It also supports localization so you can add your language file.
This plugin is designed for use in multisite networks where the same theme is used across all sites. After you have network enabled a new theme, you’ll get a new option to “Subsite Activate” the theme, which will apply it to every subsite on your network. This is very useful if you have lots of sites and don’t want to manually change each site’s active theme.
This is a pretty cool plugin that will show you a list of blogs with spam or unmoderated comments, which enables the the network administrator to manage the comments on all network blogs. It is recommended for use on small to moderate sized multisite installations.
This plugin provides a wedge between multisite and Akismet by globalizing the Akismet API key so it can be used across blogs. Multisite network blogs can then use the Akismet API key without having to configure each blog or edit any PHP files.
This plugin records all changes in user blog roles (wp_x_capabalities usermeta) across an entire WordPress installation. It can be a lifesaver to have installed if you find yourself having to troubleshoot mysterious role changes within your multisite network.
Blog Copier is a very handy plugin for multisite network admins. It enables you to copy a blog, including all its widgets, template settings and more. You can elect to copy or not copy the files. GUIDs and URLs in post contents are automatically migrated for you so you don’t have to manually change anything!
The Dead Blogs plugin lets you filter blogs, based on specific criteria in order to sort out which blogs are dead. You can locate the blogs by when they were last updated, number of posts, number of pages, or whether or not the blog uses the default theme.
Multisite Robots.txt Manager lets you manage all Network Websites robots.txt files directly within the Network Admin. Each Website within the network is able to have a unique robots.txt file. You can also instantly add Sitemaps URLs to all network websites and mass update the entire Network or individual site.
TuKod MultiSite Site Names overrides the normal restrictions that WordPress places on site names. This plugin gives you expanded site name choices in the multisite sign-up process. It enables you to use dashes (-), dots(.), tildes (~), underscores (_), capitals (A-Z) and even change the minimum length.
WP Changes Tracker is a very useful plugin that logs changes made to your WordPress structure: core, network, plugins and options. In the near future it will also log changes to themes. These logs are only available to the network admin when used in multisite.
This new plugin lets you move posts in a category and/or a page hierarchy to a subsite, while implementing seamless redirects. You can actually move content to another site on your WordPress network with a single click.
This is a plugin that nearly every WordPress multisite installation can benefit from. It adds columns to your network admin to show which sites are using each plugin and theme. It will help you know which plugins and themes are in use and which can be safely removed without affecting your subsites.
When managing a Multisite network, the menu items you need need the most are usually a couple clicks deep. The Multisite Admin Bar Tweaks plugin makes those important menu items more accessible. It adds the network ‘Plugins’ and ‘Install Plugin’ links to the ‘My Sites’ > ‘Network Admin’ menu within the site admin bar.
In the future the plugin developer plans to add in options for the user to select which admin bar links to show or not show. If you’re a network admin who could benefit from having these extra links in the admin bar, download the Multisite Admin Bar Tweaks plugin from the WordPress plugin repository.
Advertising can be a great way to monetize your blog, and if done the right way, it can even enhance your design, rather than stick out like a sore thumb. Whether you run a single blog or a multi site with thousands of members; and whether you run Adsense campaigns or sell your own ad space – these plugins will help you create, manage, and place ads anywhere on your site.
Widget Ads
Widgets have traditionally been the most popular place to put advertising on blogs. WordPress makes adding widgets extremely easy, code-free, and, for most, the sidebar widgets repeat through the blog across every page and post, thereby giving the ad maximum exposure.
Ad Widget Plugin Makes Advertising Easy!
Ad Widget
Ad Widget from WPMUDEV is a quick and easy way to place ads in widgets anywhere on your site.
You can change what the widget displays based on whether your visitor is logged in or not, and whether he reached your site via a link, a search engine, or even depending on the browser he uses.
WP 125
WP 125 plugin allows you to create your own ad banners and buttons and place them inside your sidebar and widgetized areas. You can set click-through links, track conversions, and even set the time period that ads run on your site. It offers reminders when ads need to be rotated or when they are expiring, and statistics that can be tracked via the WordPress dashboard.
Post and Page Ads
Ads that run inside posts and pages are also popular options, and many claim these ads outperform ads placed in widgets. A good post and page ad plugin allows you to easily place your ads throughout your content, not just before it or after.
In Post Ads
The In Post Ads plugin allows you to create your own ads right in your WordPress admin panel and place them throughout your post content. You can see In Post Ads in action here on this post and in the picture shown below. With In Post Ads, you can control the number of ads that run, the order in which they are displayed, and even paragraph spacing in your content.
Ad Rotate
Ad Rotate is a great plugin that allows a multitude of customization features for advertising on your blog. With it, you can show ads in posts, pages, and widgets; group blocks of ads, track conversion and click-through rates, even assign ad space to advertisers. The plugin also helps you keep your ads organized with a dedicated folder for a banner graphics, and the ability to weed out false clicks.
Pop-up Ads
Spammy pop-ups have been the bane of many a web viewer, and an attention-getting traffic tactic which has been abused for too long. In fact, every internet browser on the market has built-in functionality to eliminate or block pop-ups. But pop-ups with a catchy heading, teasing content, and an offer that can’t be refused are great additions to your site, and a fantastic way to promote content or products.
Pop Up Plugin is slick!
Pop Up!
Pop Up! Plugin allows you to create pop up ads for your WordPress powered blog. It is an effective way to place paid advertising on your site, or simply to promote features of your own site like mailing lists, special offers, and individual posts and pages.
The plugin interface works by taking content from a post you create (including colors, graphics, and html) and popping that up on the viewers browser when they visit your site. You can set when the pop-up appears, to whom it appears (logged in or logged out users), and even control what pops-up based on your viewer’s geographical region. This is a great option for daily and local deal type sites! You can also give the viewer the option to hide the pop-up anytime she is on your site. It’s compatible with virtually every WordPress theme and works with BuddyPress and WordPress Multi site.
Multi Site Advertising
If you run a multisite blog, you can use the Ad Sharing plugin to offer your users a way to make money on their own blogs by running your advertising messages.
Ad content can be customized by you and/or the user, and be placed seamlessly in any user’s site installed on your network. You can even offer to split ad revenue with the user and track the finances directly through the WordPress admin panel.
Adsense Ads
If you have a Google Adsense account and are tired of hacking your theme template files to make them display where you want, there are several well-established advertising plugins that make placing Adsense blocks a snap!
Ad Injection
Ad Injection allows an amazing amount of customization for Adsense blocks, and other advertising sources too, including Amazon Associates, ClickBank, and TradeDoubler. You can insert into post and page content, control the number of adverts based on the post length, and even restrict who sees adverts by post age, visitor referer and IP address. There’s support for A:B split testing / ad rotation which can help you improve ad copy and the ad’s overall conversion and click-through rates. It also works with WP Super Cache, W3 Total Cache and WP Cache to help keep your site running smoothly and efficiently.
Easy Adsense
Easy Adsense allows you to post your Adsense blocks in posts, pages, sidebars, and widgets. You simply paste your Adsense code into the plugin and it does the rest for you!
Google Adsense Plugin
The Google Adsense Plugin goes a step further than Easy Adsense, and allows you to edit your Adsense blocks within WordPress with the ability to choose color scheme, layout, and the number of ads which run per page.
Summary
If you’re just thinking about adding advertising to your blog, start small and watch your statistics to see what is working and what needs to be removed. Don’t over-burden your site with flashy graphics and animated logos if you think it will put-off your readers. The viewership you lose may outweigh the monetary gain you find with paid ads.
WordPress Multisite admins are often looking to share content across sites throughout the network. There’s a reason all of these sites are connected and oftentimes it is to share more than just the WordPress core and plugins. Network Shared Posts is a new multisite plugin that will enable admins to share posts via an easy-to-use shortcode. You can add the blog IDs for the sites you want to include, as well as specify the categories, tags, number of posts, thumbnail images size, and more.
There’s a full list of available shortcode attributes on the plugin’s FAQ page.
The Network Shared Posts plugin is excellent for multi-level networks that contain a great deal of related content. For example, you might add it to your network if you have a ‘state’ site that includes its own posts and then aggregates posts from ‘city’ level sites. So an example oklahoma.com site can collect posts from tulsa.oklahoma.com and okc.oklahoma.com for displaying on the main site, with a mix of categories and tags to create a custom display.
Download Network Shared Posts from the WordPress plugin repository to start sharing content across sites within your multisite network.
If you’re new to WordPress Multisite, then you may not be familiar with the Network Admin menu. The WordPress Super Admin user has access to all of the sites on the network. This is done through the Network Admin menu.
If you’ve correctly enabled multisite on your installation, then you’ll want to look for the “My Sites” menu:
This is where you will find the Network Admin menu, which includes everything you need to administer your network.
The difference in dashboard menus can be rather confusing to new multisite admins, especially since the location of the network admin menu has changed over the different versions of WordPress. After you work with multisite for a little while you’ll get the hang of the new menu structure and it will become second nature to you.
Are there any basic questions about multisite that you may have been afraid to ask? Feel free to jump in on the comments.
WordPress multisite has some restrictions for what types of files users can upload on the network. Fortunately, there’s an easy way to make changes to the allowed file types without having to add a plugin or change any code.
This particular network admin setting is a few clicks deep. You can find it under:
Scroll down to Upload Settings and add or remove file types from the “Upload file types” field.
This is probably a section you’ll want to configure before opening your network up for registration. Add as many file types as you feel comfortable hosting for your users. You can also change the maximum upload file size on the network settings page.
For more information on managing your WordPress multisite network check out our WordPress Multisite Manual. The manual is a handy reference to bookmark if you’re just getting started creating and managing multisite networks.
When navigating a WordPress multisite network, it’s important to note that users of one site are not automatically made users of other sites across the network. Ordinarily, users have to complete the regular registration process with each site they want to join.
Mika Epstein, otherwise known as Ipstenu, is a prolific multisite plugin developer. She recently released Join My Multisite. This is a brand new plugin that makes it easy for users across a multisite network to join each other’s sites. After network activating the Join My Multisite plugin, each site admin will have three new options for new memberships on their own sites:
Auto-add users – any time a logged in user visits a site, they will be automatically added to that site
Have a ‘Join This Site’ button in a widget
Keep things exactly as they are
Have a look at the settings page:
In addition to the new membership options, site admins can also automatically assign new members a specified user role, using the dropdown menu on the plugin’s settings page.
The membership options determined by this plugin are also available through a widget that each admin can easily drop into any widgetized area of their WordPress theme.
If one of your site admins has registration turned off, this plugin will not affect that. Visitors will not see the ‘register’ button.
As the network admin, you may understand the ins and outs of how WordPress multisite networks work, but visitors more than likely have no idea, especially if the sub-sites are well connected and themed to be similar to one another. They may not understand that they are not automatically members of the other sites. That’s where this plugin is very useful. It lets you eliminate that point of confusion by giving site admins the option to automatically add new visitors as users. Another benefit is that it helps to prevent your networked sites from getting too fragmented and isolated from one another. Download Join My Multisite for free from the WordPress plugin repository.
If you manage a WordPress multisite network where you, as the admin, set up each site individually, there’s a new plugin that should save you quite a bit of time. NS Cloner – Site Copier gives multisite admins the ability to easily clone individual sites in your network within a matter of seconds.
The plugin, created by the folks at NeverSettle, is billed as “the easiest, fastest, and most user-friendly way you will ever create fully configured sites on your multisite networks.” It takes any existing site on your WordPress multisite network and clones it into a new site. The new site is an exact copy of the theme, theme settings, plugins, plugin configurations, content, images, videos and site settings.
So simple, a monkey could use it!
Despite how powerful it is, the plugin is not complicated to use. As you can see from the settings page, it includes a dropdown for you to select the site to clone and then a field for the new site name and title.
Please be advised that the Site Copier plugin is currently only compatible with subdomain networks. However, the developer is in the process of adding support for subfolder-based networks. Also, because this plugin works with your database, you’ll want to make a backup before trying it out on a production site.
If you’re a developer who uses multisite to organize your clients’ websites, the Site Copier can save you time in configuring new websites. If you have a standard set of plugins, widget settings, theme settings, etc that you regularly implement, you can create a template that you can use over and over again, instead of manually configuring each site. It’s also useful for setting up design and development testing sites with multiple versions.
Can you believe that the Site Copier plugin is free? Download it from the WordPress plugin repository.
When building a WordPress multisite network it can be challenging to find plugins that will be compatible across the network. Even functionality as simple as a contact form can have you hunting for hours for a plugin that will work properly with multisite. Since a contact form is one of the most common requirements for any website, we’ve put together a list of some of the most trusted plugins for use with multisite networks.
Contact forms 7 has been around for ages and is regularly updated. This plugin has been downloaded nearly 9 million times and is a favorite of our Facebook fans. The ContactForm7.com website has a ton of tutorials and documentation for using its many features.
Formidable is a free plugin with optional premium features and support. Its unique features include a simple drag-and-drop interface and in-place editing. The plugin is multisite compatible and if you purchase an unlimited Pro licence, you’ll have support for multisite and any other single site installations. You never have to worry about your network getting overrun with spam, because Formidable Forms integrates with reCAPTCHA and Akismet for spam control.
Gravity Forms is a longtime favorite plugin of many in the WordPress community. It is one of the most successful commercial WordPress plugins on the market and that’s because it does virtually everything you could ever imagine for forms to do. Gravity Forms includes an advanced form builder with settings for limiting entries, scheduling forms, adding pricing fields and much more. The developer license has support for WordPress Multisite and offers unlimited forms, entries and a host of other features.
The Jetpack plugin collection offers a built-in contact form that you can launch from the post editor. These contact forms are very similar to those you find on WordPress.com. Network activate Jetpack in order to make it available to all sites on your network.
The WPMU DEV Contact Widget plugin was made for WordPress multisite. Compared to other form plugins this one is ridiculously simple to use. It comes with built-in spam protection and options to choose the admin email, customize the success message and add custom CSS – right from the widget controls. You’ll never have to worry about compatibility issues because this plugin was designed for use with multisite and is easy to include in your new site templates to make sure that every blog owner has their own contact form.
This is one of those workhorse plugins that has been around for ages, quietly getting the job done. Fast Secure Contact Form has been downloaded more than 3 million times and is a favorite of many multisite super admins. It doesn’t have a super fancy interface, but forms are easy to edit. The plugin allows you to create multiple forms, set confirmation emails, optionally redirect visitors to any URL after the message is sent and includes many more features – all with no templates to mess with. Fast Secure Contact Form also includes CAPTCHA and Akismet support to block spammers.
This plugin is not as widely used as some of the others but it can certainly be used in a multisite environment. Custom Contact Forms have quite a lot of nice features for styling your form and customizing it to meet your needs. Features include required fields, captchas, tooltip popovers, unlimited fields/forms/form styles, file upload fields, the ability to use a custom thank you page or built-in popover with a custom success message set for each form. The plugin is well-maintained and new features are regularly added.
Are we missing any of your favorites? Let us know in the comments.
When it comes to the subject of privacy, more options are usually better. Bloggers and members of your site are more likely to trust and recommend your community if they know that they have the option to protect their content.
WordPress Multisite Privacy Settings
By default, WordPress Multisite has two site visibility settings under the Settings >> Privacy menu, both related to search engines:
Allow search engines to index this site
Ask search engines not to index this site
If you want more privacy options, it’s as easy as installing a plugin.
WordPress Multisite Plugin: More Privacy Options
If you want to make a site private within your WordPress multisite network, the easiest thing to do is install the More Privacy Options plugin, available for free in the WordPress plugin repository. This plugin has an excellent reputation and is updated regularly.
It adds three more privacy options to the Settings >> Privacy page in the dashboard:
Blog visible to any logged in community member – “Network Users Only”
Blog visible only to registered users of blog – “Blog Members Only”
Blog visible only to administrators – “Admins Only”
These powerful options give users the ability to use their site as a private place to record their thoughts or to limit the site to their blog members only. If the site owner trusts his content with the network at large, he can elect to have it viewable to other community members. The “Admins Only” setting is also very useful if you want to create a test site on your network for experimenting with new themes or plugins.
Additional features include:
Mulitsite Network Admin can set an override on blog privacy at “Network Visibility Selector” on Network Settings page
Multisite Network Admin can set privacy options at Network-Sites-Edit under “Settings Tab” as well
Network Admin receives an email when blog privacy changes
RSS feeds require authentication
robots.txt updates accordingly
Ping sites filters correctly
Privacy status reflected in Dashboard “Right Now” box
Uses WP3+ functions auth_redirect(), network_home_url(), and home_url() for SSL login redirects
Login message has link to sign-up page of a “Network Users Only” blog or a link the blog admin email if user is logged in but not a member of a “Members Only” blog
If you want to create a completely private multisite network or just want to offer more fine-grained privacy controls to site admins, the More Privacy Options plugin is your solution. This is a multisite tool worthy of being added to your favorite plugins list on wordpress.org.
Even the average user can see that WordPress is a powerful and flexible platform. But there’s more to WordPress than meets the eye.
Just below the surface, and somewhat hidden away, there is an even more powerful mode that WordPress possesses – a mode called Multisite.
Enabling this mode allows you to turn a single WordPress installation into a network of sites. Thousands of sites, if you like. Hundreds of thousands. Even millions.
While that may sound like an exaggeration, it’s not. As an example, you can simply look at WordPress.com or Edublogs.org. They both contain in the millions of sites. And they both run on Multisite.
An Introduction to Multisite
While not for the average user and not something everyone will need, Multisite may be just what you’re looking for if you have a situation that requires a more robust approach than a single WordPress install allows for.
Our hope here is to give you an overview of what Multisite is and to help you decide if it might be right for you.
We’ll cover the following:
Why Run a Multisite Network
Is Multisite for You?
Examples of Multisites in the Wild
When Not to Use Multisite
Advantages and Disadvantages
WPMU DEV Multisite Plugins
Differences from Regular WordPress
BuddyPress
Resources
How to Activate Multisite
What Exactly Is Multisite?
Different sites in the network.
Multisite is a feature (or a mode) within WordPress that allows you to run a number of different sites from one WordPress installation.
All the sites in the “network,” as it’s known, will share all the same plugins and all the same themes.
(Note – with special plugins like Pro Sites from WPMU DEV, you can control access to plugins and themes – for example, allowing User A access to all plugins and themes but allowing User B access to only a few of the installed plugins and themes. You can also do this in a more limited way with the out of the box version of Multisite.)
All the sites also share one database; however, they do have separate tables within the database, and they also each have their own directories for media uploads.
Why Run a Multisite Network
There are different reasons why you may choose to run Multisite. Below are a few of the most common.
1. Host Sites Open to the Public
Open to the education-based public.
One of the most common reasons for running a Multisite Network is to allow users to sign up for their own blogs/sites, as sites such as wordpress.com and edublogs.org do.
Multisite can be set up to allow users to create a new site automatically with no extra work needed from the administrator. Typically new blogs will reside at a URL that looks like one of the following:
site1.mysite.com
mysite.com/site1/
The difference here is the difference between setting up sites as subdomains or subdirectories. (More on this later.)
Using Multisite in this way could work in many niches — for example, giving users their own sites so they can blog about gardening, surfing, dieting, traveling, music, education, etc., etc. The list really is nearly limitless.
2. Host an In-House Network of Sites
Another common reason for using Multisite is when one person or one organization would like to run a number of different sites from one installation, thereby making it easier to update plugins, themes, and WordPress itself. When all your sites are on one installation, it also makes it easier to access the Admin areas of different sites from one main control panel.
Here are a few examples of when this type of Multisite network might be ideal:
Different schools in a school district
Different departments in a company/university/newspaper/etc.
Different teams in a league
Different stores/branches in a chain
Different cities in a state/country … Different countries in the world
Different events in a location (e.g. festivals, concerts, etc.)
Different shows on a radio station
Is Multisite for You?
With all those “differents” above, however, you should ask yourself an important question: Do I really want these sections/sites to be different?
In other words, can I just use “categories” on a regular WordPress install and achieve the same thing?
If you can say YES to any of the following below, then you Multisite may be the way for you to go:
Do I need a different themes on the same site?
Do I need different plugins/functionality for different sections?
Do I need to give access to different administrators/editors for the different sections?
Do I need different top level addresses (e.g. mapping colors.com/red/ so that resolves to red.com)?
Examples of Multisites in the Wild
Below are a few Multisite we’ve found out in the wild. You can browse some more for yourself at the WordPress.org Multisite Showcase section.
WordPress.com– Open to the public. It is the largest Multisite-based site on the web.
Edublogs.org– Open to the public, but limited to educational purposes. This site, run by the same company that runs wpmu.org and wpmudev.org, is the second largest Multisite example on the web.
Reuters Blogs– Contains a different site for each writer. While it looks like each writer simply has a different “section” from the frontend, in the backend they would actually have their own blogs. In this way, one writer cannot access another writer’s Admin area.
Tradr — A site that provides commercial platforms with integrated marketing tools.
BBC America – Presumably, each show is a different sub-site. While this can be done with categories, it probably makes more internal sense for the BBC to silo off each show into its own backend. This way those with permissions on one site don’t necessarily have permission on another site.
Teatra– A “social marketplace“ for people to buy and sell tea.
Yacht Blogs – Open to the public. For all those interested in yachts.
Mission’s Place – Run by our own Aaron Edwards, this site is open to missionaries.
When Not to Use Multisite
If you don’t need to use Multisite, then it’s probably better not to activate it. While it might not make much of a difference one way or another, there is a chance that you might run into some issues that you don’t really need to deal with.
Don’t use Multisite if …
categories will do
you need different user databases (for special security reasons, for example)
users need to install their own themes or plugins
Some argue that you shouldn’t use multisite if you’re running small client sites. When asked why, most will end up saying that it’s just “cleaner.” And by that they mean that because you have totally separate databases with single installations, it’s easier to transfer the site somewhere else if needed.
Importing/Exporting Sites
That said, you CAN “peel off” a site from a Multisite network by using the Import/Export functions native to WordPress. If you would like to take a site from your Multisite network and turn it into a single installation, then do the following:
Set up a new install as you normally would
Export the networked site’s content with the Export function
Import the site’s content to the new single installation
OK, so we’ve somewhat hit on the advantages and disadvantages of using Multisite in different ways already, but let’s go ahead and list some out here in a more direct way and maybe touch on a few we haven’t gotten to yet.
Advantages
Automatic site/blog creation for any user
Automatic blog creation for a limited set of users – e.g. restrict by email or with a special code (need a plugin for the special code – see below)
Unlimited site-creation for one user
Limited site-creation for one user (with a plugin – see below)
Limit the amount of uploads (or make it unlimited)
Different themes on different parts of your site
Changes to a theme will apply to that theme on all the sites that use it
Users still have the ability to place things such as widgets, menus, headers, and backgrounds onto their sites, regardless of their theme (to restrict this, see plugins below)
Users can create and manage multiple sites (or restrict them to one with a plugin – see below)
Sites can be completely separate from each other, or they can be integrated in a number of ways
Activate themes on a site-by-site basis
Disadvantages
While not “difficult,” it does require the admin to learn how to manage the network, which is a little more involved than a regular WordPress install
You need access to your server – must be able to edit core WordPress files
Some themes don’t always work so well with Multisite (most do, but I’ve run into some that don’t)
Some plugins might not always work so well (again, as above, most do)
If you have problems with the core installation, or the main site gets hacked, then all sites in your network may be affected
While it’s possible to tie sites together, it is a little more difficult to display content from various sites onto the main homepage, for example. But it’s not impossible. WPMU DEV plugins will help you do that.
WPMU DEV Multisite Plugins
As with regular WordPress, a lot of the limitations you find with an out-of-box install can be overcome with plugins.
As most everyone who’s bothered to look into it knows, WPMU DEV is THE site on the web for Multisite plugins. There are literally too many to go over here. But will give you a quick rundown of a few things you can do with DEV Multisite plugins.
Pro Sites — Offer upgrades and charge users, like WordPress.com or Edublogs.org, offering your users premium themes, premium plugins, extra storage, advertising, domain mapping and more.
Anti-Splog– Stop spam blogs (splogs) from registering on your network and taking the whole thing down the toilet.
New Blog Templates – Create a template blog (or many!) and then duplicate every single setting (content, theme, categories etc.) for every new blog.
Domain Mapping– Let users use their own domain names for their sites. For example, turn site1.mysite.com into simply site1.com.
Multisite Analytics – Offer users individual stats for their sites through Google Analytics. At the same time, get site-wide stats for yourself.
Site Categories – Create site categories for your whole network.
One of the main differences you’ll come across is the role of Super Admin. As the Super Admin, you control the whole network. That means you decide things such as which plugins are available, which themes are available, whether just anyone from the web can sign up and get a site, or whether you’re going to restrict your network.
As the Super Admin, you have access to the whole network.
The Super Admin will have access to a backend for the entire network, a backend for the main blog on the site, as well as the backend of any other blog created for the site.
Navigating between these different backends may get a little confusing at times, and it may be a little difficult to figure out where you need to go in order to control something that you want to control, but other than some slight frustration, this is not really such a problem for someone determined to run Multisite.
Of course you will also have different choices to make when you set your site up. For example, will you allow public registration? If so, you’ll likely need to look into plugins like Anti-Splog, which will help you control spam blogs (splogs).
You will need to think deeply about what you want to give your users access to. Some things may be easy to cut off. Others will require finding the right plugin.
Finding the right plugins, whether they’re security plugins or plugins that help you display content more flexibly, will allow you to truly make your Multisite install work the way you envision.
Managing Plugins and Themes
As mentioned, you will have need to control which plugins and themes are available to your users. Maybe you would like everyone to use the same theme. Maybe you’d like to give users a choice. It’s up to you.
You can also manage theme choice on a site-by-site basis, giving certain sites more choices, or picking and choosing one theme for one site and another theme for another site.
As a Super Admin, you can go into sites on a case-by-case basis as above and set the themes for that site.
While none of the above is particularly difficult once you get the hang of it, it should be noted that being a Super Admin for a Multisite install is different from being an Admin for a regular WordPress install. And there is a learning curve. If you struggle with a single WordPress install, then you may want to become more comfortable with the basics before moving onto Multisite.
BuddyPress
BuddyPress is essentially a giant plugin that lets you create a fully-formed social network for users of your site.
While you don’t need to run Multisite to use BuddyPress, and you don’t need to run BuddyPress if you’re running Multisites, many sites using Multisite do use BuddyPress.
Of course it all depends on what you want your Multisite to do for you. If you’re looking to tie all the different users in your network together, then BuddyPress is a good option for you.
For some Multisite installations, however, tying everyone together is the exact opposite of what you want.
All that said, BuddyPress is really a whole ‘nother ball of wax. But we thought we’d at least mention it here as something worth considering if you’re thinking about starting a Multisite Network. (See our BuddyPress section.)
Resources
Below are a few resources that you will absolutely want to consult if you plan on running a Multisite Network.
And finally, we’ll get into actually activating Multisite.
Although Multisite is a feature of all WordPress installations, you will still need to activate it before it is visible. As mentioned in the very beginning, it is hidden away from the casual user.
Before moving onto any instructions, you should know that you are most likely going to need to choose between setting up new sites as subfolders or subdomains. And so let’s go over that quickly.
Subfolders and Subdomains
Little works as well as an example, so let’s start with a few examples.
You’ll need to think about how you want your network set up.
Subfolders look like this:
mysite.com/site1
mysite.com/site2
Subdomains look like this:
site1.mysite.com
site2.mysite.com
Depending on exactly how you’re setting things up, some of you may not have a choice. For example, if you try to activate Multisite on a site that is ALREADY in a subfolder, you will only have the choice of setting up more subfolders.
For example, let’s say your site titled “mysite” is located here:
example.com/mysite/
You’re new sites will then be added on as additional subfolders:
example.com/mysite/site1/
example.com/mysite/site2/
Some people may run into problems with their server when trying to set up sites as subdomains (e.g. site1.mysite.com). If you have an upgraded hosting account (such as a virtual private server account, for example), you may be able to call your webhost and get them to help you out with it. If not, you’ll just have to go with subfolders.
Which is Better?
This is a personal preference. If you’re trying to set up a public blogging site like wordpress.com, for example, some believe that it’s more attractive to users to have the name of their site first – e.g. site1.mysite.com.
At least in the old days of SEO (I’m not sure anymore), it was said that having subfolders (e.g. mysite.com/site1/) was slightly more attractive to the search engines.
Once you choose, there’s really no turning back, however. So just pick one and don’t worry about it anymore.
Domain Mapping
With a domain mapping plugin, you can make it seem as if your Site1 site or your Site2 site is just a single install of WordPress.
For example, mysite.com/site1/ or site1.mysite.com can be made to resolve to the domain site1.com. No one will ever know the difference.
Even users in the admin area will not know they are on a multisite network if you don’t want them to. Their admin dashboard will appear at site1.com/wp-admin/ just like any regular WordPress site.
Turning on Multisite
Activating Multisite is not difficult, but it requires more than simply clicking a button or two. You should know that you will need access to the core WordPress files on your server.
One of the most common questions about using WordPress Multisite is, “Can I import an already existing site into Multisite?”
Similarly, another common question is, “Can I peel off a site on a Multisite install and turn it into a single installation?”
The answer to both of these questions is yes, and we’re going to go through how to do that in this post. Essentially it’s as easy as using the Import/Export functions found under the Tools menu in your WordPress admin area.
What Gets Imported
While WordPress will import most things from one site to another (such as users, posts, pages, categories, media files, and more), it won’t import everything.
More specifically, it won’t automatically import your plugins or themes. It also won’t import some of your settings, things such as your permalinks structure, the title of your site, or your timezone settings. You’ll have to go into your new site and set these things up again.
The following table should help you keep track of what will and won’t get imported automatically for you. The order follows the menu order that will find in your admin area; however, you can sort the table how you like.
Menu Items
Import - Yes/No
Posts
Yes
Categories
Yes
Tags
Yes
Media
Yes
Pages
Yes
Comments
Yes
Themes
No
Widgets
No
Menus
Yes
Header
Yes and No* (see below)
Background
Yes and No* (see below)
Plugins
No
Users
Yes
User Roles
No (all users will be subscribers by default on the new site)
User Passwords
No (you must update all user passwords)
Settings
No (nothing in the Settings section will be imported)
* WordPress will import any media files (e.g. header image or background image), but it will not automatically apply those images. It will not import the settings for colors – e.g. if you have set your background as a certain color, it will not import those settings.
We have both a video of the process and a detailed step-by-step text tutorial for you. Here’s the video.
Exporting a Site from a Single Install and Importing It to a Multisite Set Up
I. Exporting Your Site
Go to Tools > Export, choose what you’d like to export via an XML file, and then hit “Download Export File.”
You’ll save this file onto your computer and then import it into the new site.
II. Importing Your Site
Some of the information below about usernames can get a little confusing. However, the nice thing about Multisite is that you can add and delete sites at will. If things get too confusing and consequently get a little messed up, you can always delete a newly created site and then start over.
With that said, let’s get into it.
Step 1. Set up a new site on your Multisite install.
Go to My Sites > Network Admin > Sites > Add New
* IMPORTANT * The name of the site URL you put in the Site Address box will also become the name of the default administrator for that site. For example, if you make the site’s URL “xyz.example.com,” the name of the default administrator for that site will be “xyz.”
* However, there is an exception to this. If you use the email address of a user already registered on the Multisite install, then the admin will take the name of that user.
The Username “Admin”
Many people use the name “admin” as the name of their administrator. However, as the name “admin” might already be taken by the Super Admin on the Multisite install, you will not be able to name your new site administrator “admin,” even if that was the name on the old site. (We’ll deal with overcoming this later.)
If, however, you are using the same email address as the Super Admin of the Multisite install, and the Super Admin has the username “admin,” then you can choose to assign the posts to that user, and it will appear that posts are still authored by the user called “admin.”
Step2. For the Admin’s email address, you can put in the email address of your admin on your single install. If you will be running the site yourself, of course you can put in the email address for the Super Admin.
Step 3. Click “Add Site”
Step 4. Go to the Dashboard of the site you’ve just created. There should be a convenient link that says “Visit Dashboard” right on the page that appears after creating a new site.
You can also access the site by going to My Sites > Network Admin > Sites.
Step 5. In the Dashboard of the newly created site, go to Tools > Import.
The last option on the list should be the WordPress option. If you haven’t yet installed the importer plugin on your Multisite installation, you will see the following beside the WordPress option:
This importer is not installed. Please install importers from the main site.
(If your importer is installed – i.e. if you do NOT see the link above — you can skip directly down to Step 12.)
Step 6. Click that link.
When you click it, the system will take you back to the Network Admin section (i.e. out of Dashboard for your newly created site).
Step 7. Click on the “WordPress” link.
Step 8. This will bring up a popup to install the plugin. Click “Install Now.”
Step9. Then click “Network Activate.”
Step 10. You’ll now need to navigate back to the Dashboard of the newly created site. (My Sites > Network Admin > Sites)
Step 11. Once in the Dashboard, again go to Tools > Import.
Step 12. Click on the WordPress link in the list in order to upload the file you saved onto your computer.
Step 13. Browse for your file and upload it.
Step 14. In the next screen, we’ll address the problem of having an administrator on the single installation named “admin.”
As mentioned, if the Super Admin for the entire network has the username “admin” (or if anyone else in the network does), then you will not be able to create a new user on the new site named “admin.”
Also as mentioned before, when you add a new site to the network, then the site name (or actually the URL name) is automatically created into a user on that site, and that user is the default admin. So, if your new site’s URL is xyz.example.com, then you will have a user with the name “xyz,” and that user will be the admin for your that new site.
You can see below that I am beginning to import the XML file from my single installation. On that single site, I had two users – one was named “admin,” and the other was named “singleuser.”
You will also see an option that says “or assign posts to an existing user …” and then it has a dropdown box.
What you’ll want to do is to assign the posts from the user on the single site named “admin” to the new admin for the new site — the user “xyz.”
(Of course you can also make up another user on the site before you import this file and assign the posts to that user. You can also use an email address already associated with a user on the Multisite install.)
Step 15. You’ll also want to download and import file attachments. Then hit “Submit.” (see graphic above)
And that’s it. You should now have your site imported, and the “admin’s” posts from your single site should now belong to the default admin for the new site (in our example, the user “xyz”).
* Remember to update the passwords and roles of imported users. Also the new blog you set up will have the default sample page and first sample post (“Hello World”). You’ll need to delete those.
Exporting a Site from a Multisite Set Up and Importing It to a Single Install
Install a single version of WordPress where you’d like before beginning this process.
Step 1. Go to the Dashboard of the individual site (on your Multisite install) that you wish to export. Then go to Tools > Export.
Export the XML file for that site, and save it on your computer.
Step 2. Choose what you wish to export, and click the “Download Export File” button.
Step 3. On the Dashboard of the single version of WordPress (i.e. the single install), go to Tools > Import.
The WordPress option should be the last option in the list. If you haven’t installed the importer plugin yet, you will need to do so now. Clicking on the “WordPress” link will automatically bring up an installation screen.
Step 4. Browse to the XML file that you saved on your computer in Step #1, and upload it.
Step 5. You can decide if you need to assign posts to a different user or not.
If you need a more detailed explanation of this, then begin reading from Step #1 in the section above titled, “Exporting a Site from a Single Install and Importing It to a Multisite Set Up.”
When you’re ready, click submit.
* Remember to update the passwords and roles of imported users.
* Also remember, if you have problems when you import your file, you can always go through, delete everything imported (posts, pages, images, users, etc. – everything that’s been imported) and then reimport the file.
Assign Posts to a New User After Importing
If you would like to assign posts to a different user after importing your content, follow the instructions below.
Step 1. Go to Posts > All Posts.
Then click on the username of the author whose posts you’d like to change to a different user.
(In this example, I’m going to change posts of the user named “singleuser” to be assigned to the user named “xyz.” )
Step 2. In the next screen, you will have a list of all the posts made by that author. You can then either click the “Select All” box at the top of the post grid, or you can select individual posts as you like.
Step 3. In the pull-down menu at the top, select “Edit,” and then click the “Apply” button.
Step 4. Next, under the “Categories” column you should now see an option to select a different author through a pull-down menu.
Select the author you’d like, and then click update.
And that’s it. The author of those posts should now be changed.
That’s It
And so that’s it. Though it may get a little confusing with the usernames, just remember to assign posts to users already on your site, and that should make things simpler.
Managing a very active multisite network can be fairly intense and time-consuming. Between answering user support emails and troubleshooting network issues, you also have to keep the core and all the plugins updated and in working order. Here are 16 WordPress multisite plugins just released this year that will save you tons of time in managing your multisite network. Grab a cup of coffee and install all of your new favorites.
Class Blogs
Class Blogs is a plugin that simplifies the process of blogging as a class by making it easier to find, organize and analyze the work created by students. It comes with teacher admin pages, student admin pages, themes and tons of widgets to show recent student posts and comments.
AP Gravatars is a simple plugin that adds a user’s gravatar to his profile page. If the user does not have a gravatar account, the plugin will display a link to create one. It’s multisite-compatible so that you can use it across your network.
This plugin creates a workflow approval process within WordPress. If a user doesn’t have permission to publish a post, an email is sent to one of the approvers when a post is submitted to be published. It also works within multisite so that sub-sites can take advantage of the approval workflow as well.
Network Shared Media is a very useful plugin that lets you access media across the network through a new tab in the media library. This can be very convenient if you find yourself posting to multiple blogs or simply want to make a set of images or documents available to other users.
This plugin adds a Terms of Service agreement field on the multisite signup form, similar to the wordpress.com TOS field. It also supports localization so you can add your language file.
This plugin is designed for use in multisite networks where the same theme is used across all sites. After you have network enabled a new theme, you’ll get a new option to “Subsite Activate” the theme, which will apply it to every subsite on your network. This is very useful if you have lots of sites and don’t want to manually change each site’s active theme.
This is a pretty cool plugin that will show you a list of blogs with spam or unmoderated comments, which enables the the network administrator to manage the comments on all network blogs. It is recommended for use on small to moderate sized multisite installations.
This plugin provides a wedge between multisite and Akismet by globalizing the Akismet API key so it can be used across blogs. Multisite network blogs can then use the Akismet API key without having to configure each blog or edit any PHP files.
This plugin records all changes in user blog roles (wp_x_capabalities usermeta) across an entire WordPress installation. It can be a lifesaver to have installed if you find yourself having to troubleshoot mysterious role changes within your multisite network.
Blog Copier is a very handy plugin for multisite network admins. It enables you to copy a blog, including all its widgets, template settings and more. You can elect to copy or not copy the files. GUIDs and URLs in post contents are automatically migrated for you so you don’t have to manually change anything!
The Dead Blogs plugin lets you filter blogs, based on specific criteria in order to sort out which blogs are dead. You can locate the blogs by when they were last updated, number of posts, number of pages, or whether or not the blog uses the default theme.
Multisite Robots.txt Manager lets you manage all Network Websites robots.txt files directly within the Network Admin. Each Website within the network is able to have a unique robots.txt file. You can also instantly add Sitemaps URLs to all network websites and mass update the entire Network or individual site.
TuKod MultiSite Site Names overrides the normal restrictions that WordPress places on site names. This plugin gives you expanded site name choices in the multisite sign-up process. It enables you to use dashes (-), dots(.), tildes (~), underscores (_), capitals (A-Z) and even change the minimum length.
WP Changes Tracker is a very useful plugin that logs changes made to your WordPress structure: core, network, plugins and options. In the near future it will also log changes to themes. These logs are only available to the network admin when used in multisite.
This new plugin lets you move posts in a category and/or a page hierarchy to a subsite, while implementing seamless redirects. You can actually move content to another site on your WordPress network with a single click.
This is a plugin that nearly every WordPress multisite installation can benefit from. It adds columns to your network admin to show which sites are using each plugin and theme. It will help you know which plugins and themes are in use and which can be safely removed without affecting your subsites.
Maybe you’ve had a talent for technology or design nearly all your life. Or maybe you just stumbled onto WordPress one day when looking to set up your own site. And then that one day led to another, and soon you were finding your way around the WordPress backend pretty well.
And then time and time again you started running into people who “wanted a website” but didn’t really have the first clue about how to build one. At some point it probably dawned you – Hey, I could make some money doing this.
But then you needed to actually get down into the weeds and figure out how you’d go about it.
This post hopes to help you with that “how to go about it” part — more specifically about how to run a business providing others with WordPress sites by using WordPress Multisite as your base.
Many others have done it. In fact, many are doing it right now. Why not you?
Web Host vs. Designer: Which is right for you?
The Structure of Your Business Model
First, there are two basic ways you might approach the services you offer. You can either be essentially a Web Host, as we’ll call it, or you can essentially be a Designer (while providing ongoing web hosting too).
We’ll use these terms “Web Host” and “Designer” loosely for convenience. In truth, to be an actual web host would be a little more involved than what we’re going to propose here (though you could still do it with WordPress with plugins like WHMCS MU Provisioning and WHMCS WP Integration). To be clear, however, those plugins are NOT necessary to do what’s outlined in this post. Also, we’ve chosen the term “Designer” here, but in reality, of course you’d be responsible for getting the whole site together, not just the design aspect of it.
Web Host
Web Hosts generally get more clients but at a lower price.
A Web Host (again, as we’re calling it here) lets anyone sign up to the Multisite installation. Maybe you’ll let them sign up for a free site and then charge for upgrades. Or maybe you’ll require payment even at the lowest level. While that might be a big marketing decision, as a technical decision, the two aren’t that different, thanks to the great plugins we’ll be talking about later.
Examples of the Web Host style would be WordPress.com and Edublogs.org. You can sign up for on those sites and then upgrade for more advanced features.
Markets for Web Hosts
There are different markets you might want to target, and so that’s a decision you’ll need to make. For example, you could go after only plumbers or roofers or lawyers. Or you could go after any type of business, of course. But specializing may help your marketing, and it would probably let you offer more complete solutions designed especially for that particular market.
The same is true if you went after bloggers instead of businesses. WordPress.com is going after the general blogger population. Edublogs.org is going after the education market.
Pros & Cons of Being a Web Host
Of course there are going to be pros and cons associated with anything you do. We’ll try to map out a few of main ones below. Considering these things may help you decide whether you’d rather go the “Web Host” route or the “Designer” route.
One other important consideration that we won’t really go into here is the type of marketing you would need to do for each. Going after many clients paying a small monthly fee is very different from going after a few clients paying a much larger initial fee.
Pros
No custom work required
Could charge extra for custom work if you liked
Inexpensive for clients, therefore possibly more clients (easier for your service to go viral)
Cons
Users must do some setting up themselves
Probably lots of support question (due to the D-I-Y nature of it)
Less money per customer – need lots
Designer (+ Host)
Designers provide custom solutions for a higher price, but usually have fewer clients.
As primarily a Designer, as we’ll call it (with ongoing hosting as well), your clients most likely will never even know that they are on a Multisite installation. The Multisite installation is for your sake much more than it is for theirs. The Multisite installation lets you easily access all your clients sites from one backend and keep them updated as well.
In addition, if using the right plugins, it allows you to easily use pre-made templates (not just themes) that you can then tweak and customize, cutting down your design time considerably. While pre-made templates can be used on the “Web Host” site too, again, that’s more for the convenience of the end user than it is for you. In this case, however, the templates are for your convenience as a designer. (We’ll talk about this in more detail later.)
Markets for Designers
Like a Web Host, the Designer primarily needs to decide if he/she will go after a niche market (only lawyers, for example) or whether the target market will be any type of business.
For Designers, however, there is typically another option that isn’t usually pursued by Web Hosts, and that’s defining your market by location. So, for example, you might sell yourself as a web designer for businesses in XYZ City. Because of the higher income earned initially on each site, you can afford to have fewer clients and give them more personalized service – such as showing up at their offices and teaching them face to face how to do something.
Pros & Cons of Being a Designer
Pros
More money per client
Once set up, work may be minimal
Fewer support questions because you do it for them
Cons
More time spent with customers initially
Customers may be harder to please due to higher expectations
Possibly harder to find clients due to the expense
Combination of the Two
Of course you could also structure your business to be combination of the two styles, letting customers do it themselves on the lower end or opting in to more custom designs and more hands-on attention on the upper end. While that may sound like the best of both worlds, and it could be, there would be aspects about that to consider, such as how effectively you could market to such a wide range of client types.
Pros & Cons Recap
Just a quick recap of the pros and cons for each type of setup.
Differences for the Clients
In deciding which model to pursue, you should consider who your clients will be for each. While your communication with one type may be different from your communication with the other (email vs. phone, forums vs. face-to-face, etc.), you will still be dealing with clients no matter which you type you choose.
With that in mind, let’s take a look at how these two systems differ for the clients. When you understand that, you’ll better understand what type of person is attracted to each system.
The Main Differences
There seem to be two main differences:
A willingness to get your hands dirty
Price
Web Host
Web Host clients are generally the DIY types.
With the Web Host set up, the client signs up and then must go about putting things into place – theme, menus, pages, widgets, plugins, etc. You can help them out a lot by setting up pre-made templates with many of these things already in place. (We’ll talk about this later.) But if they want something to be different from the template (as they probably will), they’ll need to do it themselves. This will most likely mean finding instruction for how to do it (best if provided by you) and then having the time and patience to follow those instructions.
In exchange for getting their hands dirty, they’re getting a high-quality site at a cheap price. They will also have more flexibility to change all those things they set up – themes, widgets, etc.
Pros for the Client
Cost less
More flexibility to change major parts of the site
Cons for the Client
Must do it themselves
No customized looks available beyond the themes’ default (i.e. they can change themes but not the looks of the themes)
Designer
Designer clients relax while you do all the work.
With the Designer setup, the client will talk to you directly about what they’re looking for. Perhaps they’ll choose a basic design from a set of choices, or maybe they’ll even point to certain site to use as a model. Or maybe you’ll even make suggestions to help them out. It then becomes your job to build the site to their specifications, checking with them to make sure they’re happy.
In exchange for you doing the hands-on work in the beginning, they pay you for it. How much hands-on work you do after that is something you will need to work out. If you leave it open, you may have some clients requesting changes on a regular basis. And when we say “regular basis,” we mean very regular. If you attach a price to additional work, it will cut requests down, but it may leave some clients feeling somewhat handcuffed.
Pros for the Client
You do the work for them
More customization available outside of theme’s defaults
Cons for the Client
Cost more initially
Additional work costs more too
Setting Up Your System – Plugins for the Super Admin
One of the biggest pieces to the puzzle in setting up your system is to get the right plugins. As one of WPMU DEV’s specialties is Multisite plugins, we will be drawing on a lot of DEV plugins to get the system up and running. In some cases, such as with the Pro Sites plugin (which lets you easily charge for different levels), there are really no other options out there for WordPress.
In other cases, we may have a preference for our own plugins, of course, but we’ll also try to point you to plugins that aren’t ours as well in order to give you some other options.
Web Host vs Designer Plugins
Getting the right plugins are key to making your system work.
For the most part, many of the most important plugins you would use as a Super Admin would be the same whether you were running your business as a Web Host or a Designer.
The only exceptions to that are two plugins that are critical for running a Web Host system – Pro Sites and Anti-Splog.
Pro Sites lets users choose from pre-determined packages, pay with a service like PayPal, and then get access to what they paid for immediately. As a Designer, you will be talking to your clients one-on-one and discovering what their needs are. Therefore, the automated nature of Pro Sites isn’t needed.
Anti-Splog helps you protect your network from spam blogs. As a Designer, you won’t have your network open for just anyone to come along and set up a blog. Therefore, you aren’t going to be running into spam blogs.
Here’s a list of the main plugins you will likely need to set up your system. We will go over each in more detail below.
If you’re running a Web Host setup, then the Pro Sites plugin is going to be THE key piece of the puzzle for you.
As mentioned above, this is the plugin that will allow you to set up different packages that users can subscribe to. For example, you can limit certain themes or plugins to certain levels. You can offer upgraded support for certain levels. Users can sign up to get more space, etc.
Take a look at the video below to get an overview of Pro Sites.
Putting Pro Sites to Work – Let’s say you’ve decided to run a Web Host system for interior decorators. Most would want to show a portfolio of their work. At one level, you could offer the default WordPress gallery. At a higher level, however, you could give them access to a premium gallery plugin that looks much nicer.
And of course it could work the same way with themes. Give them some nice themes at one level, but let them have access to even nicer themes at another level.
But Pro Sites gives you a lot more control than that. While you can give a user free access and then let them upgrade, it isn’t required to have a free level. You can make even the lowest rung on the ladder a paid level.
Another very nice feature is that you can give access to any level you like for a limited amount of time. And of course it’s not required to have multiple levels, and so one strategy might be to only have one level packed with everything (all the best plugins, themes, etc.), but give users access to it for only three days. This way they could sign up, play around with things, get excited about building their site, but then they’d need to pay in order to actually continue.
Something else you can do with Pro Sites is to limit the number of Posts and/or Pages that can be created.
And there’s more on top of this. All the options it offers allows you to structure your offer most any way you’d like.
As mentioned, Anti-Splog helps you combat spam blogs. If you’re running an open network, it’s an absolute must. If you’re running a Designer type setup, then more than likely you’ll be adding new sites yourself, and you won’t have the need for an anti-splog tool.
Check out the video below to get an overview of Anti-Splog.
New Blog Templates is one of my personal favorites. In my view, if used right, this is a plugin that can help set you apart from the crowd if you’re going in the Web Host direction, or it’s a plugin that will drastically cut down your workload if you’re going in the Designer direction.
First, a quick explanation. New Blog Templates lets you set up a blog any way your like – with Posts, Pages, widgets, the theme you want, menus, galleries, any plugin you can think of, etc. – and then it lets you turn that blog into a template.
So what does that mean in practical terms? Well, let’s look at an example. First from the Web Host point of view.
New Blog Templates for Web Hosts
Getting a menu to display correctly may be nothing for you, but it might be a chore for your clients.
Let’s say you’ve decided to target restaurants. You want to set up a site that lets restaurant owners sign up for $X-amount per month, and then they can build their own sites with the themes and plugins you offer. The problem, however, is that sometimes setting up something like a menu (either in a theme or with a plugin) can be a little overwhelming for someone not familiar with such things. Just reading the instructions gives them a headache, to say nothing of actually getting it to look the way it should.
With the New Blog Templates plugin, you can go in and set up a site for a sample restaurant and make it look just the way it should. And you could do that over and over again with a number of different “sample” restaurants. Maybe you have an Italian restaurant sample and a Chinese restaurant sample and a Sandwich Shop restaurant sample. Or maybe you only focus on sandwich shops, and you have ten different Sandwich Shop samples.
The client can then choose one of those samples and, in many cases, simply replace your sample content with their own content. They don’t have to learn, for example, that they need to create a “Menu” page and then place a special shortcode in it. They simply have to navigate to the premade menu and start substituting their items for your sample items.
Make the Simple Things Even Simpler
And the same is true for things that are even much simpler.
Even something as simple as getting a map to show can help your clients.
Many people have no clue how to do many things you take for granted, and they have no interest in learning. Even something as simple as installing a Google Map plugin and putting in a map to their place of business can be a chore. They don’t want to learn how to install plugins or even how to activate/deactivate them. They don’t want to go searching out what the right shortcode is for a particular plugin. They don’t even know what a shortcode is. All they want is a Google map on their site.
So in this case, for example, you could cut their learning curve down a ton by setting up a working example and having them simply replace the Google map URL. You set it up and then give them simple instructions (maybe even right on the page itself): “Go to Google Maps (link), put in your address, copy the URL, come back here and put it in the space where the sample URL is, and then delete these instructions and update the page.”
Set Up Themes and Make Them Templates
Many themes look great when you see the demo on the developer’s site, but then you install one on your own site, and you find there’s a lot of work to do to make it look as good as it did on the developer’s site.
You could do a lot of that work for your users by creating a sample site that just needs to have its “dummy content” replaced by the user’s content.
For example, if the theme you’re using has a featured spot on the home page for whichever category you’d like, go ahead and make up a category called Featured – Homepage, so it’s clear to the user that by putting a post in that category, it will show up on the homepage. In this way they don’t need to muck around in the settings of the theme to figure out how to get posts to go into the featured spot.
Set up a system, then let it work for you.
The more you dig into just about any theme these days, the more you’ll see little opportunities like this to make things easier for your users. And if you’re going after a certain niche, then you can set up special plugins just for them too, special Pages they may need, etc. Essentially, you’re building their site for them, but you only do it once. Then you just clone it and turn them loose with it.
This initial building will take some time, as will providing them with instructions. But keep in mind that you’re setting up a system here. Once it’s built, it will chug along more or less on its own.
*** IMPORTANT NOTES:
1. It should be noted that with this plugin you can only choose a template for NEW blogs – i.e. as the blog is being set up. (Hence the name: New Blog Templates.) Also, you cannot change templates once you’ve set the site up. In order to get a new/different template in place, you would need to create a new site on your network.
2. Of course users are not required to choose a template to start with. And even if they do, they will still have free reign to add and delete what they like as they would with any other site. As you might set up some templates to work with certain themes, however, this may cause some mismatching here and there if another theme is used. Users will need to be aware of that.
New Blog Templates for Designers
Designers can make their lives easier with New Blog Templates.
As we said the Pro Sites plugin would be THE key piece of the puzzle for Web Hosts, the New Blog Templates plugin is the THE key piece of the puzzle for Designers – assuming you’d like to drastically cut down your design time by automating large chunks of it.
One way to go about it would be to begin from scratch by working with some clients and building the exact sites that they want. This will be a lot of work, of course. But when the first few sites are done, you can turn them into templates that you can then use for future clients. Of course you won’t want all your sites to look the same, so you can make changes here and there – sometimes large and sometimes small.
The big advantage here is that you may find a nice combination of features that work well for most businesses you deal with. You can then set about including that feature set into a wide array of different themes. From that point you can make smaller tweaks to customize each site as the client likes. If you need to do any editing of the theme itself, you can use child themes.
An Example – Sites for Lawyers
Find the common features for a niche like lawyers.
Let’s say, for example, that you’re working with lawyers. After working in the industry for a while, you start to notice that a lot of the underlying structure of lawyer sites is similar. While the designs may be very different, the types of content is similar.
Let’s say they all pretty much have the following sections:
Areas of Practice
Location
Contact Us
About Us / Staff
Blog
FAQs
Disclaimer Page
Testimonials / Awards
Widget for badges, etc.
And so you can make up a basic starting point template for law firms. From there you can customize and design on top of that structure.
And of course you might even start to specialize for different types of lawyers. When you do, you begin to notice that on top of the basic structure above, they also have sections related to their specialty. For example, let’s say you begin catering to real estate attorneys. You notice many have the following sections, each with some general information and links pointing out to places of authority, such as government statutes.
Real Estate Closings
Real Estate Contract Negotiation
Title Insurance
Short Sales
Foreclosure Services and Representation
Loan Modifications and Restructuring
Distressed Property Workouts
Commercial Leasing
With this in mind, you can create a special Real Estate Law template.
The Domain Mapping plugin is going to be another must for most people. This plugin maps the user’s site on your network (e.g. xyzplumbing.mywebhost.com) to their own domain (e.g. xyzplumbing.com).
Although it’s possible to set up a site like WordPress.com or Edublogs.org and have people be willing to pay for upgrades without having their own domain, in most cases money will be made with clients that want their own domain. This, of course, applies to both the Web Host and the Designer model.
Another domain mapping plugin option is the WordPress MU Domain Mapping plugin found in the WP Plugin Directory.
Your client may or may not know that they are working on the WordPress platform. You may want to use that as a selling point. Or you may want to leave that fact out of the conversation altogether. That’s up to you and how you think it might affect your marketing efforts.
Either way, the Ultimate Branding plugin will let you easily wipe traces of WordPress’ branding from your system. Replace all WordPress logos with your own. Customize the Admin area. Use your own favicons. Write your own help content. Set up the dashboard the you like. And more.
Take a look at the video below for an overview of Ultimate Branding.
And here’s a look at some of the settings to give you a more complete idea about what you’ll be able to change with this plugin.
A quick look at all the things you can change with the Ultimate Branding plugin.
The Easy Blogging plugin takes rebranding to another level. Easy Blogging changes the look in the backend completely, making it both more attractive and much much simpler.
Have a look at the following video for an overview of the Easy Blogging plugin.
The Easy Blogging plugin is also flexible. At the “highest” level, you can let users choose to turn the Easy Blogging mode on or off. Or you can make it mandatory, thereby making sure you can control the complexity of the backend. You can also use it in conjunction with the Pro Sites plugin and make it mandatory only for free users, for example.
Know what your clients need ahead of time, and do it for them.
In addition to making things simpler, Easy Blogging also makes it easier to point users toward the things that will be most important to them.
For example, let’s say you have an “Announcements” section on the homepage of one of the Blog Templates you created. In order for the user to change the message in the Announcements area, they will need to go to a page which you conveniently created for them called Announcements.
Instead of making the user dig into the Pages section and find the page for Announcements, you could put a button right on the sidebar that goes directly to the edit screen for that page.
Quick technical note: You would do this by building the page, and then copying the last part of the URL and putting that into the URL box. For example, if the page you built for Announcements in your template had an ID number of 43, then the URL you would put in the box would look like this: post.php?post=43&action=edit.
This way, no matter what the user’s domain, that menu button would always go to the edit screen for the Announcement page (providing they’ve started with the template you built). For example, the same menu item would go to these edit screens on these three example sites:
To give you a better idea of how the Easy Blogging plugin changes the appearance of things, take a look at the edit screen under Easy Blogging.
Easy Blogging – the new post screen in the editor.
And here’s a look at the dashboard with a custom widget put in place. I’ve added a bit of HTML to show you a little of what it can do.
A look at the Easy Blogging dashboard with a custom widget.
In addition to the above, another very nice feature of Easy Blogging (especially if you have clients that aren’t technically savvy) is the Wizard. This feature lets you create a step-by-step wizard guide for your users, taking them through whichever pages/screens you assign to your home-made guide.
This is especially useful if you have set up a custom-made site – whether you’re using it for an individual client or as a template.
Users can easily switch back and forth between Wizard mode and regular mode with the click of a button.
Create guides and take your clients by the hand. Show them exactly what they need to do and where they need to go.
And finally we come to the last plugin we’ll recommend as a “must have” – Video Tutorials.
Whether you’re setting up as a Web Host or a Designer, you’re likely to be dealing with a number of clients who aren’t familiar with WordPress at all. These white label video tutorials will be a lifesaver for both you and your clients. They integrate right into your backend, providing on-the-spot support that will show your users exactly what they need to do.
Take a look at the video below for an overview.
Other Plugins to Consider
The plugins mentioned above are recommended as “must haves,” but there are lots of other great plugins you’ll find at WPMU DEV to help you do exactly what you want to do. We’ll give a short rundown here of some others that may serve you well.
Support System – Set up a comprehensive support system with an FAQ and Support Ticket systems available to all your users via the WordPress Admin.
Admin Help Content – WordPress default help may overwhelm your users. Create your own. WP Help will also allow you to make up your own support documents.
Terms of Service – Places a Terms of Service box on the signup form. Especially good for Web Host setups. Multisite TOS is another option for you.
Default Theme – Allows you to easily select a new default theme for new blogs.
(Note: if you put in a default theme and you also choose a template, the template will override the default theme)
Multisite Analytics – Offer users individual stats for their sites through Google Analytics. At the same time, get site-wide stats for yourself.
Affiliates - Allow your users to become affiliates, send you referrals, track their clicks and sales, and get paid.
Custom Press – Especially useful if going after a certain niche and making special post types for them. Custom Post Type UI is another easy-to-use option for you. And Types is yet another.
Even More Plugins & a Technical Note
We’ll stop here with the plugins, but you should know that WPMU DEV’s Multisite plugins don’t stop here. You can find plenty more by searching the Multisite plugin directory.
Also, if you need to deal with bringing already existing WordPress sites into your Multisite Network, this post on importing to and exporting from Multisite should help.
Thoughts? … Comments? … Ideas?
As mentioned, this idea of running a business based around WordPress Multisite is not new. Many have done it. Maybe you have too. If so, we’d like to hear about your experiences.
If you’re thinking about doing this but haven’t done so yet, maybe you have questions that you’d like to put out there. Please do so in the comments.
Or maybe you just have a good idea you’d like to share. Let us hear it.
The post above is by no means a be-all and end-all. If anything, it’s only a possible beginning.
Displaying BuddyPress profile data outside of the main BuddyPress components is a little trickier than you might imagine. However, this is a common request, especially since many of our readers manage multisite networks. So for this quick tip we’re going to examine a few examples of displaying BuddyPress profile data on multisite blogs.
Basic Example of Displaying BP Profile Info on a Multisite Blog
A very common scenario is where you want to display an author’s bio on his multisite blog, pulling the content from a BuddyPress profile field. The code below gets the blog admin’s user ID and displays the profile field that you specify. You only need to replace the ‘Bio’ with the name of the field you’re trying to display:
This works for any kind of basic text field and can be added anywhere within the blog’s theme templates.
Display Data From a Checkbox Profile Field on Multisite Blogs
Example of a checkbox profile field displayed on a multisite blog
A slightly more complicated example is when you need to display fields such as checkboxes or drop-downs.
I took a hint from a WordPress StackExchange post for displaying unserialized profile fields. The key is to use $multi_format = ‘comma’ to output your chexboxes or dropdowns.
In this example we’ll display a ‘Counties Served’ checkbox field with each county separated by a comma, using the following code on a multisite blog:
Here you’ll want to replace the ‘Counties Served’ with the name of the profile field you are wanting to display. Pretty simple, right?
There is an old plugin that does this and quite a bit more with easy-to-use widgets, but in this case I wanted something simpler. If any of you know a better way to show BP profile fields in mulitsite, please let us know in the comments.
On a very active WordPress multisite network, blogs can come and go. Perhaps a user hasn’t renewed his membership or simply decided to delete his blog. Other sites may still be linking to that nonexistent blog. The default behavior of WordPress is to direct you to a 404 error page when you try to visit a nonexistent blog. Unless you’ve taken great care to make your 404 error page useful and engaging, the visitor has probably reached a dead end.
Did you know that WordPress has a NOBLOGREDIRECT constant that you can use to customize the URL it redirects to for nonexistent blogs? Add this to your wp-config.php file and change the URL to wherever you want to send your visitors.
1
define('NOBLOGREDIRECT', 'http://example.com');
Using this handy constant you can redirect to your home URL, a blog directory or any page that you think might help to get your visitor interested in staying on your site.
This is one of those really easy customizations that improves a new visitors experience on your website. Instead of landing on a 404 error page, the user can be sent to a more engaging page with information about your network. Any WordPress multisite admin can implement this quick customization in less than a minute.
Recently, due to the many attacks launched on the internet, especially the botnet DDoS attacking WordPress hosts, I was forced to move some of my sites to a shared server — a virtual machine — with little memory and just a slice of one CPU core.
This required rethinking the whole strategy of hosting them: instead of having huge server with almost unlimited memory, disk space, many CPU cores, and infinite resources, I had to somehow extract the same amount of performance out of this tiny virtual server. How?
After a whole week of reading mostly outdated tutorials, and evaluating many different approaches and strategies, it was clear that my beloved LAMP environment, favored by so many for running WordPress, had to go. Apache simply refused to be fit into such strict limits.
The alternative seemed to be Nginx, which I had absolutely no experience with, so I was not expecting miracles — and I was aware that WordPress has been designed to take good use of Apache’s tricks, like mod_rewrite to get not only pretty URLs but also work tightly with disk caches.
But to my utter surprise, not only Nginx plays nicely with WordPress, but the result was unsurpassable performance that I never thought to be possible! Small is beautiful, but it can be ultrafast too. Here’s how!
Requirements
For this tutorial you will need three things:
A virtual machine (also known as virtual private server), either created on your own computer (using VMWare or similar software), or, more likely, leased from a commercial provider. You can get a good overview of pricing and features at CompareVPS. I’m using a VPS with 512 MB of RAM, 40 GB of disk, and 500 GB of monthly traffic for a bit less than US$10/month.
A pre-installation of Ubuntu. For this tutorial we will use Ubuntu 12.04. There are more recent versions; and many of the commands and configurations will probably work under Debian Linux as well. Commercial providers will usually pre-install the operating system when you sign up with them.
Some familiarity with Unix console commands. At least you should not be afraid to experiment with them!
Quick overview
So here is what we’re going to install. First, we’ll begin with MySQL, and tweak it a bit to get it to fit into our limited-memory environment.
We’ll be using PHP with the Alternative PHP Cache (APC) — a way to speed up PHP processing — which plays nicely with the W3 Total Cache plugin (which, in turn, is fully Nginx-aware).
And finally we’ll explain how you can host multiple sites with completelydifferent domain names using a single WordPress multisite installation.
Caveats and disclaimers
Before you start following this tutorial, you should have in mind a few things. Choosing the “best” setup for WordPress is a tricky business, because, on one hand, it depends on the definition of “best”; but on the other hand, it depends on your WordPress setup (and the hardware it’s running on), what it’s being used for, the kind of data (like images and multimedia files) you’re hosting, and, more importantly, your visitors and what they’re doing.
Benchmark results are helpful, but consider your own environment.
There are plenty of benchmarks on the Web attempting to “prove” that one solution is “better” than others. I did the same for my own particular setup, and what will be described below is the result of my own tests. But you might have a different environment and not be able to reproduce the same results.
For instance, some people question very seriously the claim that Nginx + PHP-FPM is actually slightly slower than Apache + mod_php unless you have a lot of static content (because Nginx will serve it directly without the need of contacting the PHP-FPM backend). If you have plenty of memory to spare, a solution using Varnish + Apache + mod_php might beat a very fine-tuned Nginx + PHP-FPM solution. Just because Nginx + PHP-FPM might work best for the kind of setup that WordPress.com has, it doesn’t mean it’s the best for you.
But if you have a very tight environment with few resources — or, instead of opting for a huge server with lots of memory and CPU, you prefer to distribute your load among several small cloud instances — then this tutorial might help you out with extracting the most performance out of your tiny virtual private server.
Installing MySQL
So, your virtual server provider has just sent you the access password to your own slice! It’s time to to log in via SSH and start installing things. We’ll begin with MySQL.
Some pre-installed versions of Ubuntu might have MySQL 5.5 already as part of the package list. If not, what you need is to run:
1
sudo apt-get install mysql-server
Now it’s the time to tweak MySQL to make it fit into as little memory as possible, but still perform adequately well. The first choice is to either go with MyISAM or InnoDB, the two most popular table engines. MyISAM is the oldest one, InnoDB comes as default with MySQL 5.5.
Discussions have been raging on the Internet about which solution is best for WordPress, and, again, it might be a matter of personal taste and specific environment. What is important here is that if you just use one of them. It’s pointless to let MySQL run both, and that will save you some memory.
After some reflection, specially after reading Mark Maunder’s article (who benchmarked MySQL using both approaches), it seems that MyISAM might be a preferred choice on single-CPU environments. Since for this tutorial we’re using a tiny virtual server, which might just have one CPU core, we’ll stick with MyISAM.
Open /etc/mysql/my.cnf (you will need a text editor; nano is a popular one and should be installed on most systems; if not, sudo apt-get install nano should get you that) and change/add the following:
#
# * MySQL configuration for tiny memory footprint
#
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
skip-networking
key_buffer = 24M
sort_buffer_size = 4M
read_buffer_size = 4M
#binlog_cache_size = 2M
max_allowed_packet = 12M
thread_stack = 128K
thread_cache_size = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover = BACKUP
#max_connections = 200
#table_cache = 64
table_cache = 128
thread_cache = 256
#thread_concurrency = 10
thread_concurrency = 4
myisam_sort_buffer_size = 1M
tmp_table_size = 12M
max_heap_table_size = 12M
wait_timeout = 200
interactive_timeout = 300
max_connect_errors = 10000
#
# * Query Cache Configuration
#
query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 16M
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
skip-innodb
default-storage-engine = myisam
skip-external-locking
skip-slave-start
skip-name-resolve
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
[isamchk]
key_buffer = 16M
#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/
Some short explanations on the above configuration: you might have seen tutorials for improving performance under MySQL, even from Matt Mullenweg himself, and the settings are a bit higher. Here we’re looking at a compromise: we don’t want MySQL to have terrible performance, but we don’t want to have it consuming too much memory.
The more surprising aspect might be “no networking” (and all the related aspects to that, e.g. skipping name resolving, and so forth) and getting rid of InnoDB completely. This saves us some networking buffers, but, of course, it means that WordPress will need to contact MySQL on an Unix socket and be installed on the same machine; we’ll see how this works later on.
You might prefer to run two servers.
If you prefer to run two servers, side-by-side, one with MySQL, the other with Nginx/WordPress, then of course you will need to turn networking on. This might be a more suitable environment for cloud-based networks — some providers allow you to allocate a set amount of CPUs, memory and disk, but you can launch as many instances as you wish.
Usually, only some of those will be accessible by the outside world, and the rest is inside a “private” network, with no routing to the exterior. Cloud providers usually do not charge anything for traffic among your virtual instances — only for traffic that crosses the boundary to the “real world”.
This will mean that although you have open network connections in this case, they’re completely shielded from the outside world, and, as such, are secured. And, of course, you can later duplicate the MySQL instances (or the front-end instances) if you need.
But for this tutorial, we’re keeping it simple: everything is inside the same virtual private server, and, as such, networking is not necessary — we can communicate via Unix sockets instead.
Start MySQL with:
1
service mysql start
At the end, you should most definitely set a root password (also known as “administrative account”) for MySQL, since by default it’s empty. There are many ways to do that, but Ubuntu 12.04, for MySQL 5.5, has a neat command:
1
sudo dpkg-reconfigure mysql-server-5.5
Under other distributions, you will need to use the following commands:
Remember to pick a very hard-to-figure-out password, preferably randomly generated.
Installing Nginx
The next step is to install Nginx. This is a software application that is under constant development, and it pays off to get the latest batch of security enhancements. Unfortunately, the Ubuntu core developers are not always up-to-date with Nginx, so the recommended choice, as per the Nginx Wiki, is to add it from a third-party repository (or, as the Ubuntu crowd calls them, from a Personal Package Archive [PPA]), which is maintained by volunteers and is not distributed by nginx.org. It has some additional compiled-in modules and may be more fitting for your environment.
1
2
3
4
5
sudo -s
nginx=stable # use nginx=development for latest development version
add-apt-repository ppa:nginx/$nginx
apt-get update
apt-get install nginx
If you get an error about add-apt-repository not existing, you will want to install python-software-properties:
1
sudo apt-get install python-software-properties
and then just run the above commands again.
Overview of the configuration for Nginx
Apache Web Server
You can run Nginx and Apache side-by-side on the same server (for instance, letting Nginx deal with static content and having Apache handling PHP), but for this tutorial, we’re going to assume that only Nginx will be running, and we will use the same data directory structure (the one where the actual files for the websites are going to be) used by Apache.
Why? It will make changing to Apache easy, if you decide to drop Nginx; or, if you’re following some tutorials on the Web, which assume you have a “standard” structure for a Linux distribution with Apache, then you won’t be much confused about the right directory to place your files.
What this means is that all data will be under the /var/www directory. Nginx itself follows a configuration style which is similar to all applications under Debian/Ubuntu. The main configuration directory is /etc/nginx. The main configuration file is /etc/nginx/nginx.conf. Additional configuration files (we will use that for adding WordPress-specific configurations) are under /etc/nginx/conf.d; they will be automatically loaded when Nginx restarts/reloads.
And finally, all website-specific configurations (for each virtual host) will be under /etc/nginx/sites-available. Each time you create a new virtual host, that configuration file will be symbolically linked to /etc/nginx/sites-enabled.
Some Nginx configurations that you might find out there will probably just use one single file for everything (Nginx usually doesn’t have very long configuration files anyway). Here, however, we will split everything according to the usual tradition of Debian/Ubuntu. The idea is that each virtual host will have as little different information as possible, and draw from common rules for everything.
Installing PHP5, PHP5 Extensions and PHP-FPM
Nginx, as you might remember, does only handle static files — everything else needs to be passed to an external service. In our case, we’ll use PHP-FPM to handle PHP5 on behalf of Nginx. PHP-FPM is like a mini-webserver, with its own options, but which will only process PHP — we’ll get back to it later.
Figuring out what PHP5 extensions you really, really need to have is not always easy! For this tutorial, we want to have PHP5 with as few extensions as possible (to make sure it consumes little memory!), but we need at least a few, since WordPress (or some of the plugins) will depend on them.
I have mostly followed Rahul Bansal‘s suggestions. The first thing is to make sure we get PHP 5.4 (instead of the default PHP 5.3 which comes with Ubuntu 12.04 LTS), and that means adding another repository to get the latest version. Newer versions of Ubuntu might already have PHP 5.4 as the default, so you might wish to skip this step.
For some WordPress plugins you might need to add php5-pear to that list, as well as a few others (like php5-imap if you are using some sort of newsletter which gets mailed out to your users). International users will probably add php5-intl. I normally add php5-tidy which gets used by W3 Total Cache, but it is not strictly necessary.
Configuring Nginx
To give you a rough overview of what the Nginx configuration below does, it’s good to understand that Nginx is configured with rules: as it gets an URL, Nginx will need what to do with it — look up into a certain directory for a static file (for images, CSS, and so forth), pass PHP scripts to PHP-FPM, or block access (for security reasons).
Nginx can obviously do quite a lot more processing, like adding no-expiry headers and removing cookie requests for static files (for better caching), or gzip‘ing everything on the fly (for saving bandwidth).
Here is the /etc/nginx/nginx.conf file which handles most of the common features:
Notice a few things. First, worker_processes should be set to 1 per CPU (in my own VPS I just have one CPU). client_max_body_size is the size of uploaded files through POST; I believe it defaults to 1m (one megabyte), but 8 is the default used by PHP for file uploads, so I suggest those two settings are kept with the same values.
The upstream command is the setup to talk to PHP-FPM: as you can see, like we did with MySQL, we’re using Unix sockets to communicate with PHP-FPM. If you had a setup with Nginx on one VPS and PHP-FPM on another (using Nginx, say, as a front-end reverse proxy/caching server), you would use server my.ip.address:portnumber instead.
In this tutorial, we’ll show you both the single-site and multisite configuration for WordPress. The configuration files for those two choices will be stored under /etc/nginx/conf.d/, so we will activate the appropriate ones on demand. That’s why this line is commented out — we don’t want to load both configurations, since WordPress works rather differently under multisite mode!
The configuration for single-site WordPress (save it under /etc/nginx/conf.d/wordpress.conf) is as follows, inspired by the recommendations at WordPress.org and the entry for WordPress on the Nginx Wiki, which describe best practices as well how to avoid some common pitfalls.
# WordPress single blog rules.
# Designed to be included in any server {} block.
# This order might seem weird - this is attempted to match last if rules below fail.
# http://wiki.nginx.org/HttpCoreModule
location / {
try_files $uri $uri/ /index.php?$args;
}
# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
# Directives to send expires headers and turn off 404 error logging.
location ~* ^.+\.(xml|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
access_log off; log_not_found off; expires max;
}
# Uncomment one of the lines below for the appropriate caching plugin (if used).
#include global/wordpress-wp-super-cache.conf;
#include global/wordpress-w3-total-cache.conf;
# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
# Zero-day exploit defense.
# http://forum.nginx.org/read.php?2,88845,page=3
# Won't work properly (404 error) if the file is not stored on this server, which is
# entirely possible with php-fpm/php-fcgi.
# Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine. # And then cross your fingers that you won't get hacked.
try_files $uri =404;
#fastcgi_split_path_info ^(.+\.php)(/.+)$;
#NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
include fastcgi_params;
fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# fastcgi_intercept_errors on;
fastcgi_keep_conn on;
fastcgi_pass php5-fpm;
}
And now the rules for WordPress running in multisite mode (save them under /etc/nginx/conf.d/wordpress-mu.conf):
# WordPress multisite subdirectory rules.
# Designed to be included in any server {} block.
index index.php;
# This order might seem weird - this is attempted to match last if rules below fail.
# http://wiki.nginx.org/HttpCoreModule
location / {
try_files $uri $uri/ /index.php?$args;
}
# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
# Zero-day exploit defense.
# http://forum.nginx.org/read.php?2,88845,page=3
# Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.
# Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine. And then cross your fingers that you won't get hacked.
try_files $uri =404;
# fastcgi_split_path_info ^(.+\.php)(/.+)$;
#NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
include fastcgi_params;
fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# fastcgi_intercept_errors on;
fastcgi_pass php5-fpm;
}
location ~ ^/files/(.*)$ {
try_files /wp-content/blogs.dir/$blogid/$uri /wp-includes/ms-files.php?file=$1 ;
# access_log on; log_not_found on; expires max;
}
#avoid php readfile()
location ^~ /blogs.dir {
internal;
alias /var/www/wordpress/wp-content/blogs.dir ;
access_log off; log_not_found off; expires max;
}
# Directives to send expires headers and turn off 404 error logging.
location ~* ^.+\.(xml|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
access_log off; log_not_found off; expires max;
}
The difference is mostly dealing with file uploads, since each WordPress multisite installation will have a “common” area, but separate areas for the uploads. We will see later how this magic happens (hint: we will need to map each subdomain to the correct $blogid).
For now, notice that this configuration is not perfect: I had to explicitly add alias /var/www/wordpress/wp-content/blogs.dir; — ideally, this should be set from each virtual server’s configuration, or this will work with just one multisite installation…
Beyond these rules, we’ll add also a common set of restrictions, in an attempt to make Nginx more secure. Place them under /etc/nginx/conf.d/restrictions.conf:
# Global restrictions configuration file.
# Designed to be included in any server {} block.</p>
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~ /\\. {
deny all;
}
# Deny access to any files with a .php extension in the uploads directory
# Works in sub-directory installs and also in multisite network
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~* /(?:uploads|files)/.*\\.php$ {
deny all;
}
All that is left to do are the configuration files for the individual websites! But first, we need to set up PHP-FPM; then, after we install WordPress, we will be able to see all of this working together: at this stage, all you can do is to see if there are any configuration errors:
1
sudo service nginx configtest
If all’s well, you should just see:
1
Testing nginx configuration: nginx.
Configuring PHP-FPM
PHP5 itself is configured from /etc/php5. Under Debian/Ubuntu, each different way of launching PHP5 will have its own, separate configuration — e.g. apache2 for the Apache configuration, cli for the command-line version of PHP5, and, naturally, fpm for PHP-FPM. They are all set independently, which sometimes might be confusing, as you can launch different modules and have different settings for each configuration.
We can start with /etc/php5/fpm/php.ini first, since it doesn’t need many changes. Just check that memory_limit = 128M (you can tweak this to consume less memory, but keep in mind that W3 Total Cache will consume a fair amount of memory — in exchange for superfast performance). You might have noticed from the Nginx configuration that we ought to use cgi.fix_pathinfo=0. Also remember to set date.timezone for your own timezone (it’s mandatory for PHP 5.4). The rest should be pretty much the standard.
Check under /etc/php5/fpm/conf.d which modules PHP5 should load. In my case, I had to delete 20-snmp.ini, which I didn’t need. Each of those files calls the appropriate extension and allows you to set extra parameters. You should have something like this list:
Now we need to configure the service that provides PHP to Nginx. PHP-FPM has an extra configuration file for that, stored under /etc/php5/fpm/php-fpm.conf. We will not need to change this file; this is the global configuration for PHP-FPM. Then it launches several pools.
The analogy is that PHP-FPM works a bit like a webserver with virtual hosts: php-fpm.conf has the overall configuration, and then we have separate configurations for the pools under /etc/php5/fpm/pool.d/. By default there is just one pool, www.conf, and this is all we need to edit. It’s a long file, I’m just showing some of the changes and checks you should do:
This looks familiar, right? First, we must make sure that PHP-FPM is using the same Unix socket than Nginx. Then we’ll use dynamic allocation of pools — in this case, we tell PHP-FPM to start with 3 servers (that means three processes ready to listen to PHP requests from Nginx), limit it to a maximum of 20, don’t keep too many spare servers around, and, every time a child process serves 500 requests, it gets killed.
This naturally reflects my own setup — 512 MB of RAM, some of which is naturally also needed for MySQL and Nginx itself (Nginx doesn’t eat much memory, though). After some careful tuning of the parameters, this allows me to serve something like 10 concurrent requests and have all processes in memory — no swapping!
But, of course, this depends on how many extensions you have loaded on PHP5, how much concurrency you really need (10 simultaneous connections is not that much), how quickly your webpage loads (which, in turn, depends on the plugins, widgets, external calls, and so forth)…
The whole trick is to twiddle with these numbers until you get acceptable performance, avoid disk swapping, and don’t leave your users endlessly waiting for pages!
If you want to have separate logs, which will report things like processes dying too early from lack of resources or connectivity issues with Nginx and similar errors, add the following to the www.conf pool configuration file:
If not, PHP-FPM will just pipe most errors via Nginx (but not all), and they will appear on the webserver’s log.
You start PHP-FPM with:
1
sudo service php5-fpm start
Double-check that Ubuntu is launching MySQL, Nginx, and PHP-FPM when it boots (this is the default behaviour for newly installed packages providing network services); if not, use update-rc.d to check them all in.
Installing WordPress
Word.
Most of you will install WordPress directly from the sources, and a good reference for that is on the Ubuntu Server Guide website. I personally dislike the way Ubuntu handles WordPress as an application. It will be better integrated into the overall system, but you will only get upgrades when the Ubuntu team feels they should upgrade it. Looking at the dates of the last update, this was quite a while back. In the case of WordPress, the latest and greatest is also the safest (security-wise) choice, so I recommend to install it manually.
Although Nginx can read pretty much anything from any place on the directory structure, as mentioned before, I’m true to the “Apache/Ubuntu” way of organizing things, and that means placing everything under /var/www — including, in this case, the virtual host that will hold our WordPress installation.
1
2
3
4
5
6
sudo -i
cd /var/www
wget -O wordpress.tar.gz http://wordpress.org/latest.tar.gz
tar -zxvf wordpress.tar.gz
chown -R www-data:www-data /var/www/wordpress
rm wordpress.tar.gz
Now we need to handle the database. WordPress needs a “clean” database (freshly created). In this example, we’ll also add a user just for that database.
If you prefer to use a Web-based database configuration tool, just follow the instructions on this tutorial about installing phpmyadmin. If you’re fine with using command prompts to make database changes, then log in to mysql server as the root user:
1
mysql -u root -p
Create a database with the name wordpress:
1
CREATE DATABASE wordpress;
Create a new user, which will have access to this database only; its username will also be wordpress:
1
CREATE USER wordpress;
Set the password to the user wordpress to be VeryHardToFigureOut2013! (use your own, but make it hard to guess or just generate it randomly as suggested before) :
1
SET PASSWORD FOR wordpress = PASSWORD("VeryHardToFigureOut2013!");
Grant user wordpress all permissions on its database of the same name:
1
2
GRANT ALL PRIVILEGES ON wordpress.* TO wordpress@localhost IDENTIFIED BY 'VeryHardToFigureOut2013!';
FLUSH PRIVILEGES;
And now you can log out from the session by typing:
1
exit
I usually try to log in immediately afterwards with the username/password just created, to be sure everything is fine.
Next, it’s configuration time! WordPress will do pretty much everything on its own, but first we need to let Nginx become aware of our new site.
Open /etc/nginx/sites-available/mydomain.conf and type the following:
1
2
3
4
5
6
7
8
9
10
11
12
13
map $http_host $blogid {
default 0;
mydomain.com 1;
}
server {
server_name mydomain.com;
root /var/www/wordpress;
access_log /var/log/nginx/mydomain.com-access.log;
error_log /var/log/nginx/mydomain.com-error.log;
include conf.d/restrictions.conf;
include /var/www/wordpress/nginx.conf;
include conf.d/wordpress-mu.conf;
}
We’ll get into this later.
1
2
3
cd /etc/nginx/sites-enabled
ln -s /etc/nginx/sites-available/mydomain.conf
touch /var/www/wordpress/nginx.conf
Note that the last command is a requirement for W3 Total Cache (that file has to exist and be readable by the webserver’s user).
Finally, to make sure all this is readable by the webserver, do
1
chown -R www-data:www-data /var/www/wordpress
Running the WordPress self-installer
Go ahead and let WordPress create it.
Click on Let’s Go:
Note that the database host is: localhost:/var/run/mysqld/mysqld.sock. This will get WP to talk to the database via the Unix socket which is set up for MySQL by default, and, as said, totally avoid any TCP-based network connections.
If all goes well, you should be able to get to the familiar steps below:
If not, two things might be wrong. The first is that our “unusual” MySQL setup is not properly configured. The second one is that somehow one password or setting was written wrongly; just go back and fix it. Remember not to use the “admin” name for the Super Administrator: as said, the latest BotNet attack on WordPress sites looked specifically for “admin” and tried to crack its password.
After that, you should be able to login; WordPress is still running in “single site” mode. Now to the next step!
Defining Multisite
To enable WP in Multisite mode, you need to open /var/www/wordpress/wp-config.php with your favourite text editor. If you have done this before, it should be easy. Above the bit that says:
Refresh your browser, and you should have a new option under Tools > Network Setup:
For this tutorial, I will be setting it up as separate sub-domains. There is a reason for that — the Nginx rules later will be a bit easier. At this point, if you press Install, WP will do some validations and probably return an error about a missing “wildcard domains”. Don’t worry. What matters next is that wp-config.php needs another change. As you can see, WP “assumes” you’re running under Apache, so we will pretty much ignore step 2, and just add the prompted lines on step 1 to wp-config.php:
Remember, this will come below the line saying define(‘WP_ALLOW_MULTISITE’, true); but before the line saying
1
/* That's all, stop editing! Happy blogging. */
You will need to login again, but that’s it, your WP Multisite install is pretty much finished.
Adding plugins
Add your favorite plugins.
We will want at least W3 Total Cache. I will assume you’re familiar with the plugin installation procedures, so I won’t go into much detail here. Go to My Sites > Network Admin > Dashboard and then choose Plugins > Add New, search for W3 Total Cache, install it, and set it to Network Activate. One of the great features of W3TC is that you can configure it for all sites in a multisite environment at once, and that’s exactly what we want to do here.
At this stage, you’ll probably be adding all your favourite plugins. I’m personally a fan of Jetpack, since it includes so many useful things like Akismet anti-spam measures, statistics, Photon to cache your images on WP.com’s cloud for free (which is very useful to keep traffic off your website!), and a reasonably good system for managing all your social networking integration. And due to the many security incidents with WP, I tend to install at least Limit Login Attempts.
I’m also very fond of Human Made Limited‘s pair of plugins, WP Remote and BackUpWordPress. The first will allow you to centrally manage all your WP blogs (even if hosted on different servers!) for free, making sure you keep them always up to date (core, plugins, and themes), and never forget to upgrade them all. BackUpWordPress is probably one of the simplest free backup plugins which will backup both the content and the database, and, in my experience, it’s one of the easiest to use if you wish to migrate from one server to another — which is always a mess under WordPress.
As a bonus, when both are installed, you can easily retrieve your backups from WP Remote’s backoffice, from any site. So if you’re administering a lot of WP blogs on different servers, both are a must. Since they’re both free, simple to use, and do their job right, there is little reason not to install them, even though there are better (paid) alternatives around. But, of course, this is all up to you!
You’ll definitely want domain mapping.
What we’ll definitely add is WordPress MU Domain Mapping. There are deep theological discussions about why this isn’t part of the WordPress core. Basically, you have two options of having a network of sites: either they’re all under the same domain, but on different directories (e.g. mydomain.com/site1, mydomain.com/site2, and so forth), or under different subdomains (site1.mydomain.com, site2.mydomain.com). But in most real scenarios, what you have is totally different domains for each site, and you want the ability to manage them all together.
This is the job for WordPress MU Domain Mapping: you will tell it to point a certain domain — say, myotherdomain.com and anotherdomain.com— to specific sites on your install. Obviously you will need a little help from Nginx. The purpose of the next steps is to add these two sites, and make sure they’re properly pointed to the right place, and that Nginx can correctly forward the requests to the right place. All of that while still making sure that W3 Total Cache is working!
First, let’s confirm that W3 Total Cache likes the configuration so far. While still on the Network Administration panel, follow the link on Performance > Dashboard and click on Check Configuration. If all goes well, you should have something like this:
The important thing here is that Nginx should have been detected. You will also see that we have PHP with the Alternative PHP Cache (APC) module enabled.
Now go to Performance > General Settings and enable at least Page Cache, Minify, Database Cache, Object Cache (and Browser Cache should be on by default). For the method use Opcache: Alternative PHP Cache (APC). Save the configuration by clicking on Save All Settings. W3TC should tell you to Empty the Page Cache, so go ahead and do that.
If all went well, W3TC has done some under-the-hood magic for you. If you now open the /var/www/wordpress/nginx.conf file, you should have a surprise: W3TC will already have filled it on your behalf! (If you have an empty file, or got an error, it means that you have either forgotten to touch this file before or it doesn’t have the right user/group ownership or permissions; just take a look again if it’s set to www-data:www-data and is writable).
Fine-tuning W3TC is more an art than a science, although it has become quite easier on recent versions. Page Cache should be fine by default. Minify depends on a lot of things and is probably the trickiest bit. If you’re using CloudFlare, and are as lazy as I am, just let CloudFlare handle minification for you. If you add the login data for CloudFlare on W3TC, the latest versions will communicate with your account, correctly identify that it’s set to auto-minify things, and disable those options on W3TC.
It’s always better to allow CloudFlare to waste CPU cycles on minification, instead of spending your precious resources on that. However, I have a particular instance of a website where CloudFlare’s minification does not work well, but W3TC’s does. This will depend a lot on the theme and the plugins you’re using, and it’s great to know that you have this option.
If you’re not using CloudFlare, try the automatic settings, and on Performance > Minify enable at least HTML & XML (with Inline CSS minification and Inline JS minification), JS and CSS. This should also combine all JS and CSS automatically, which will give you extra points on Google PageRank.
I usually don’t mess around with Database Cache and Object Cache, but I go wild on Browser Cache and turn everythingonexcept
Note that W3TC is a plugin with a very active development cycle. This means that many options are constantly being added and/or removed, specially if they’re a bit obscure or hard to understand what they’re doing. If you’re reading this tutorial many years after it was written, I would recommend you to check a recent W3TC-specific tutorial, to see what options have changed and what they do.
Now let’s install the WordPress MU Domain Mapping plugin. Remember, this has to be network activated to work. Then go to Domains > Domain Mapping and set the checkboxes under Domain Options like this:
Adding two new sites
So when this tutorial is finished, you should have a network of three sites: mydomain.com, myotherdomain.com and anotherdomain.com. What we’re doing is the following mapping:
mydomain.com points to the overall installation, the default site, i.e. mydomain.com
myotherdomain.com points to site1.mydomain.com
anotherdomain.com points to site2.mydomain.com
Firstly, you need to go to your DNS provider and add records for all that. We’ve seen how mydomain.com was already configured to point to your IP address. Now you will need to point site1.mydomain.com, site2.mydomain.com, myotherdomain.com and anotherdomain.com all to the same IP address (Nginx will handle the rest).
Once DNS has refreshed (and you can ping those domains and make sure they’re all pointing to the correct IP address — always the same one!) we can start adding the two sites. This, of course, is what you can do from Network Admin > Sites > Add Site. On Site Address put site1; under Site Title use myotherdomain; and the admin email could be the same as for the main site (myname@mydomain.com in this tutorial). Similarly, for site2, use anotherdomain for the title, and the same email address once more.
Let’s get it all properly mapped. Go to Settings > Domains. You will see the following message popping up:
1
Please copy sunrise.php to /var/www/wordpress/wp-content/sunrise.php and ensure the SUNRISE definition is in /var/www/wordpress/wp-config.php
First, let’s copy that file (this is the handler for domain mapping):
Go to Settings > Domains again, now it should show:
We’re ready to add our own mappings. Sadly, the panels for WordPress MU Domain Mapping are not very user-friendly — we need to figure out the Site IDs on our own.
Fortunately, this is not too hard, since they’re listed on the Sites > All Sites panel:
Now when you hover with the mouse over the Domain name, it should give you it’s ID, with an URL like this:
Notice that there is an extra column, called Mapping, which was added by WordPress MU Domain Mapping. It starts as being blank. If you have followed this tutorial, and haven’t added and then deleted any domains, the logic is simple: the first site is ID 1, the second 2, and so forth (but as soon as you add and delete domains, this can quickly get out of order).
So these are the assignments we wish to do:
mydomain.com uses ID 1 (default — no need to add it)
myotherdomain.com uses ID 2
anotherdomain.com uses ID 3
If the options have been correctly set, it should now look like this:
And, under Sites > All Sites, you should have:
WordPress is now configured to handle the domain mapping, but we have to let Nginx know about it too!
So let’s get back to opening /etc/nginx/sites-available/mydomain.conf. You will have noticed the map directive at the top. What we’re going to do is to pretty much replicate here what we have setup via WordPress:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
map $http_host $blogid {
default 0;
mydomain.com 1;
myotherdomain.com 2;
anotherdomain.com 3;
}
server {
server_name mydomain.com myotherdomain.com anotherdomain.com;
root /var/www/wordpress;
access_log /var/log/nginx/mydomain.com-access.log;
error_log /var/log/nginx/mydomain.com-error.log;
include conf.d/restrictions.conf;
include /var/www/wordpress/nginx.conf;
include conf.d/wordpress-mu.conf;
}
Restart nginx with:
1
sudo service nginx reload
And now it’s testing time! If all went well, you should be able to view http://myotherdomain.com/ and http://anotherdomain.com/ on your browser and they will be properly redirected.
Final note: How to test all the above before going into production?
Time to do some testing.
Following the above tutorial requires owning at least three domain names which you’re not using for any purpose, and, of course, adapting every line of code to reflect your real domain names. But you might wish to do some testing first to be sure that you have the configuration right, before you move to a production environment.
Here is a neat little trick that you can use: using the HOSTS file for creating “fake” domains. Most computers are pre-configured to read static IP address assignments from their HOSTS file first, and only then hit the DNS nameservers. All you need to know is your server’s IP address.
You should do this on two places: on the server where you’re running your WordPress installation and on your desktop computer. Under Linux/Mac OS X, the file is under /etc/hosts, so with sudo nano /etc/hostsyou should be able to edit it and add the following line at the bottom:
where, of course, you should replace 192.168.0.1 with your server’s real IP address. Under Windows, it depends a bit on what version you’ve got; it’s usually under C:\WINDOWS\system32\drivers\etc\hosts. Use something like Notepad to edit it (don’t use Write or Word, since it will add lots of useless formatting and break everything!).
After you’ve done the changes, you will very likely need to exit your browser and launch it again (because most browsers will cache DNS).
There are a few caveats, though: since you’re not using “real” DNS, your WordPress installation will not be able to use any plugins that require a XML-RPC call to your server. A typical example is Jetpack, which really requires “real” addresses, because it contacts your server directly to do its magic.
However, almost all other plugins — even the core auto-update feature which needs to contact the “outside” world — don’t have that restriction. CloudFlare may also have a few issues: you have to be careful not to let CloudFlare clear the cache, or it will be caching the wrong site instead! The best is to turn it off on your development environment and just activate CloudFlare again when you move the site to the production environment.
Can you give us an idea about how much the site makes?
Class Blogs is a plugin that simplifies the process of blogging as a class by making it easier to find, organize and analyze the work created by students. It comes with teacher admin pages, student admin pages, themes and tons of widgets to show recent student posts and comments.
AP Gravatars is a simple plugin that adds a user’s gravatar to his profile page. If the user does not have a gravatar account, the plugin will display a link to create one. It’s multisite-compatible so that you can use it across your network.
This plugin creates a workflow approval process within WordPress. If a user doesn’t have permission to publish a post, an email is sent to one of the approvers when a post is submitted to be published. It also works within multisite so that sub-sites can take advantage of the approval workflow as well.
Network Shared Media is a very useful plugin that lets you access media across the network through a new tab in the media library. This can be very convenient if you find yourself posting to multiple blogs or simply want to make a set of images or documents available to other users.
This plugin adds a Terms of Service agreement field on the multisite signup form, similar to the wordpress.com TOS field. It also supports localization so you can add your language file.
This plugin is designed for use in multisite networks where the same theme is used across all sites. After you have network enabled a new theme, you’ll get a new option to “Subsite Activate” the theme, which will apply it to every subsite on your network. This is very useful if you have lots of sites and don’t want to manually change each site’s active theme.
This plugin provides a wedge between multisite and Akismet by globalizing the Akismet API key so it can be used across blogs. Multisite network blogs can then use the Akismet API key without having to configure each blog or edit any PHP files.
This plugin records all changes in user blog roles (wp_x_capabalities usermeta) across an entire WordPress installation. It can be a lifesaver to have installed if you find yourself having to troubleshoot mysterious role changes within your multisite network.
Blog Copier is a very handy plugin for multisite network admins. It enables you to copy a blog, including all its widgets, template settings and more. You can elect to copy or not copy the files. GUIDs and URLs in post contents are automatically migrated for you so you don’t have to manually change anything!
The Dead Blogs plugin lets you filter blogs, based on specific criteria in order to sort out which blogs are dead. You can locate the blogs by when they were last updated, number of posts, number of pages, or whether or not the blog uses the default theme.
Multisite Robots.txt Manager lets you manage all Network Websites robots.txt files directly within the Network Admin. Each Website within the network is able to have a unique robots.txt file. You can also instantly add Sitemaps URLs to all network websites and mass update the entire Network or individual site.
TuKod MultiSite Site Names overrides the normal restrictions that WordPress places on site names. This plugin gives you expanded site name choices in the multisite sign-up process. It enables you to use dashes (-), dots(.), tildes (~), underscores (_), capitals (A-Z) and even change the minimum length.
WP Changes Tracker is a very useful plugin that logs changes made to your WordPress structure: core, network, plugins and options. In the near future it will also log changes to themes. These logs are only available to the network admin when used in multisite.
implementing seamless redirects. You can actually move content to another site on your WordPress network with a single click.
This is a plugin that nearly every WordPress multisite installation can benefit from. It adds columns to your network admin to show which sites are using each plugin and theme. It will help you know which plugins and themes are in use and which can be safely removed without affecting your subsites.
