[wp-trac] [WordPress Trac] #12931: Upgrading a Single Site install to MultiSite Install with Subdirs is not safe

[WordPress Trac]

#12931: Upgrading a Single Site install to MultiSite Install with Subdirs is not
safe
--------------------------+-------------------------------------------------
 Reporter:  nacin         |       Owner:             
     Type:  defect (bug)  |      Status:  new        
 Priority:  high          |   Milestone:  3.0        
Component:  Multisite     |     Version:  3.0        
 Severity:  blocker       |    Keywords:  needs-patch
--------------------------+-------------------------------------------------
 http://wpdevel.wordpress.com/2010/04/03/suggest-agenda-items-for-apr-
 8th-2010-de/comment-page-1/#comment-5891

 I have spoken with Dion, jjj, and others about issues that arise when we
 force /blog on the root blog of a new MS subdirectory install. Say I’ve
 had a blog on WP for a long while, and now 3.0 comes out, I upgrade, and I
 decide to move to MS. So I upgrade with subdirectories, and I find that
 most or all of my old links on my main blog are now broken, because I have
 /blog forcibly prepended to my permastruct.

 This is a huge problem, and in my opinion a blocker. I’ve previously only
 thought about it so far in the context of existing MU installs, or fresh
 3.0 installs.

 I again cannot make the meetup, maybe I can be in by 5pm eastern, but I
 think this should be discussed. (jjj says he will be there.) There are a
 few things we can do to fix this:

 1. We can give them a big warning in network.php. (jjj: “Ohai! Noticed you
 may nuke your site; here’s a suggestion.”)

 2. Proper redirection to the new /blog URLs, which is more or less
 impossible for cases when MS catches the URL first.

 3. Actually implement a way to rid /blog. That means confirming that the
 path requested is a blog instead of assuming so in ms-settings.php (line
 70) by querying wp_blogs. That means page slugs cannot clash, that
 category and tag bases cannot clash, etc. We would need a unique_site_slug
 function, and if the person has %postname% as a permalink, that could work
 okay, but unique_post_slug will need to confirm it is a unique site slug
 for is_main_site(). Someone may not be allowed to register if the slug
 conflicts with an existing root blog page, I’d think. And in network.php,
 we should identify problem permalink setups. And there’s probably a lot I
 haven’t thought about yet.

 Yes, I know it is by design, but this will be seen as a major
 architectural flaw once 3.0 is out and MU gets introduced to the masses,
 whether we hide it with WP_ALLOW_MULTISITE or not.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/12931>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software