To make use of the WordPress multisite function, you need to create a wildcard subdomain first. If you use Plesk version 10.4 or later, follow the instructions below to add a wildcard subdomain. If you are running an earlier Plesk version, go here, but be warned that the instructions are rather technical and require root level access to the server. Consider upgrading or migrating to a later Plesk version.
And there you have it! Now, whenever someone browses a subdomain you have not explicitly created in Plesk, they will be served the parent domain instead. Follow these instructions to finish setting up your WordPress network.
In WordPress MU (WPMU), and in WordPress 3.x, webmasters can enable subdomain mode to create sub-sites of the main domain name (e.g. support.example.com as opposed to example.com/support/).
There is already a lot of help and support on the internet for webmasters whose hosting service or servers use the cPanel control panel to manage the webhosting environment, and for setting up the wildcard subdomain settings needed for WPMU and WordPress 3.x with multisite enabled (WP-MS).
However, there is a lot less help for webmasters whose hosting service provide Parallels Plesk Control Panel as a replacement for cPanel, and Plesk has several quirks that do not exist in cPanel hosting.
The standardised instructions included for both WPMU and WP-MS for enabling sub-blogs / sub-sites work fine for cPanel based hosting, but less so for Plesk Panel based hosting, unless you are thoroughly familiar with Plesk's idiosyncrasies.
This page aims to provide a straight forward, step-by-step guide to getting wildcard subdomain mode enabled under Plesk based web hosting.
The instructions on this page are for WordPress users of all experience levels, whether they have server root access or not.
If you are not planning to use WordPress sub-blogs or sub-sites in subdomain mode, you do not need these instructions.
If you follow the standard WordPress instructions for enabling wildcard subdomains under Plesk hosting, you will lose access to web-based email interfaces (browser based email use) for email accounts under your main domain name.
The reason for this lies in Plesk-specific reconfiguration of server-level settings that must be "undone". This mainly affects webmasters using Plesk Panel 9.x series for both Linux and Windows.
Follow these steps :
This will place the mail host names, and their associated wildcard mail-user names (shown in DNS), above and before the website domain and subdomain names in the loading sequence.
The reason for doing this is to ensure the webmail host names are loaded and resolved BEFORE wildcard subdomain name resolution for webpages (WordPress's main and sub sites).
If it is not done, you will be able to see and use the WPMU and WP-MS sub-sites without any problem, but you will not be able to use the browser based email interfaces, nor use the Plesk control panel buttons to view, edit, and send email.
Plesk's official "workaround" containing a variation of the above instructions, including command line parameters, are here: http://forum.parallels.com/showpost.php?p=394330&postcount=36
That link also includes their instructions discussed in the next section below, which DO NOT work for enabling wildcard subdomains for WPMU and WP-MS - do not use the Plesk instructions, use the solution posted below, for the reasons shown.
Plesk's official workaround for creating wildcard subdomains (linked above) does not work for WordPress sub-blogs and sub-sites. This occurs for a very simple reason.
Under Plesk, your main domain's installation of WordPress lives in the main folder for putting your web files.
When you create a wildcard subdomain using the Plesk instructions, it creates that named subdomain and its site files folder in:
The purpose of this Plesk method is to host a new webscript in the subdomain folders that is independent of the script in the main domain's folder hierarchy. Although this is not unique to Plesk, the way they control and manage it is different to cPanel (behind the scenes) and it simply does not work for WordPress's virtual wildcard subdomains that are stored in the database, not on disk.
Because of this, you have to ignore the Plesk instructions for creating a wildcard subdomain when trying to setup WPMU or WP-MS.
This is going to sound odd if you have already been struggling to get wildcard subdomains working, but the standard WordPress instructions for creating wildcard subdomains DO work ... if you apply them in the basic Apache Web Server way, not the Plesk way.
The instructions are below - again if you have root access, do them yourself. If not, send them to your web hosting company to do for you.
In /var/www/vhosts/domain.com/conf/ create or edit a vhost.conf file.
Note, for Plesk 10 you may find you need
Do not add the <ServerName> or <VirtualHost> headers - just add the server alias command and wildcard domain name on a single line as shown above.
Author's note - On my install, being a belt and braces type of guy, I also added these lines (without line numbers) after the ServerAlias line:
Save the vhost.conf file and restart Apache again (as above).
That sets up the server to read the wildcard subdomain names, and point the page requests to the WordPress installation's root folder with its htaccess file, for resolving to the correct home or sub-site / sub-blog.
But, in order to get there, the DNS wildcard still has to be set - the standard WordPress instructions work fine for this too -
Note - if you add the DNS record as an A record ( *.example.com in A xxx.xxx.xxx.xxx ) you might get some delays in resolving blog addresses initially. Using the CNAME entry in testing proved less troublesome. Your experience may differ.On Plesk 11 I had to run this shell command as root in order to rebuild the vhosts config http://forum.parallels.com/showthread.php?t=260504 (Post #4):
You should now be good to go.
Log into your site, go to the home site Administration Panel - Settings - Permalinks - and save them again. This is a MUST DO or you could start getting strange behaviour from your browser, such as trying to download and save an x-httpd-php file instead of opening a webpage.
Then, navigate around the administration side of your main and sub blogs, and do the same on the public pages - make sure you're not getting any weird dump-outs.
If all is fine in WordPress, then try going to webmail.yourdomain.com and you should see the login for your default webmail client.
If all that works fine, allow yourself a WOOT!
I tried the above, and it does manage to get the webmail working alongside a Wordpress Multisite installation on subdomains, but I wanted to have some Plesk-based subdomains as well. Plesk puts the configuration of its subdomains AFTER the configuration for the main domain in the httpd.include file, so putting the wildcard ServerAlias rule in vhost.conf for the main domain catches everything, and apache ignores the Plesk configured subdomains that come after it.
The solution here is to put the apache rules with the wildcarded ServerAlias in a file in the /etc/httpd/conf.d folder (call it zzz_wildcard.conf to make sure it loads last). The file should contain the first VirtualHost entry for port 80 from the httpd.include configuration for the domain:
<VirtualHost XXX.XXX.XXX.XXX:80> ServerName example.com:80 ServerAlias *.example.com =========================== all the other plesk stuff =========================== </VirtualHost>
Thanks to Dave in this thread for the solution.
There are four main stages to setting your server up to run WordPress in multi site subdomain mode, when using wildcard subdomains on a Plesk Panel administered web hosting server -
As long as you perform all four in sequence, and remember to restart Apache, you shouldn't have any problems.