1. Getting Started

Each WPMU DEV membership includes credit for three free sites for members whose sights are also hosted with us.

We do this by applying a $30 credit to your membership account that can be used to defer the per-site costs associated with whatever hosting plan you choose.

You can see more about our pricing on the Hosting Overview page.

All members, including those on an introductory free trial, whose sites are hosted by WPMU DEV can create new hosting sites as needed from The Hub.

Just log in to The Hub and click the ‘Hosting’ taqb. Look for the ‘+’ sign in the top left corner to begin.

Important Information:

• Your ‘Site Title’ can be changed at any time in the future
• Your ‘Temporary Destination Domain’ CAN NOT be changed in the future. This is the link you will use to access the site before you configure DNS and choose a final primary domain.
• Your ‘WordPress admin’ user information can be changed in the future. Do remember the password you set in order to access the WordPress Dashboard once the site is ready. If you lose it, you can always do a password reset by email.
• The ‘Server’ location CAN NOT be changed in the future without changing DNS information. The best idea is to always choose the location closest to where the majority of your sites’ visitors are.
• You can convert a single site to a ‘Multisite’ network in the future, but it is much more challenging to go the other way.

Sites can be migrated to WPMU DEV hosting using our migration tool or by manually transferring files using sFTP/SSH and phpMyAdmin. We recommend using the migration tool, because it simplifies and accelerates the process and automatically resolves issues that occasionally interfere with a smooth migration.

If you run into any trouble, just start a live chat or create a support ticket, and our team will help get your site moved.

Migration Tool Method

The WPMU DEV migration tool is a server-to-server via FTP process that is much more robust than any PHP-driven, i.e. plugin, migration.

For starters, the migration tool is far less susceptible to timeout issues than PHP. Additionally, it handles all file transfers and redefines URLs in one smooth process that doesn’t involve programs or utilities that many users seldom use. As long as the source server isn’t afflicted with FTP issues, it would take the Mario Andretti of web admins to perform a faster, safer migration.

Prepare to Migrate

First, as always, backup your site. Do this at your original host. It’s unlikely that the migration process will harm your site, especially when using the migration tool, but backing up is always step one when making major changes to your site.

You will need your current FTP username and password. The migration tool connects WPMU DEV servers to your host’s servers using the same FTP credentials you would use to connect via FTP. If you don’t know them, they should be displayed on a screen you can access from your dashboard or control panel at your original host. If you cannot locate them, contact the host’s support team for assistance.

Commence Migration

From The Hub, click the Hosting tab located in the menu near the top of the page.

Click the plus (+) icon.

Click Migrate Existing Site.

The dropdown menu on the next screen will reveal a list of all the sites currently connected to The Hub. If the site you wish to migrate does not appear in the list then it is not connected, and you should click the Please add it to your Hub first link, and follow the instructions provided. Once the site is connected, select it from the dropdown menu and click the arrow to proceed.

Your site’s files will reside in a temporary domain until the DNS record changes you will make later have a chance to propagate. Enter your preferred temporary domain name in the field provided, and click the arrow to proceed.

Select the geographic area where you wish your site to be hosted.

WPMU DEV servers need to log in to your site using the same FTP username and password you use when you manage files with an FTP client. If you don’t know the credentials, you should find them in your site’s dashboard or control panel at your current host. If they do not exist, create them, paste them into the fields provided and click Start Migration.

Once they access your site, WMPU DEV servers will attempt to locate your site’s files, and most of the time they have no problem doing so. Occasionally, however, the path to those files contains an unknown directory that our servers cannot resolve and the migration will fail. If you know the FTP path to your site files, you can insert it in the WordPress install path field highlighted below to provide a backup if our server fails to find the files on its own.

If you don’t know your FTP path, the simplest thing to do is ask your current host to provide it. However, you can find it on your own by logging in to your site via FTP. Regardless of the FTP client you use, your path will be displayed on the screen similarly to how they appear in the image below. Simply cut and paste the path–in this case /site/public_html/–into the WordPress install path field. Do not include the domain name in the path but just the words and slashes as they appear in the placeholder text in the image above.

When ready, click Start Migration.

This screen allows users to monitor migration’s progress, although you can safely close the window and move on to other things without jeopardizing the migration. You will receive an email notification when the migration is complete or if it fails.

Following a successful migration, the temporary domain used in this migration is set as the primary domain for the migrated content and is viewable. In fact, unless the original site has been disabled in some way, your content is viewable at both the original URL and the temporary one. In a moment, you will be instructed to update your DNS records and set your original domain as the primary domain, at which point your permanent domain is the only one visitors can access.

