How to run WP Multisite 4.1 in a subdirectory

History of article updates

• January 19th, 2015 – fix for WP4.1
• February 20th, 2015 – figuring out the true cause
  • So how did this issue really started?
  • Users – how to really fix your broken WP Multisite
  • WordPress Multisite changes a lot with little notice

We recently found our users were having difficulty resetting their passwords. As many of our users are paid owners of our WordPress video player FV Player Pro, it is essential they are able to log in to manage their licenses. Log in issues were a very big deal for us and we had to stop the presses to get it working right. Much thanks to Klaus for helping us track down the bug.

The attractive, partially functional Foliovision login screen
of earlier today: “Lost your password” link was broken

What as the issue? The link from “Lost your password” went to https://foliovision.com/wp-login.php?action=lostpassword and not https://foliovision.com/directory/wp-login.php?action=lostpassword where we needed it. This was a consequence of running WordPress Multisite in a subdirectory.

As we are developers, we have a lot of other folders and files we want in public_html website root folder, besides WordPress which makes a right mess of public_html. We figured this out for 3.9.1 but now WordPress has made it impossible to update our multisite.

WordPress files which we want out of website root folder (public_html)

UPDATE January 19th, 2015:

This section is now deprecated and we recommend you read the February 20th, 2015 update below.

We figured out that the network_admin_url() function doesn’t count on WordPress install in a directory at all. network_admin_url() is called in many places like admin files like wp-login.php. So rather than applying a patch to the specific instances, it’s better to stamp it out with a mini-plugin in wp-content/mu-plugins

The bug report was filed into WordPress Trac and we published a quick fix for this bug. It’s a PHP code you need to add to your wp-content/mu-plugins folder. You can download the raw code at the Github link here: gist.github.com/foliovision/52e8a2bc5ae68eb73844

Now all admin files including “Lost your password” are running correctly. With this fix, it’s now possible to update our WordPress multisite install without making changes to wp-config.php each time for the update.

UPDATE February 20th, 2015: What was really broken when running WordPress Multisite in a directory?

Previously we tracked down which function generates the bad output and came up with some quick code to fix it. Then we reported it to WordPress developers. We were given some instructions about how to run WordPress Multisite (which involved tweaking wp_options database table) in a directory which we followed.

These instructions helped, but we thought – why can’t this just work without hand tweaking the database settings? So we were about to report this as an issue and suggest improvements to WordPress.org Create A Network documentation and improving the install scripts to handle this automatically.

But to be 100% sure we are on the right track, we setup up new WordPress, move it to a directory and then changed it to Multisite. The issue which we reported to WordPress developers didn’t occurred.

• WP Admin Dashboard was working fine : http://lifeinamovie.com/site/wp-admin/
• WP Network Admin loaded ok as well, although without /site in URL: http://lifeinamovie.com/wp-admin/network/
• Lost password dialog worked, even though it’s not on /site as well: http://lifeinamovie.com/wp-login.php?action=lostpassword

This forced us to have on more careful look at all of our plugins and everything. We found some tweaks in the theme functions.php file which were causing these issues.

Note: functions.php is a popular place to drop in any quick fixes, same as wp-content/mu-plugins directory. You don’t have to create a new plugin to put in your fix, but the downside is that you might forget about some of these tweaks.

We removed these tweaks and now our site finally runs without any issues and no tweaks are needed.

We noticed other issues or changes though, so read on!

So how did this issue really started?

Our site has been switched to Multisite back in the days of WordPress 3.5. We were worried that if we move our WordPress out of the directory, we might break our bbPress forums integration, or other parts of the site. From previous experience we knew that WordPress Multisite can’t be run in a directory. We were surprised that it worked, but thankful that it did.

What’s the answer to this mystery? WordPress 3.5 was the first version which could work as a Multisite when installed in a directory:

