Exploring the Merge from Multiuser to Network
Running multiple sites under one installation of WordPress was not alwayspossible. From August 2005 until July 2010, there was a completely separate
software package called WordPress MU. In July 2010, the codebase
of WordPress MU and WordPress merged, meaning that the features of WordPress MU were included in the WordPress software, rendering the
WordPress MU software package obsolete. The merger of codebases
brought several advantages, including
✦ One codebase: Having the multisite feature available in one piece of
software completely eliminates user confusion on which version of
WordPress they need to use. Now, you use the same software package
regardless of whether you want to use the multisite feature. If you do,
just a few minutes of configuration can make it happen.
✦ Bug fixes: WordPress MU was not as popular as the original WordPress
software; therefore, the MU project didn’t attract as many developers
to contribute code, fixes, and additional feature development. When the
merge occurred in July 2010, the multisite feature gained the massive
WordPress developer community, making bug fixes and new features a
quicker and easier process.
✦ Easier interface: If you worked with MU, you know what we mean
here. The interface and Dashboard features for the multisite feature
in WordPress is much easier to work with, mainly because it works in
tandem with the other WordPress settings and features you’re already
familiar with.
In the past, the WordPress codebase would be updated and those
changes would be rolled over to WordPress MU with any additional fixes.
Occasionally, WordPress MU users had to wait two to four weeks or longer
for updates. Because the number of users familiar with WordPress MU was
far less than WordPress, feedback for bugs was also slow. Even though more
than 95 percent of the two codebases were identical, the remaining code in
WordPress MU did the bulk of the work maintaining multiple blogs.
Understanding the Difference between Sites and Blogs
With the merger of WordPress MU and WordPress came a name change.
Each additional blog under WordPress MU is now a site. But, what’s the difference?
Largely, it’s one of perception. Everything functions the same, but people
can see greater possibilities when they no longer think of each site as “just”
a blog. Now, WordPress can be so much more:
✦ With the addition of the Domain Mapping plugin (see Chapter 6 in this
minibook), you can manage multiple sites with different, and unique,
domain names. None of them has to be a blog. They can have a blog element,
or just use pages and have a static site.The built-in options let you choose between subdomains or subfolder
sites when you install the network. If you install WordPress in the root
of your Web space, you will get subdomain.yourdomain.com (if you
choose subdomains) or yourdomain.com/subfolder (if you choose
subfolders). Chapter 2 of this minibook discusses the differences and
advantages.
After you choose the kind of sites you want to host and create those
sites, you can’t change them later on. These sites are served virtually,
meaning that they do not exist as files or folders anywhere on the
server. They only exist in the database. The correct location is served to
the browser by using rewrite rules in the .htaccess file.
✦ The main, or parent, site of the network can also be a landing page of the
entire network of sites, showcasing content from other sites in the network
and drawing in visitors further.
Discovering When You Should
Use the Network Feature
Determining whether to use the multisite feature depends on user accessand posting. Each site in the network, although sharing the same codebase
and users, is still a self-contained unit. Users still have to access the back
end of each site to manage options or post to that site. A limited amount of
general options is network-wide, and posting is not one of them.
You can use multiple sites in a network to give the appearance that only one
site exists. Put the same theme on each site, and the visitor doesn’t realize
that they are separate. This is a good way to separate sections of a magazine
site, using editors for complete sections (sites) but not letting them access
other parts of the network or the back end of other sites.
Usually, for multiple users to post to one site, WordPress is sufficient.
The multiuser part of the WordPress MU name did not refer to how many
users, really. MU was always a bit of a misnomer and an inaccurate depiction
of what the software actually did. A network of sites is a much closer
description.
Another factor to consider is how comfortable you are with editing files
directly on the server. Setting up the network involves access to the server
directly, and ongoing maintenance and support for your users can often lead
to the network owner doing the necessary maintenance, which is not for thefaint of heart. Generally, you should use a network of sites in the following
cases:
✦ You want multiple sites and oneinstallation. You’re a blogger or site
owner whowants to maintain another site, possibly with a subdomain or
a separate domain, all on one Web host. You’re comfortable with some
edits to files, you want to work with one codebase to make site maintenance
easier, and most of your plugins and themes are accessible to all
the sites. You can have one login across the sites and manage each site
individually.
✦ You want to host blogs or sites for others. This is a little more involved.
You want to set up a network where users can sign up for their own sites
or blogs underneath (or part of) your main site and you maintain the
technical aspects for them.
Because all files are shared, some aspects have been locked down for security
purposes. One of the most puzzling for new users is the suppression
of errors. Most PHP errors (say you installed a faulty plugin or incorrectly
edited a file) do not output messages to the screen. Instead, what appears is
what we like to call the White Screen of Death.
Knowing how to find and use error logs and do general debugging are skills
needed when you are managing your own network. Even if your Web host
will set up the ongoing daily or weekly tasks for you, managing a network
can be a steep learning curve.
When you enable the network, the existing WordPress site becomes the
main site in the installation.
Although WordPress can be quite powerful, in the following situations the
management of multiple sites has its limitations:
✦ One Web account is used for the installation. You cannot use multiple
hosting accounts.
✦ You want to post to multiple blogs at one time. WordPress will not do
this by default.
✦ If you choose subdirectory sites, the main site will regenerate permalinks
with /blog/ in it to prevent collisions with subsites. There are
existing plugins available to strip this.
WordPress MU had quirks in the software. The www was stripped from the
domain name, for example, and you couldn’t install on just an IP address
or by using only localhost as the name. These issues are addressed in
WordPress 3.0.Setting Up the Optimal Hosting Environment
This chapter assumes that you already have the WordPress software
installed and running correctly on your Web server, and that your Web
server meets the minimum requirements to run WordPress.
Before you enable the WordPress multisite feature, you need to determine
how you are going to use the feature. You have a couple of options:
. Manage just a few of your own WordPress blogs or Web sites.
. Run a full-blown blogging network with several hundred different blogs
and multiple users.
If you are planning to run just a few of your own sites with the WordPress
multisite feature, then your current hosting situation is probably well suited.
However, if your plans are to host a large network with hundreds of blogs
and multiple users, you should consider contacting your host and increasing
your bandwidth, as well as the disk space limitations on your account.
The best example of a large blog network with hundreds of blogs and
users (actually, more like millions) is the hosted service at WordPress.
com (http://wordpress.com). At WordPress.com, people are invited to
sign up for an account and start a blog using the network feature within the
WordPress platform on the WordPress server. When you enable this feature
on your own domain and enable the user registration feature, you are inviting
users to
. Create an account.
. Create a blog on your WordPress installation (on your domain).
. Create content by publishing blog posts.
. Upload media files such as photos, audio, and video.
. Invite friends to view their blog, or to sign up for their own account.
In addition to the necessary security measures, time, and administrative
tasks that go into running a community of blogs, you have a few more things
to worry about. Creating a community will increase the resource use, bandwidth,
and disk space on your Web server. In many cases, if you go over the
allotted limits given to you by your Web host, you will incur great cost. Make
sure that you anticipate your bandwidth and disk space needs before running
a large network on your Web site! (Don¡¯t say we didn¡¯t warn you.)Checking out shared versus dedicated hosting
Many WordPress Network communities start with grand dreams of being
a large and active community. Be realistic on how your community will
operate in order to make the right hosting choice for yourself and your
community.
Small blogging communities can be easily handled using a shared-server
solution, whereas larger, more active communities should really consider a
dedicated-server solution for operation. The difference between the two lies
in their names:
. Shared-server solution: You have one account on one server that has
several other accounts on it. Think of this as apartment living. One
apartment building has several apartments for multiple people to live,
all under one roof.
. Dedicated-server solution: You have one account. You have one server.
That server is dedicated to your account, and your account is dedicated
to the server. Think of this as owning a home where you don¡¯t share
your living space with anyone else.
A dedicated-server solution is a more expensive investment for your blog
community, while a shared-server solution is the most economical. Your
decision on which solution to go with for your WordPress Network blogging
community will be based on your realistic estimates of how big and how
active your community will be. You can move from a shared-server solution
to a dedicated-server solution if your community gets larger than you
expected; however, starting with the right solution for your community from
day one is easier.
Exploring subdomains versus subdirectories
The WordPress network feature gives you two different ways to run a network
of blogs on your domain. You can use the subdomain option or the
subdirectory option. The most popular option (and recommended structure)
sets up subdomains for the blogs created by your WordPress Network.
With the subdomain option, the username of the blog appears first, followed
by your domain name. With the subdirectory option, your domain name
appears first, followed by the username of the blog. Which one should you
choose? The choice is yours. You can see the difference in the URLs of these
two options by comparing the following examples:
. A subdomain looks like this: http://username.yourdomain.com
. A subdirectory looks like this: http://yourdomain.com/username
No comments:
Post a Comment