[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
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.
--
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