• See this ticket, where it was made possible: #19796 Multisite installs should work with WordPress in a subdirectory
• See the WordPress 3.5 release notes where it says: “you can now install MS in a sub-directory”

The release notes don’t mention WP Multisite or WP MU but MS (MultiSite – result of merging WordPress MU and WordPress in WordPress 3.0). No wonder we haven’t noticed this change. WordPress.org, you do a great job, we like WordPress and we like contributing by our plugins, but please don’t use cryptic language in your Release notes!

So our new WordPress Multisite was working! But later, in one the next versions (around 3.8 – 3.9), there was some change which broke our setup and we put in some quick fixes just to keep our site running. It’s hard to say what exactly could it be as we had a lot of changes:

• going HTTPS
• switching to NginX – you can’t use the recommended .htaccess anymore, you have to figure things out by reading the WordPress.org NginX article
• our .htaccess and wp-config.php was locked down from any changes – if core WordPress was supposed to fix something automatically it couldn’t

Then, after upgrading to 4.1 (or perhaps even 4.0) this code was no longer needed and it break things – caused our issues with the login window.

Users – how to really fix your broken WP Multisite

We see other users with similar issues. What troubleshooting steps should you take? You need to kill any tweaks which you might put in to keep your Multisite working with previous WordPress versions. Following steps might kill your site, but they are easy to revert if you have the experience:

• make sure you use the recommended .htacces and wp-config.php which you can find in wp-admin -> My Sites -> Network Admin -> Settings -> Network Setup. Backup your current files and really put in the recommended defaults
• rename your plugins and mu-plugins folders to quickly deactivate any plugins
• rename your theme folder – wp-admin section will run without it

If you do the above, you should find that your WordPress in a sub-folder works with Multisite perfectly fine.

WordPress Multisite changes a lot  with little notice

Here are some changes which we noticed happening without announcement and the level of documentation varies. Here’s what we found and hopefully we can save some administrators from frustration by posting about this:

Multisite Files Rewrite (ms-files rewrite) was suddenly disabled, but there was no announcement about it. Before WordPress 3.5 the media files were stored in hideous wp-content/blogs.dir/blog_id/files/year/month/filename.jpg kind of folders which were rewritten to /files/year/month/filename.jpg URL structure. Suddenly this was disabled and changed to wp-content/uploads/site/blog_id/year/month/file-name.jpg kind of structure.

Disabling this feature (ms-files rewrite) was decided here in ticket #19235 Turn ms-files.php off by default in WordPress bug tracking, mainly because of performance reasons, which are entirely valid (we always put in static rewrite into .htaccess for these files or use the NginX map module to get it done).

This happened 2 years ago, but we only found out about it now. That’s because this functionality was kept in the WordPress code (our sites didn’t break – thankfully!), it’s just no longer an visible option. So we are only finding about it now that we installed some new WP Multisite-websites. WordPress.org, please put up some early warning if you decide to remove this functionality entirely.

If you want to use this feature, do the following (quick tips for experts only!):

1. grab your database client (phpMyAdmin or what you use on your computer) and set ms_files_rewrite in wp_sitemeta table to 1
2. move files (if any) from wp-content/uploads/site/blog_id to wp-content/blogs.dir/blog_id
3. add the required .htaccess rules
   

   • for subdomain WP Multisite install:

     RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

   • for subdirectory WP Multisite install:

     RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]

   • as you can see this loads some PHP script to serve the file, which we don’t recommend, it’s better to check blog path or subdomain in htaccess and do the rewriting there
4. also don’t forget to create 301 redirections and update the article content using search and replace

While it’s great that this feature keeps working, we are worried about its future. The documentation is also pretty weak.

Option to pick sub-domain or sub-directory based WP Multisite – during our recent installing of new WordPress Multisite, we noticed that this option is missing. That really got us confused. We looked for some documentation and here it is: WordPress.org Create A Network  documentation says:

You are given the choice between sub-domains and sub-directories, except when existing settings restrict your choice.

