Removing ms-files.php after upgrading an existing Multisite installation to 3.5

Removing ms-files.php after upgrading an existing Multisite installation to 3.5

One of the features in the WordPress 3.5 release towards the end of last year was the removal of ms-files.php processing for static multisite files. For new installations this is the default mode, however for existing installations it is a completely optional, and manual, process to change to the new mode.

While looking into the manual option, I’d seen a few requests from people wondering if a plugin existed, so wrote one to ease the process a little (download below). Whilst not feature-complete, in that URLs within widgets and theme options still need to be changed manually, it could be useful as a starting point for someone.

For more details about what you need to do to change an existing installation manually, take a look at Mika Epstein’s post on dumping the ms-files filter. While not difficult, the plugin does help ease some of the more laborious parts of the process.

WordPress 3.5 now turns ms-files.php off by default for new multisite installations, but it is also possible to turn it off manually.

Why would you want to do so?

If you have an existing multisite installation why would you want to change how uploaded files are processed?

For pretty much the same reasons it was turned off for new installations! Single site WordPress uses the uploads directory to store uploaded images. Prior to version 3.5, sub-sites in a WordPress multisite installation required a special directory called blogs.dir to store uploaded files, and accessed these images through a file handler called ms-files.php. However a web server can serve up static files such as images more efficiently by itself than by loading them through PHP. Avoiding the ms-files.php filter is therefore a good thing.

What can this plugin do?

You can use this plugin to migrate an existing multisite installation to use the uploads directory instead of blogs.dir. It works by flipping the new switch that controls how multisite files are processed and updates your network. In more detail, it sets the ms_files_rewriting flag to 0 in the wp_sitemeta table, resets the upload paths for each sub-site, and finally copies all files from blogs.dir/[id]/files/ to uploads/sites/[id]/ (where [id] is the site identifier).

It can also optionally update links in posts and pages to use the new URL path, however links in widget settings and theme & plugin options will not be changed.

 

11 Comments

  1. Really: this plugin is an excellent service to the WordPress multisite community, Thanks!

    Reply
  2. Hi, copied plugin to plugins directory and nowhere it shows up, also tried to access it by typing in url address: /wp-admin/network/settings.php?page=migrate_multisite_files_page this shows that i don’t have permissions… i suppose that because of plugin not activated… but i can’t see this plugin in any plugin page…

    Reply
    • When you say ‘copied to plugins directory’, did you unzip it first? If not, then that’s most likely the problem. If you did, then check the file permissions to be sure they’re accessible by your web server. Finally, you will need to be a network admin to be able to see and network activate the plugin.

      Hope this helps. If you still have problems getting it to work, then either:
      1) think carefully about whether you really want to proceed further; problems now may mean more problems later :)
      2) send more information about your environment to support@yunopress.com, including access credentials if possible, so I can take a closer look at what’s happening

      Reply
      • yes of course i unzipped :) not the first time with wordpress or plugins. i’am superadmin on multisite wordpress…

        Reply
        • Had to check :)

          What you described is quite rare. What happens if you put the file in your mu directory? Alternately, if you’re comfortable editing php files try removing some of the sanity checks (on wordpress version and multisite flags for example). Those checks are in there for a reason though, so would be worrisome if that made a difference…

          Good luck and please let me know what you find!

          Reply
          • found the problem, we are running WordPress 3.5.1,
            and if i uncomment:
            if (version_compare($wp_version,”3.5″,”<")) { exit ($exit_msg); }
            then plugins shows on plugin pages. i see that acctualy this is written right, but dunno why its not working.

          • Thanks for letting me know what the problem was. Glad you got it sorted.

  3. Just want to put out a huge “Thank You”

    The last major change to wpmu file layout (REALLY long ago) was when wp-inst was removed. I took days and eventually I gave up and redid the whole damn thing.

    I thought the same would happen with this change, but I ran it on my test site and all was good. So relieved.

    One small bug/non-issue (perhaps with my setup, quite old): when I first activated it, the plugin’s page stated that the blah blah (I forget) was not set so I couldn’t make it process anything. So, I first did an undo, then did the process and everything worked like a charm.

    Just a super-huge thanks again!

    Reply
    • Thanks for the feedback – glad you found it useful!

      Reply
  4. I assume this will break all previous media file links, correct? Any way to preserve them with an htaccess trick or similar?

    Reply
    • The media files are copied to the new location keeping the originals under the blogs.dir folder. If you had links pointing directly to files then those would still work (but not if they went through the ms-files filter). You could probably setup a bunch of RewriteCond rules in the htaccess, however it would probably be easier to just update your links.

      Reply

Leave a Reply

Share This

Share this post with your friends!