[wp-trac] [WordPress Trac] #11742: MU isn't fully compatible with custom content dir

[WordPress Trac]

#11742: MU isn't fully compatible with custom content dir
---------------------------------+------------------------------------------
 Reporter:  Denis-de-Bernardy    |        Owner:          
     Type:  defect (bug)         |       Status:  reopened
 Priority:  normal               |    Milestone:  3.0     
Component:  Upload               |      Version:  3.0     
 Severity:  major                |   Resolution:          
 Keywords:  multisite has-patch  |  
---------------------------------+------------------------------------------

Comment(by wpmuguru):

 Replying to [comment:40 westi]:
 > Is there not a middle ground here which can give us the best of both
 worlds?
 >
 > Make the wp-content/blogs.php solely issue redirects to the preferred
 url.
 > Ensure that ms-files.php is suitably over loadable to allow people to
 implement the kind of different stuff they are doing in blogs.php at the
 moment.
 >
 > Can someone summarise how blogs.php is currently intended to be used so
 that we can better understand the upgrade implications?

 The blogs.php that was removed was a shell file that loaded ms-files.php.

 My issue/concern is not with removing blogs.php from trunk. As long as we
 can come up with a way to allow the MU installs to upgrade without
 deleting the blogs.php from the MU installs. Blogs.php from MU 2.9.X and
 ms-files.php from trunk are functionally identical, so the admin message
 saying that it's been deprecated isn't necessary in 3.0.

 Prior to the patch being committed I suggested using something like a
 svn:ignore. Is it possible to build into the zip process a switch on that
 particular file so that it does get distributed to MU installs but not to
 WP installs?

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/11742#comment:50>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software