[wp-trac] [WordPress Trac] #19235: Turn ms-files.php off by default

WordPress Trac wp-trac at lists.automattic.com
Fri Nov 11 21:38:56 UTC 2011

#19235: Turn ms-files.php off by default
 Reporter:  nacin         |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Multisite     |    Version:
 Severity:  normal        |   Keywords:  dev-feedback 2nd-opinion
 Similar to what we did with global terms, I suggest we disable ms-
 files.php handling for new installs. Reasoning follows.

 == Spam Control? ==

 The primary intent of ms-files.php, I presumed, was to prevent images from
 being accessible for spammed, archived, or deleted blogs. Ultimately, this
 is not indicated in the UI, and if it goes away, most admins are not going
 to miss it. If a site needs to be deleted, it can just be deleted (for
 most networks). If you do need this kind of protection, then you're
 clearly running a more advanced network, and you should enable it

 == Security? ==

 ms-files.php additionally does mime-type checking. Contrary to what many
 may assume, though, it does not check against the upload file types option
 that is on the Network Settings page. Rather, it only uses
 wp_check_filetype(). There is a filter on wp_check_filetype() which could
 be used to add/remove mime types, but since plugins are not yet included,
 it cannot be used out of the box.

 == Performance? ==

 Reading a file out via PHP is terrible for performance. While some caching
 headers are applied, it would be far more efficient if these are applied
 directly by the server. To load a typical blog page with 10-15 images in
 the posts might just require loading WordPress 11-16 times, depending on
 what is in browser cache. (Granted, SHORTINIT, but it's still bad to spin
 up a PHP process for this.)

 If you want to leverage ms-files.php, you will need object caching (at the
 very least). But realistically, it's the only aspect of multisite that
 truly requires object caching out of the box. Removing it will make
 multisite easier to use and remove one of the biggest differences between
 single-site and multisite. Someone like otto42 who is simply running a few
 blogs that are statically cached has no necessity for ms-files.php.

 == We Can Be Backwards Compatible ==

 ms-files.php is simply enabled by routing /files/ through the handler via
 mod_rewrite or web.config. Since we do not touch rewrite rules for network
 sites after installation, we can turn this off for new installs without
 any impact.

 For implementation, we should just continue to use the /wp-
 content/uploads/ directory. We can simply create a new directory called
 /sites/ in /uploads/ — we'll already have permissions for wp_mkdir_p() —
 and then add blog ID folders in there. No more blogs.dir, no more
 blogs.php, no more ms-files.php.

 For existing sites wanting to transition over, they will need special
 rules to rewrite /files/ to the new location. Since we will be keying
 things by blog ID on the FS level, we may need some sort of ms-files.php-
 like migration script that simply does the lookup then fires a 301
 redirect. This of course would only be opt-in if they modify their rewrite

 Finally, we would need to modify (for new installs) the upload paths and
 URLs (fileupload_url, upload_path, etc.). We would probably need to
 introduce a function similar to global_terms_enabled(), such as
 ms_files_rewriting_enabled(), to handle such toggles.

 Note, these new filesystem paths would expose blog IDs. I don't know of
 another instance where these are currently exposed, but I don't see a
 reason to care. It should be noted that blog IDs on WordPress.com are
 exposed assuming you realize how wp.me shortlinks are generated.


 Is this going to be a pain? Yes. But in the end, it'll definitely be a
 worthwhile transition.

Ticket URL: <http://core.trac.wordpress.org/ticket/19235>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software

More information about the wp-trac mailing list