Member Likes (0)
A few months ago one of my client sites hit the 32k link limit on an ext3 filesystem. Upgrading and moving the media elsewhere are not valid options. I'd also like to AVOID modifying core if possible. That's where the problem is.
What I'd like to be able to do is simply MOVE the media to a tiered structure to prevent this from happening again. In other words, change this:
wp-content/blogs.dir/1234/ wp-content/blogs.dir/33669/ wp-content/blogs.dir/48484/
wp-content/blogs.dir/12/1234/ wp-content/blogs.dir/33/33669/ wp-content/blogs.dir/48/48484/
Hooking into get_option for upload_path is simple enough, and works fine as far as uploading. But it doesn't address actually viewing the media. ms-files.php is setup to minimize it's load by using a short init, which means plugins and hooks simply aren't called, and I can't see anywhere within the entire WP engine loading process that I can inject a *dynamic* parsing routine for this specific pattern.
I can define a constant (BLOGUPLOADDIR) within wp-config...but in order for this to work the constant has to be able to determine the blog_id, which isn't known during the wp-config or wp-settings stages, and between there and the default ms constant declarations there simply aren't any hooks to effect modification of the values for assignment, and where it passes the value to the actual media, it tests only the constant and filename, which no means of ensuring it meets my pattern.
So...does anyone have any ideas to make this (or something similar) work?
I'm thinking what I'll probably need to do is parse instead for the base URL (subdomain or subdirectory) and use a hash of that instead of the blog_id. The problem with that? It's going to seriously cause issues with back-end media management and frankly, just moving it over to the new directory structure.