WordPress How-To: Install Multiple WP Blogs With One Single Database

As an open source content management system, WordPress often finds itself installed on lower-cost, budget hosting plans which permit clients to have limited number MySQL or PostgreSQL database per account. This is no problem for those users who plan to only host just one or two WordPress blog, but can be a significant road block for those WordPress users who aspire to host their friends, family members, or a thriving community of independent bloggers.

Luckily, WordPress offers a number of ways to permit multiple installations of the software within just one database, saving users both a significant usability headache and the higher cost that comes from seeking a hosting plan which supports multiple MySQL databases.

The road to enabling multiple installations in a single WordPress database involves extensive editing to the software’s site-wide configuration file for many users. WordPress supports hosting multiple blogs with one installation of the software, or installing multiple instances of the software into one database. Those who choose to do this will need to be familiar with the configuration PHP file, their .htaccess file, and other server settings which are determined remotely by their current web host. Those who are comfortable knowing and modifying these settings are urged to complete this process, as it will likely be simple and take just a few minutes from start to finish.

Step 1: Locating and Changing Settings in the WP-Config.php System File

Locating and Modifying WP Config

Every WordPress installation relies on “wp-config.php” to control database usernames, passwords, and locations, as well as settings relating to actual software features and user information. This file is rarely modified, except for in the first steps of a typical installation, and many WordPress developers and novice users may not be sure where to locate the file or which edits to make. For clarification, this configuration file lies in the root directory of every WordPress installation. This will typically be the “public_html” folder for a primary installation, and the base of a subfolder for each subsequent install of the WordPress software.

Once the file is located, it can be edited using an FTP client’s built in file and text editor. Doing this process directly on the server ensures that all edits are made to the remote file and saved directly, eliminating potential data loss and confusion between different versions of the configuration file. When the file is opened, there are a few settings that need to be changed when installing the WordPress software multiple times using the same database.

We will need to configure our “wp-config.php” file in order to customize our WordPress installation. First and foremost, the actual database information must be entered. If this is the first (and primary) installation, the database name, username, and password can be both defined and discovered using the server’s control panel. Both the cPanel and Plesk Panel software have a specific database configuration area that displays this information to users upon request. Fill in all information accurately, as failure to connect to the database will result in a failed installation overall.

Step 2: Changing the Structure of the WordPress Database

Customizing WP Database

Every WordPress download comes with a default configuration file which designates a “wp_” prefix to the entire installation. This prefix will be added on to every table which is created by the installer and is designed to separate the WordPress tables from other applications residing in the same database. Similarly, this prefix can be changed in order to separate different WordPress installations from each other. Changing the database prefix is perhaps the most central step to ensuring that WordPress installations can function alongside each other in the same database without overwriting each others’ data, granting the wrong user permissions, or publishing the wrong content.

What to look for in wp-config.php?

In the still-open “wp-config.php” configuration file for the WordPress installation in question, locate the line which determines the database prefix which will be used. It almost always looks like the following example:

$table_prefix = ‘wp_’;

As can be seen, the WordPress developers have loaded the file with the default “wp_” prefix. This can be used for the first or primary WordPress blog installed to a server, but it cannot be used for any secondary installation. Using the same database for multiple blogs will lead to data loss, erroneous content, and all kinds of user permission problems that could enable malicious activity between blogs.

Change this prefix to almost anything else, so long as it is all lowercase and contains no spaces or punctuation marks. The “_” underscore character is not a requirement, as periods or hyphens can also be used. However, be aware that the underscore character is considered the standard way of separating a prefix from a table name, and it’s the easiest to use when scanning database records for certain iterations or cells.

Step 3: Proceed with Installation

If all you wish to do is simply install multiple WordPress blogs into separate databases with entirely separate groups of users and administrators, the process is largely complete. With the correct database information placed into the file, and the proper table prefix in place of the default WordPress-generated option, everything will likely go off without a hitch. However, advanced users might be interested to know that installing multiple WordPress blogs into the same database enables a unique kind of data sharing. Because user tables are all placed into the same database, WordPress can actually be instructed to use the same set of users between multiple blogs; this can be done on a per-installation basis, as well, so only the right users are given access to multiple points of entry and content publication.

For those advanced users who wish to create a site-wide user list that can publish content across multiple blogs, this edit is relatively straightforward to make and must be done at the beginning of the installation process before the actual installation page has been loaded. It’s easy to do, and the process is presented in the next step for those who are so inclined to give it a go.

Step 4: Sharing Users and User Meta Information Among Multiple Same-Database Installations

An important consideration to be made when installing many WordPress iterations into just one database is whether or not the users of each website will need to login to a different website within the same domain name’s purview. This can be especially true for “magazine-style” sites which categorize their content into subfolders and subdomains, with each content creation department having their own WordPress installation and content creation portal. Having a different user account for all users on every blog can be time-consuming and it’s largely an outdated practice.