…and it also adds information when you are not presented with these options, click WordPress.org Before You Create a Network.

That documentation is great, but there could be a warning directly on the Multisite install screen.

Original Fix to install WordPress Multisite into a directory

A while ago, we upgraded our single site WordPress install to a multisite network install. We did everything as described in the following articles:

• Before You Create A Network
• Giving WordPress Its Own Directory
• How to Create a network

The most uncommon part was that we like to run our WordPress installs in a subdirectory (e.g. /wordpress/): we don’t like the mess resulting from having WordPress files together with other files we have in the site’s root.

Everything went smoothly and everything ran as it was supposed to.

Then we did an upgrade to the latest WP version. Nothing seemed to work as expected.

After poking around and testing with a new install, we have found the points where things stopped to work.

Database

• in wp_blogs database table, path should be set to /
• in wp_site database table, path should be set to /

Constants in the main config file

• in wp-config.php make sure there is

  define('PATH_CURRENT_SITE', '/');

  (instead of define('PATH_CURRENT_SITE', '/wordpress/');)

Correct .htaccess

• if you’re using .htaccess, the install should have guided you through the install. Just for reference, in WP 3.9.1, this is what the .htaccess looks like:

  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.php$ - [L]
  
  # add a trailing slash to /wp-admin
  RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
  
  RewriteCond %{REQUEST_FILENAME} -f [OR]
  RewriteCond %{REQUEST_FILENAME} -d
  RewriteRule ^ - [L]
  RewriteRule ^(wp-(content|admin|includes).*) wordpress/$1 [L]
  RewriteRule ^(.*\.php)$ wordpress/$1 [L]
  RewriteRule . index.php [L]

Correct nginx configuration file

• On nginx, the nginx config file has to be updated so that the network administration works.

  • rewrite ^(/wp-.*) /wordpress$1 permanent;

    and 

  • if (!-e $request_filename) {
       rewrite ^(/wp-.*\.php)$ /wordpress$1 permanent;
    }

    should be added in the right places, considering /wordpress is the subdirectory where your WP resides.

For the above, I’ll post an example of a simple nginx configuration file, considering my site is example.com and the WordPress directory is /wordpress. In this example, we’re running php5-fpm with nginx.

server {
   listen 1.2.3.4;
   server_name example.com www.example.com sub1.example.com;
   access_log /var/log/nginx/example-access.log;
   error_log /var/log/nginx/example-error.log;

   root   /www/example/public_html;
   index  index.html index.htm index.php;

   location ~ .*\.(php|php5)?$ {
      #added after upgrade to WP 3.9.1 in '/wordpress' subdirectory:
      if (!-e $request_filename) {
         rewrite ^(/wp-.*\.php)$ /wordpress$1 permanent;
      }
      try_files $uri =404;

      include fastcgi_params;
      fastcgi_pass unix:/var/run/php5-fpm.sock;
      fastcgi_index index.php;
      fastcgi_param  SCRIPT_FILENAME  /home/example/public_html$fastcgi_script_name;
      fastcgi_read_timeout 300;
   }

   location ~* .(js|jpg|jpeg|png|gif|ico)$ {
      expires 7d;
   }

   location / {

      index  index.php index.html index.htm;

      # if the requested file exists, return it immediately
      if (-f $request_filename) {
         break;
      }

      if ($http_host = sub1.example.com) {
        rewrite ^/wp-admin/?$ /wp-admin/index.php last;  #  wp-admin fix for domain mapped site
        rewrite ^/files/(.*) /wp-content/blogs.dir/2/files/$1 last;
      }

      # all other requests go to WordPress
      if (!-e $request_filename) {
         #added after upgrade to WP 3.9.1 in '/wordpress' subdirectory:
         rewrite ^(/wp-.*) /wordpress$1 permanent;
         rewrite . /index.php last;
      }
   }

}

I hope this helps you if you run into problems setting up a WPMU in a subdirectory.