Before making those updates, however, we encourage you to visit the temporary domain to verify that the migration was successful. You can do so by clicking WP Admin next to the temporary domain in The Hub.

If you discover a problem with the site following migration, contact support and our team will help you determine how best to proceed. If you are satisfied with the migration, then it’s time to edit your DNS records. See our WPMU DEV DNS Records documentation for guidance.

Manual Migration

Manual migration occurs in two phases. The first phase involves exporting the database and files that make up your site into files that can be used in phase two, which involves importing those files to your new WPMU DEV Hosting environment.

Export the Database (.sql)

We’ll be using phpMyAdmin in this guide, but if your current host provides cPanel or another manager, don’t worry. Most database managers have similar interfaces, and you should have little trouble following the steps below.

Likewise, if your host provides a tool or other simple method to export your database to a .sql file, by all means, use that tool. Otherwise, follow the steps below.

First, create a folder on your local system into which you will export your site’s database and files. We’re calling ours “Migration.”

Navigate to phpMyAdmin and click on your database name from the left side of the screen. When you see the database tables in the main screen click Export in the menu near the top.

On the next screen, leave everything as is (Quick and SQL) and click Go. You should be prompted to save an .sql file. Name the file “my_database.sql,” and save it to the local migration folder you created. Naturally, you can name the file whatever you wish as long as it’s a .sql file, but to avoid confusion, it might be helpful if your file names matched the ones we’ll be referencing in this guide.

That takes care of creating a backup of the database. Now, we must conduct a similar, but more lengthy operation for the site files.

Exporting Files

Again, if your current host provides a tool to archive your site, use it. If not, you’ll need to download and install one, such as Filezilla, WinSCP, Cyberduck or any one of the many available FTP clients.

When you’re ready, navigate to your WordPress root directory, select all the files that appear in the window and click Compress. If there are old files you’ve been meaning to delete—leftover plugin files, unused images, etc.—now would be a good time to make that happen by simply not including those files in the archive.

In the screen that pops up, select Zip Archive as the file type, name the file “my_site.zip“and click Compress.

Once the archive completes, the new .zip file will appear in your root directory. Right-click the file name, select Save As and save the file to the same migration folder in which the database is saved.

A complete copy, aka a full backup, of your site is now saved on your local system.

The Import

You will need sFTP and/or SSH credentials to import your site. If you haven’t already created those credentials, follow the steps below. If you have, skip down to the Copy wp-config.php section.

Keep in mind that sFTP/SSH credentials provide access to the inner-workings of your site. Never share these credentials with anyone who doesn’t require that access.

Create sFTP and SSH Credentials

Begin in The Hub and select the Hosting tab, which will open a list of your domains hosted with WPMU DEV. Select the temporary domain you created for this migration to access the dashboard for that domain.

Select the SFTP/SSH tab. You will need to create both an sFTP user and SSH user with the steps below.

Click Add User and select SFTP User from the dropdown menu. Once you’ve created the new sFTP user with the steps below, return to this step and go through the steps to create an SSH user.

In the popup box, create a username and password, (1) and (2). Keep these credentials handy, as you will need them to continue the migration.

For the purposes of this migration, leave the Path Restriction field (3) set to None. However, if you create credentials for other users at some point, you can provide access to one area of the site while restricting access to others.

For example, you can create an sFTP user for your graphic designer and restrict that person’s access to the Uploads folder only.

Leave the Environment field (4) set to Production, but keep in mind that staging sites require their own credentials, which you don’t need for migration but will need later to access the staging environment.

When you’re ready, click Add .

Copy the old wp-config.php

Open your FTP client and, using the sFTP user you just created, connect to your WPMU DEV temporary domain. As shown in the image below, your temporary domain name is the Host, the protocol is sFTP (not FTP or SSH, yet) and the Port is 22.

Once connected, navigate to the directory site/public.html and locate, then download the wp-config.php file to your migration.

Once that is accomplished, minimize but don’t disconnect the FTP client, and open a command prompt or terminal (Mac).

Prepping the hosting environment

At the command/terminal prompt, log in to your WPMU DEV server by entering, ssh @.wpmudev.host and when prompted, enter your SSH password as shown below.

Navigate to your new WordPress file system by entering, cd site/public_html/.

The public_html folder contains files that are created whenever a new instance of WordPress is installed. Deleting those files will ensure that your existing file structure remains the same, for the time being.

Type the command rm-rf* to delete all the files in public_html.

