[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 nacin):

 Replying to [comment:40 westi]:
 > 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.

 That's what we had as of [13040]. It's pluggable in that they can simply
 change their rewrite rules to point to whichever file they'd like.
 Otherwise, they'd be getting updates via ms-files.php. We were all in
 agreement up to this point.

 > Can someone summarise how blogs.php is currently intended to be used so
 that we can better understand the upgrade implications?

 For some reason, it was placed in wp-content from the get-go, presumably
 because it served wp-content uploads. Some MU sites do modify it, so it's
 kind of a drop-in of sorts, but most probably don't. Those that do simply
 ignore the upstream update.

 The problem is, we still had wp-content/blogs.php as a deprecated fluff
 file, in a folder that would confuse many WP single-install users, and
 rightfully so. So I wanted to come up with a way to remove it from wp-
 content all together and point MU->MS admins to use ms-files.php.

 Of course, if they don't want to use ms-files.php, they can remove the
 action that generates the nag and they'd be all set. ryan pointed out FUD
 that could go into this and obviously we can't keep it like this.

 I see no reason to keep blogs.php for single installs, and there are
 various ways we can avoid that. My initial ideas were removing on install
 when not multisite, or moving into wp-content when we are multisite.
 Ultimately, [13514] was what I came up with.

 As a compromise, I can't imagine a link to dismiss the nag not being
 acceptable to combat the FUD.

 We're simply telling them that blogs.php is no longer getting upstream
 updates, and if they want to get upstream updates, then they should simply
 change their htaccess file to use ms-files.php instead. Allowing them to
 dismiss that notice -- instead of forcing them to rename blogs.php or kill
 a hook -- is a better idea than [13514]. They can still keep a blogs.php
 file and not bother to change their rewrite rules to something else.

 That seems like the best of both worlds.

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