Upgrading a Single Site install to MultiSite Install with Subdirs is not safe
|Reported by:||nacin||Owned by:||nacin|
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:
- We can give them a big warning in network.php. (jjj: “Ohai! Noticed you may nuke your site; here’s a suggestion.”)
- Proper redirection to the new /blog URLs, which is more or less impossible for cases when MS catches the URL first.
- 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.