Minimize the command/terminal prompt if you wish, but don’t close it. Move back to your FTP client, and you will see that your site/public_html folder is empty and ready to receive the database and files saved in your migration folder.

Click the File tab in the main menu of the FTP client and then click Import. In the pop-up screen, select either the “my_database.sql” or “my_site.zip” and then click Import. When it finishes uploading, do the same for the other file.

Extracting the .zip

Return to the command/terminal prompt, which should still be logged in to the site/public_html folder, and enter the command unzip my_site.zip -d.. Don’t forget the period at the end of the command.

Your files will scroll down the screen as they inflate (extract) in your hosting environment.

Locate and Add Database Credentials

Once the extraction is complete, there are some credentials from your old wp-config.php file that need to be added to that same file in the new environment. To locate those credentials, open the wp-config.php file saved in your migration folder. You can open the file with any text editor like Notepad or a code editor if you have one.

There are six lines within that file that need to be located, and it might be faster if you used the Find tool to do so. The six lines you need to locatee are shown in the image below.

For the record, never share these credentials with anyone you don’t trust poking around in the very heart of your site.

Return to the SSH command/terminal prompt, where you will add the database credentials to the new wp-config.php file with a series of “wp config set” commands. Enter the commands one at a time following the format in the examples below. Just be sure to replace the dummy values in our examples with the real values from your old wp-config.php file.

Note that the DB_COLLATE value was empty in our wp-config.php file, as it may be in yours. In that event, simply enter a single open quote followed by a single close quote to indicate that the value is empty.

wp config set DB_NAME wpdeveloper_wpmudev_host
wp config set DB_USER wpdeveloper
wp config set DB_PASSWORD gNvsXINEc8UfAWB
wp config set DB_HOST 127.0.0.1:3306
wp config set DB_CHARSET utf8mb4
wp config set DB_COLLATE ‘’

(Use single quotes here to indicate no value)

Type this command to verify the new file has been properly updated:
wp config list DB_NAME DB_USER DB_PASSWORD DB_HOST DB_CHARSET DB_COLLATE.

A table will appear identifying the names and associated values for the database credentials. They should exactly match those copied from the previous wp-config.php file.

Importing the Database

Just like before, the database in the new hosting environment will have been populated with some default files when WordPress was installed on your server. These files need to be removed and the database made ready to accept your site’s database files.

Enter the commands below into the command/terminal prompt.

wp db reset --yes

wp db import my_database.sql

wp search-replace migrateto.wpmudev.host --url=migrateto.wpmudev.host --network --skip-themes --skip-plugins

wp cache flush

wp search-replace http://migrateto.wpmudev.host https://.wpmudev.host --url=.wpmudev.host --network --skip-themes --skip-plugins

wp cache flush

If everything went well, you should now be able to access your site in its new hosting home. In fact, the first thing you should do it peruse your entire site to be sure everything migrated properly. If it didn’t and you need help making sense of what happened, don’t hesitate to contact support.

If you haven’t already done so, you will need to update your DNS records with your domain registrar and then set your permanent domain as your primary domain, so the temporary wpmudev.host domain no longer appears in your URL. See our DNS and Domain Management documentation for guidance on modifying DNS records with several popular hosting providers.

Members are free to choose the region in which their data is stored. We currently maintain regional hosting facilities in the following locations:

• Canada (Toronto)
• Germany (Frankfurt)
• India (Bangalore)
• Netherlands (Amsterdam)
• Singapore
• United Kingdom (London)
• USA East (New York City)
• USA West (San Francisco)

All hosted customer data, backups, storage, and files are fully stored in these regions.

More hosting locations will be made available as our data center partner, Digital Ocean, brings them online.

Changing Regions
Members are free to migrate sites from one region to another at any time but should be aware that our hosted backups are regionally isolated and cannot be migrated with the site. Members should download any hosted backups they wish to preserve before initiating the migration. Hosting backups cannot be accessed from a different region, and we cannot move them for you after the fact.

Also, migrating a site to a new region will require the assignment of a new dedicated IP address, so all DNS settings will have to be reconfigured, including any IP address-dependent plugins or integrated apps.

Finally, there is downtime to consider. The original site will cease to function the moment the migration begins. The time required for the migration depends on the size of the site or sites being moved, and once the site is up in its new region, how long it takes to reconfigure its plugins and apps depends largely on the skill of the admins.

Each site that we host gets its own plan, complete with its own dedicated memory, CPUs, storage, and usage limits.

You can see all plans and specs here.