The “wp-config.php” file can be amended to instruct a WordPress installation to place all data within its prefixed tables, but to pull user information from a differently-prefixed table. This means the primary blog’s user list could potentially because the user list of all blogs installed into subfolders across a website. Here’s how it’s done.

define(‘CUSTOM_USER_TABLE’, $table_prefix.’global_users’);
define(‘CUSTOM_USER_META_TABLE’, $table_prefix.’global_usermeta’);

These two lines must be added to the “wp-config.php” file before the WordPress software is installed. Notice that the tables utilized for user information are prefixed with “global.” This allows both the primary installation and all secondary installations to access the same, universal tables full of user information. It gives no specific WordPress installation control over the user databases, as each WordPress installation remotely accesses that information via the “global” tables.

The two lines of code above could be modified to be named otherwise, including using the standard “wp_users” and “wp_usermeta” tables for those blogs which will simply access information already determined by the site’s primary WordPress installation. Developers should modify these lines intelligently and at their own risk, and remember to do so before installation as it’s exceedingly complex to change the user tables after an install has been completed.

Installing Side-by-Side WordPress Installations is Largely an Outdated Practice

While WordPress will likely never drop support for custom MySQL table prefixes and multiple installations of the software in the same database, the company’s developers have been hard at work on creating a solution which can perform all of the above tasks on an automated, on-the-fly basis. This means being able to create multiple WordPress blogs by using the standard WordPress Dashboard interface, largely eschewing the “wp-congif.php” file edits and database trickery that is used to share user information among separate installations. WordPress provides a showcase of many blogs which use this feature in its MultiSite Showcase as a demonstration of just how functional, open-ended, and easy a Network is to create and maintain.

The feature is included in WordPress 3.0 and higher, and it’s known as “WordPress Networks.” The company had previously developed the feature as an entirely separate version of WordPress, known as “WordPress MU,” but made the decision to integrate the two during the release of its most recent software version. The feature, while fully functional and quite robust, is not enabled by default. Users will still need to work a little PHP magic within the site’s configuration file in order to be able to access these new and innovative features.

Instead of modifying the database prefix set out in the “wp-congfig.php” file, users will instead bypass that setting and define an entirely new line of code. This line of code instructs the WordPress Dashboard to enable the multisite, or WordPress Networks, configuration options and setup tools. The line to be pasted into the configuration file is this one:

define(‘WP_ALLOW_MULTISITE’, true);

It’s pretty simple, and saving the file will immediately allow the WordPress Dashboard to show the setup and configuration panel within its interface. That’s exact where the user should head next, as the Dashboard is the central feature of WordPress Networks setup.

Once in the Dashboard, click the “Administration” heading in the sidebar and then click “Tools.” Beneath this, a new option named “Network Setup” will appear, and it should be clicked. WordPress will determine whether new blogs should be installed as subfolders or subdomains, and it will ask for a defined directory where it should place blog media uploads (pictures, movies, audio files, and more). With those settings defined, it will get to work and define new database tables, cells, and users. The process may take a few moments.

After the initial configuration has been completed, the site administrator will be presented with a page that instructs them to configure their “wp-config.php” and “.htaccess” files further. These changes will initialize the media upload directory, make essential changes to the way permalinks work for multiple WordPress installations, and enable more of the special WordPress Networks features that set this type of installation apart from standard WordPress versions.

The best part about using this feature is probably the minimal impact it has on the site’s database. Rather than burdening the database with a long list of tables and cells, it installs most of the new information into an existing database structure that doesn’t need to be modified at all. The few extra tables and cells it does install are minimal and efficient, meaning site load times will not suffer as a result of the installation. That cannot be said for databases which play host to many side-by-side WordPress installations which are installed the “old-fashioned way.”

A Note of Caution: Always Be Careful with the MySQL Database

For the most part, there are very few risks associated with installing WordPress to a database in multiple instances. But, as with any change to the site’s database, always have a backup on hand and be ready to restore your data with it. Modifying the database and placing tables side-by-side has been known to occasionally cause incidental data loss which can only be recovered with a backup. Furthermore, accidents do occur and people have been known to forget the essential step of modifying the database prefix. This results in a complete loss of pages, posts, and users.

With the right precautions in place, and careful attention to detail, it is entirely possible to run multiple WordPress blogs from within the same database. Both the old method, as well as the new WordPress Networks feature, can create advanced blog setups that enable robust levels of content, shared user access, and easier usage of the site’s resources than many competing content management solutions would allow for.

Follow Up Reading

This post is part of my WordPress How-To Series. You might also want to check out other popular post on this topic: 25 Handy Code Snippets For WordPress Developers as well as Most Wanted WordPress Hacks, Tips, And Tricks.