• Skip to content
  • Skip to primary sidebar
  • Skip to footer

Foliovision

Main navigation

  • Weblog
    • FV Player
    • WordPress
    • Video of the Week
    • Case Studies
    • Business
  • About
    • Testimonials
    • Meet the Team
    • We Support
    • Careers
    • Contact
    • Pricing
  • Products
  • Support
    • FV Player Docs
    • Pro Support
  • Login
  • Basket is empty
Affordable VAST/VPAID for Wordpress has arrived. Serve ads with your videos starting today!

How to run WP Multisite 4.1 in a subdirectory

19 January 2015 / Alec Kinnear / 9 Comments

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.

foliovision login screen
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 in root
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 //cdn.foliovision.com/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.

wpmu in a subdirectory

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.

Alec Kinnear

Alec Kinnear

Alec has been helping businesses succeed online since 2000. Alec is an SEM expert with a background in advertising, as a former Head of Television for Grey Moscow and Senior Television Producer for Bates, Saatchi and Saatchi Russia.

Categories: WordPress Tags: hosting, multisite, WordPress, wpmu

Related Posts

  1. FV WP Link Robot Installation

    FV WP Link Robot Installation

  2. How to prepare FTP uploaded images to work with SEO Images in Filezilla

    How to prepare FTP uploaded images to work with SEO Images in Filezilla

  3. How to update your WordPress plugins from a local copy on Windows

    How to update your WordPress plugins from a local copy on Windows

Reader Interactions

Comments

  1. virre 11 November 2014 at 11:14 pm

    Thank you! I’ve been looking for a solution for this problem for a long time! Now my MU site works as it could.

    Reply
  2. Morten 17 February 2015 at 9:21 am

    Looking forward to try out your solution.

    I have been searching far and wide for a long time to get some clarification on multisite setup with WP files in a subdirectory.

    I think your article here is the only one on WWW that addresses this issue and thus I guess that all other multisite installs has the core WordPress files installed in the root directory.

    Reply
  3. RamaEl 27 March 2015 at 9:28 pm

    Updating: RewriteRule ^(wp-(content|admin|includes).) wordpress/$1 [L] RewriteRule ^(..php)$ wordpress/$1 [L] With my install’s directory was what fixed the redirection for me. THANK YOU, your post helped me out very much, SO GLAD you posted it!

    Cheers!

    Reply
  4. Tim McKay 9 September 2015 at 5:39 pm

    Is this just for storing WP in a subdirectory and using the subdomain multisite or does this solve the issue between subdirectory WP and subdirectory multisites?

    Reply
  5. Martin 11 September 2015 at 5:06 pm

    Hello Tim,

    we are using subdomains on our site, so I’m not 100% sure.

    Thanks, Martin

    Reply
  6. Morten 14 September 2015 at 8:57 am

    It’s about creating a WordPress Multisite installation where the Wordpress files reside in a sub-folder. During setup you should be presented with the option to pick sub-domain or sub-directory based WP Multisite, which refers to the domain structure of you multisite; subsite.domain.com or domain.com/subsite.

    Reply
  7. Todd 8 December 2016 at 10:14 pm

    Thank you very much – this post was super helpful to our dev team.

    Do you have any tips for getting this to work with a VVV environment? See github.com/Varying-Vagrant-Vagrants/VVV It’s a pretty popular environment among Wordpress developers, and it runs on nginx.

    I followed the tutorial to the tee — I installed a single site, then moved it to a subdirectory, and then enabled multisite.

    It’s working great for the primary site on the network, but I’m struggling with the nginx rewrites. The Network Admin keeps throwing nginx 404 errors because it’s trying to resolve at example.com/wp-admin rather than example.com/wordpress/wp-admin

    I could probably get around it temporarily by running a search/replace on “example.com/wp-admin” to “example.com/wordpress/wp-admin”, but I don’t think that’s a sustainable solution because every new site that gets added would then need to re-run the search//replace script.

    I tried updating wp-config define(‘PATH_TO_SITE’, ‘/’) to read define( ‘PATH_CURRENT_SITE’, ‘/wordpress/’ ) , but then I get a “Too many redirects” Error and can’t access the site.

    I’m far from a server expert. My question to you is how would you modify the default nginx file that VVV includes for all sites? You can view it at the github repo: github.com/Varying-Vagrant-Vagrants/VVV/blob/develop/config/nginx-config/nginx-wp-common.conf

    Reply
  8. Martin 13 December 2016 at 10:03 am

    Hello Todd,

    we are currently only using NginX for serving of static files, so I’m not able to check this easily.

    It appears to me the “Rewrite multisite in a subdirectory” part of the NginX config should cover the /wordpress directory just fine.

    Thanks, Martin

    Reply
  9. Ben Neale 31 July 2017 at 12:13 pm

    Many thanks for this. I’d been looking for an Nginx solution to this problem – and you’ve provided it.

    I’m still having one issue however with the Add Site form – because it redirected the form action /wp-admin/network/site-new.php?action=add-site to /wp/wp-admin/network/site-new.php?action=add-site it then created a invalid referrer / nonce issue. – with “Are you sure you want to do this? Please try again.”

    If I change the form action to ‘/wp/’… using Inspect Element in the browser, it works as as expected. Any idea how to make this right

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

You can click here to Subscribe without commenting

Primary Sidebar

Categories

  • Business
  • Camera Reviews
  • Case Studies
  • Design
  • FV Player
  • Internet Marketing
  • IT
  • Life
  • SEO
  • Slovak
  • Video of the Week
  • WordPress

Footer

Our Plugins

  • FV WordPress Flowplayer
  • FV Thoughtful Comments
  • FV Simpler SEO
  • FV Antispam
  • FV Gravatar Cache
  • FV Testimonials

Free Tools

  • Pandoc Online
  • Article spinner
  • WordPress Password Finder
  • Delete LinkedIn Account
  • Responsive Design Calculator
Foliovision logo
All materials © 2025 Foliovision s.r.o. | Panská 12 - 81101 Bratislava - Slovakia | info@foliovision.com
  • This Site Uses Cookies
  • Privacy Policy
  • Terms of Service
  • Site Map
  • Contact
  • Tel. ‭+421 2/5292 0086‬

We are using cookies to give you the best experience on our website.

You can find out more about which cookies we are using or switch them off in .

Powered by  GDPR Cookie Compliance
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Necessary Cookies

Strictly Necessary Cookie allow you to log in and download your software or post to forums.

We use the WordPress login cookie and the session cookie.

If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.

Support Cookies

Foliovision.com uses self-hosted Rocket.chat and self-hosted Freescout support desk to provide support for FV Player users. These cookies allow our visitors to chat with us and/or submit support tickets.

We are delighted to recommend self-hosted Rocket.chat and especially Freescout to other privacy-conscious independent publishers who would prefer to self-host support.

Please enable Strictly Necessary Cookies first so that we can save your preferences!

3rd Party Cookies

This website uses Google Analytics and Statcounter to collect anonymous information such as the number of visitors to the site, and the most popular pages.

Keeping this cookie enabled helps us to improve our website.

We reluctantly use Google Analytics as it helps us to test FV Player against popular Google Analytics features. Feel free to turn off these cookies if they make you feel uncomfortable.

Statcounter is an independent Irish stats service which we have been using since the beginning of recorded time, sixteen years ago.

Please enable Strictly Necessary Cookies first so that we can save your preferences!