You can upgrade plans at any time. You can also downgrade a plan at any time, however, please note that downgrading more than one level may require a DNS change and for our support team to help process manually. This is because of technical limitations around storage space in the environment. In these cases, we’ll set up a new hosting environment at the desired plan, and manually migrate the site’s files and content over.

We do not set hard limits on visits, bandwidth, or traffic, but we do provide recommended visit levels for each plan to help you determine which plan will be right for you. Your site will have lower performance, including brief outages, when your memory and CPU resources are maxed out.

Factors that might use more resources and thus require you to upgrade include:

• WordPress Multisite – Multisite networks are more taxing on server resources, especially Subdomain installs and those Multisite where you will have many logged in users.
• Membership Sites – Membership sites receive a higher percentage of traffic where users are logged in, which means that caching systems in place are not as helpful in managing their load.
• e-Commerce Sites – Similar to Membership sites, increase logged in activity for checkout can cause higher server load.
• Poorly coded themes or plugins, or those that require significant interaction with the database. Some themes and plugins just aren’t as efficient for performance as others. They may also add features that require higher processing loads.

Unlike many hosts, we support (and encourage!) the use of WordPress Multisite on all plans.

However, you should be aware that WordPress Multisite networks will use more server, CPU, and memory resources than standard WordPress single installs. So, if you have more than a handful of sites, you might find you need one of the higher plans to meet your WordPress Multisite network’s needs.

Subdirectory installations (ie. mysite.com/sitename) can be created by you in your Hosting Hub.

Subdomain installations (ie. sitename.mysite.com) require manual work from our support team. Before converting or migrating a WordPress Multisite subdomain install, we need to be sure that you are able to:

1. Configure wildcard DNS for the desired domain with your domain registrar
2. Provide us with a wildcard SSL certificate for the desired name.

Please contact support to start the process for a subdomain install.

NOTE: There is a known issue with a limited set of valid file types triggering a security validation error when users attempt to upload them with the WordPress media uploader. This document covers some options for overcoming that issue. You can track WordPress efforts to resolve the issue at WordPress.org.

This guide covers how to safely modify the WordPress default limits on the size and type of files that can be uploaded to the media library and includes usage instructions regarding the following topics:

WPMU Dev Max Upload File Size
WordPress Default File Types
Adding/Removing File Types in Multisite
Modifying the File Size Upload Limit in Multisite
Adding/Removing File Types in Standard Installations
Adding Custom File Types in Standard Installations
Modifying the File Size Upload Limit in Standard Installations

After reading this guide, if you still have questions regarding file upload limits or you need help setting the right limits for your site, don’t hesitate to start a live chat with our hosting support Superheroes or submit a support ticket using the Support tab of your WPMU DEV Dashboard.

WPMU DEV Max Upload File Size

The maximum file upload size for all WPMU DEV-hosted sites is 128mb, regardless of hosting plan. Members can restrict the size of uploaded files, but the maximum size cannot be increased.

Files larger than 128mb should be uploaded by SFTP/SSH. See our SFTP & SSH documentation for information on how to upload files larger than 128mb.

To view the current maximum upload size for any site, navigate to the WordPress media uploader: Dashboard > WP Admin > Media > Add News. The upload size limit will be displayed at the bottom of the UI.

WordPress Default File Types

Members can add or remove file types from the allowed upload list as needed, but should keep in mind that each added file type creates a potential security risk for your site or network. We recommend that you add only those file types you need.

WordPress allows uploading of these file types by default:

Images: jpg, jpeg, png, gif, ico
Documents: pdf, doc, docx, ppt, pptx, pps, ppsx, odt, xls, xlsx, psd
Audio: mp3, m4a, ogg, wav
Video: mp4, m4v, mov, wmv, avi, mpg, ogv, 3gp, 3g2

Changing Multisite Upload Limits

Multisite admins can adjust both the file size and file type limits in their Network Settings, located here: Dashboard > Network Admin > Settings > Network Settings.

Scroll down to the Upload Settings section where you will find the Upload file type and Max Upload File Size fields.

Adding/Removing File Types in Multisite

In the Upload file types field enter the file extensions of the file types you want to add, separating the extensions with a single space. Delete the extensions of file types you do not want to be uploaded.

Modifying the File Size Upload Limit in Multisite

In the Max Upload File Size field enter a size, in kilobytes, up to 12800kb (128mb) to set the max size for files uploaded to this network.

Click Save Changes, and that’s all there is to it. The new file size limit will apply to every site within this network.

Changing Upload limits in Standard Installations

