Newer WordPress users might feel a bit constrained if they’re using a web host that has a limit on the number of databases they can use for their websites, especially if that host limits them to just one database for all of the site’s functions. It can make installing many pieces of software impossible, especially if the goal is to put multiple instances of the same application into the same database. With WordPress, however, this is not as big an issue as it is with many other PHP and MySQL-based content management solutions. The software’s configuration file for all versions allows for quite a few customizations that can enable multiple blogs in one database, and a new feature in the WordPress 3.0 Dashboard actually allows multiple blogs in an entirely new way.
If your host has limited the number of available databases that your site can utilize, there’s no reason to assume that WordPress cannot be installed multiple times into the same database and function perfectly in each instance. By following a few simple steps, double-checking the configuration file, and adjusting a few optional settings, WordPress actually excels at side-by-side installations.
For Multiple Installations, it’s All About the Configuration File
Every single WordPress installation, regardless of its version, uses the wp-config.php file to determine some basic settings during the installation process. Almost all of these settings directly relate to the database. This file determines which database is used for the software, which table prefix will be assigned to the installation, and some optional settings related to users and accounts. It’s important to have a good, working knowledge of this file in order to install WordPress installations side-by-side into the same database.
It’s located in the root WordPress folder, which will likely be located in the public_html directory for the software’s main installation, and in the subfolder of every other installation on the server. By default, no settings are pre-filled; instead, WordPress developers leave placeholders where most of these settings should go. The two default settings tell the file to connect to localhost in order to find the relevant database, and they tell the software to attach a wp_ prefix to every WordPress table.
The table prefix is the first thing that needs to be altered in every subsequent WordPress installation after the first one. It’s located near the top of the file and the line of code associated with this setting looks like the following:
$table_prefix = 'wp_';
The default wp_ prefix is the most important thing that must be changed, as it relates to multiple installations in the same database. Failing to change this will force every subsequent installation to overwrite the database settings that were determined as part of a prior installation. It will also erase all entries, comments, and pages. Furthermore, multiple installations with the same prefix will cause all kinds of problems with templates, plugins, and other administrative and end user features.
The prefix can be changed to virtually anything a user prefers; due to the nature of multiple installations in the same database, and the occasional need to interact with these cells directly, it might be a good idea to give them semantically meaningful names. Many people prefer to use an all-lowercase version of the blog’s name, or prefix the tables with the administrator’s username or first name.
After this has been changed, it’s time to change the actual settings for connecting to the database. This includes changing the default database name, the username, and the database password for the installation. As this is the same for every installation, it probably requires no additional research or instruction.
Advantages of a Shared Database: Shared Users between Installations
For the typical WordPress user, or one who doesn’t want to modify the wp-config.php file, the above steps are all that needs to be done to complete multiple installations in the same WordPress database. For others, however, there is another key way to modify this file. Because the WordPress installations all share the same database, it is possible to share user accounts between all of the installations on a server that reside in that database.
This can be done on a per-installation basis, meaning that any WordPress installation can be excluded from this process simply by leaving these modifications out of the file. Because of the convenience this offers, it’s a great idea for multi-author blogs and those blogs that are administered by the same individual behind the scenes. This is done by customizing the “users” table that the installation looks for by default. It simply instructs the WordPress installation to look for a different prefix when determining user accounts and access rights.
In the wp-config.php file, two new lines need to be added to the bottom of the file to instruct the software to look in a custom table for user information. These lines are:
define('CUSTOM_USER_TABLE', $table_prefix.'YOUR_USERS); define('CUSTOM_USER_META_TABLE', $table_prefix.'YOUR_USERMETA');
The first table in this series determines where WordPress looks for usernames and passwords so that they can be used across installations. The second customized table instructs WordPress to look for user information, permissions, and profile settings that they’ve defined in one of the relevant installations. These tables can be set to absolutely any installation’s prefix, which would replace YOUR_ in the example above. For demonstration purposes, the settings have been capitalized; in real-world usage, however, the table names should be all lowercase.
An alternative way of proceeding with this change is to customize a table for user information that is separate from any one installation. By placing this line in every WordPress configuration file, even the primary installation on the website, the user table could be changed to “sitewide_users” or similar and the meta table could likewise be changed. This would make it easy to revoke single sign-on privileges from certain blogs over time if the administrator wishes to revoke universal access or the needs of the website change for any reason.
Utilizing WordPress Networks for Multiple Installations in One Database
The two methods described above for enabling multiple installations in just one database are now considered to be the old-fashioned or “manual” way of performing the process. That’s because the development community behind WordPress has been hard at work on a new feature known as WordPress Networks. This new feature is only available to users of WordPress 3.0 or higher, and it’s specifically designed to enable multi-blog websites in one database. It won’t even require every blog to utilize a separate database prefix.
What it will require, however, is adding a new setting to the existing wp-config.php file of the site’s root WordPress installation. This configuration is what enables WordPress to use the Networks feature, which is disabled by default in every installation. The line can be added immediately after the WordPress database prefix setting:
The line is identical for every WordPress installation, and no further customization of the code is required to make the feature immediately active in the WordPress Dashboard. A few settings will need to be adjusted both in the Dashboard itself and in the site’s
.htaccess file, but those will be explained during the setup process.
After enabling the WordPress Networks feature, it is possible to log into the WordPress Dashboard and begin setting up multiple blogs. The Network setup agent simply asks whether the administrator prefers to place every installation into a subhuman or a subfolder, and then it proceeds with creating the necessary new database tables and configuration settings. Administrators will then determine every blog they wish to set up as part of the new network, and they’ll determine every blog’s directory and some basic settings.
After this process, WordPress will present a page of additional configuration requirements to make the new WordPress Network feature work perfectly. A few lines will have to be added to the “wp-config.php” file manually after installation, and these lines vary based on a server’s paths and configuration. Then, WordPress Network administrators will add a few basic redirects and instructions to their .htaccess file (for Apache installations).
Finally, administrators will determine an upload directory for media from each of the new blogs, and they’ll complete setup. They’ll be taken to a new, network-centric Dashboard feature. They can then define users for blogs and automatically email, username and password information to each author as they’re created and added to the blog with authorship permissions.
The process is a bit more involved than the traditional (and now deprecated) WordPress MU installation, especially because it requires more than 10 unique, WordPress-generated lines to be added to the wp-config.php file manually. However, it uses just one database prefix for all of the relevant blogs and saves users from the longer, more intensive process of customizing those prefix and user account settings every time they install a new blog.
Proceed with Caution and be on the Lookout for Bugs and Glitches
When installing multiple WordPress installations into the same database, or setting up an extensive WordPress network full of many blogs, it’s important to pay attention to how the server responds and how each installation behaves. Even though WordPress makes the setup and configuration of these blogs easy and straightforward, servers can react in different ways and cause problems.
Use every blog extensively to ensure that it is pulling the correct information from the database, and be sure to browse between individual blogs on the same server to ensure that cookies are being placed and used properly, user information is stored only on the blogs with the custom “user” and “usermeta” tables defined, and that no PHP or wp-config.php printed errors are occurring throughout the website.
For those users who have decided to skip the manual installation of multiple blogs, and have instead chosen WordPress Networks as their way of accomplishing this, be sure that the site’s .htaccess file is performing as expected. This file, if modified incorrectly, can lead to broken links and unresolved subdomains that can send users to error pages or to the wrong blog entirely. That’s no good, and users will quickly go elsewhere for the content they had hoped to read on your website.
If everything is functioning exactly as planned, then it’s time to enjoy the results of this laborious configuration process and start setting up users, accounts, and permissions so that each blog can be filled with content by a robust group of authors. Keep an eye out for any problems as each WordPress installation ages, and especially as those installations are upgraded to new versions of the software. Always dedicate time to testing each installation periodically, and especially after an upgrade, to save readers from errors and the dreaded “404 error” page.