id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
19235,Turn ms-files.php off by default,nacin,nacin,"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 manually.

== 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 rules.

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.",task (blessed),closed,normal,3.5,Multisite,3.0,normal,fixed,has-patch,ocean90 johnbillion@… info@… johnnytee unsalkorkmaz@… djeyewater dennen@… boonebgorges@… steve@… seancojr isaac@… amaury@… kieranmasterton lightningspirit@…