If you’ve seen the error message below, then you’ve tried to upload a file type that is not on your site’s upload allowed list or has failed a WordPress security validation test.

Adding/Removing File Types in Standard Installations

We’re going to show you how the plugin WP Extra File Types can resolve either issue. The first thing to do is install and activate the plugin.

While we’re at it, we will show you how to use this plugin to identify why a file might trigger a security validation error, information that will be helpful if a particular file type or a particular user experiences ongoing upload issues.

Get WP Extra File Types

Once you’ve installed the plugin, you’ll find a new option, Extra File Types, in your site’s Settings tab, located here: Dashboard > Settings > Extra File Types.

Click Extra File Types UI, and you will see a list of hundreds of file types from which to choose.

You will also see two checkbox options, shown below. Do not select either of these boxes, yet. Selective use of these options can help identify why a file triggered the upload error.

Select the file type(s) you wish to add to the allowed list and then scroll to the bottom of the UI to click Save Changes.

Try to upload the problem file again. If the upload succeeds, great! This means the file was simply not on the allowed list, and now it is. You and your users can now upload that file type as needed.

If the file triggers a validation error again, return to the WP Extra File Types UI, and select the Check only file extensions option shown below. Leave Skip WordPress checks unchecked, and click Save Changes. If the file is failing WordPress’s MIME type validation, this option will bypass that check without disabling other security measures.

Try to upload the problem file again. If the upload succeeds, great! This means there was an issue with the file’s MIME type but otherwise the file was deemed safe to upload.

If the file triggers a validation error with Check only file extensions enabled it’s time to consider whether you are certain the file is valid and not harmful. If you are uncertain, we recommend not uploading the file.

If you are certain the file is valid and not harmful, return to the WP Extra File Types UI. Uncheck the Check only file extensions option, and check the Skip WordPress checks option. Save your changes.

WARNING: Selecting this option will disable all WordPress upload security measures, and should only be used to upload files you are certain are not harmful. Leaving this option enabled allows users to upload any file type to your site, including potentially harmful files. You should disable this option when you are not actively troubleshooting an upload issue.

Try to upload the problem file again. If the upload fails with WordPress checks disabled, it is likely that the issue has nothing to do with the file type, and you should contact support for help troubleshooting the problem.

Adding Custom File Types in Standard Installations

You also can use WP Extra File Types to add files types not included with the plugin’s preset list. To do this, scroll to the bottom of the UI where you will find the Add your custom file types panel. Click the plus sign (+) to open the interface.

This will open up a table of fields where you must specify a file format by completing the Description, File Extension, and MIME Type fields. The Internet Assigned Numbers Authority (IANA) is responsible for all official MIME types, and you can find the information required for these fields at their Media Types page. Click Save Changes before returning to the media uploader.

Modifying the File Size Upload Limit in Standard Installations

Once the plugin is activated, Increase Maximum Upload File Size will appear as a new option near the bottom of your Admin Menu. Click the link to open the plugin.

The plugin contains a single drop-down menu. When you open the UI for the first time, it will display your current max upload file size.

Click the drop-down menu to view the menu of various upload size limits. Setting a file size larger than 128mb will not override the 128mb max upload limit. Select the desired upload limit, and click Save Changes.

Once a limit has been set, the plugin displays both the WPMU DEV Managed Hosting default limit of 128mb and the lower limit established by the plugin.

Our servers run NGINX, the fastest, most stable web server around, and NGINX does not support .htaccess. Members accustomed to using .htaccess to enable or disable functionality needn’t worry, however; because all the functions typically associated with it are automatically handled by our servers.

Servers with the AllowOverride directive on, a prerequisite for .htaccess files, process requests at a much slower rate than NGINX servers. In fact, NGINX servers process many more requests per server than their Apache counterparts in large part because they don’t support .htaccess.

Some of the common uses for .htaccess that our servers automatically achieve are:

Permalinks – Our servers are configured to automatically handle permalinks for you.

Caching – Our servers handle caching for you, no need to install plugins or modify .htaccess files.

Redirects / rewrites – Redirects can be handled using a plugin or via custom server-side redirects that WPMU DEV support can install for you.

Security – Many WordPress security plugins have you modify the .htaccess file to install security rules. Fortunately, WPMU DEV hosting already has these security precautions in place at the server level.

Regardless of what you’re trying to achieve, if you’re doing it with .htaccess, then you’re probably doing it wrong. Instead, contact our support Superheroes and they will help you figure out how to implement the same thing without creating or modifying a .htaccess file.