Make WordPress Core

Opened 14 years ago

Closed 14 years ago

#12931 closed defect (bug) (fixed)

Upgrading a Single Site install to MultiSite Install with Subdirs is not safe

Reported by: nacin's profile nacin Owned by: nacin's profile nacin
Milestone: 3.0 Priority: high
Severity: blocker Version: 3.0
Component: Multisite Keywords: needs-patch
Focuses: Cc:

Description

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.”)
  1. Proper redirection to the new /blog URLs, which is more or less impossible for cases when MS catches the URL first.
  1. 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.

Change History (16)

#1 @westi
14 years ago

Plan from dev chat:

westi: I would go for sticking with the /blog for now
westi: Blocking / Strongly recommending against (at a UI level) subdir conversion for existing sites
westi: Improve in 3.1

Solution Must (Some test cases ;-) ):

  • Support upgrade from existing subdir mu installs
  • Support conversion to subdir multisite for a new 3.0 install
  • Block conversion to subdir multisite for a pre 3.0 single site install which is upgraded.

#2 @nacin
14 years ago

  • Owner set to nacin
  • Status changed from new to accepted

Thanks westi for setting up this ticket. We can simply block subdirectory installs when the install is new, explain why, and provide for an override. We would do this in Tools > Network (network.php). That would satisfy the test cases.

I think using a second constant for the override is fine. Additionally, I would think an easy way to define a new install would be 3 > SELECT MAX(ID) FROM $wpdb->posts. Thoughts before I proceed?

#3 @westi
14 years ago

Sounds reasonable - I would rather we provided a filter on the result of the check than added another define.

Someone can enable the upgrade easily with a mu-plugin then and we don't gain another pretty useless constant

#4 @wpmuguru
14 years ago

If allow_subdomain_install() returns false we should allow a subdir install because those will be local/dev installs.

Also, we could compare the MIN post_date with the current date and if the difference is less than something like 2 weeks then don't block a subdir install.

#5 @wpmuguru
14 years ago

(In [14513]) add network install rule, filter & UI tweaks, see #12931

#6 @wpmuguru
14 years ago

(In [14514]) add subdomain explanation to network install, see #12931

#7 follow-up: @gazouteast
14 years ago

  • Cc gazouteast added

Block conversion to subdir multisite for a pre 3.0 single site install which is upgraded.

Problem - when the single site install is in the hosting space root and is the hosting account domain name, with add-on domains in subdirectories of the hosting root that have their own domain name.

example =
/public_html/root_domain
/public_html/root_domain/addon_domain1
/public_html/root_domain/addon_domain2
Where root_domain.com + addon_domain1.com + addon_domain2.com are all valid domain names with their own sites (not domain mapped subdomains).

the root_domain could be DNS wildcarded for a subdomain install, I have done it at least once that I recall, but hosting services fight it tooth and nail and I've started seeing it as a prohibited activity in terms and conditions from some of them (alongside using WP caching plugins being prohibited at some too).

Blocking sub-directory network conversions for hosting root directory existing installs will effectively block those sites from upgrading to multi-blog. A workaround needs identified and supplied.

Gaz

#8 @nacin
14 years ago

I'm confused by your setup there. I understand the practice of add-on vs. root domains, but I don't see how that has an effect here.

We're blocking a single-site install that has existed for some time from being converted to a subdirectory network, as the root blog will be forced to use the /blog/ prefix.

#9 in reply to: ↑ 7 @wpmuguru
14 years ago

Replying to gazouteast:

Blocking sub-directory network conversions for hosting root directory existing installs will effectively block those sites from upgrading to multi-blog. A workaround needs identified and supplied.

You can add a simple plugin to override the block: hook the allow_folder_install filter and return a true. See [14513].

#10 @jlevandowski
14 years ago

I'm using 3.0-beta2-14676 and if you go to permalink settings and just click Save Changes without making any changes it appears to fix this problem. So maybe it's just something to tell users switching to multi site to do.

#11 @wpmuguru
14 years ago

RE: comments in puntup. If the owner installs a single install and edits the existing posts/pages that will create post revisions, etc. Blocking a folder install after a week or two is reasonable. Blocking a folder install where the owner has poked around a bit is a little draconian.

#12 follow-up: @nacin
14 years ago

Okay, so we ignore post_status = inherit perhaps.

They can add the filter. We don't want people to publish 3 posts and then break those links without them knowing what they're doing 100%.

#13 in reply to: ↑ 12 @wpmuguru
14 years ago

Replying to nacin:

Okay, so we ignore post_status = inherit perhaps.

They can add the filter. We don't want people to publish 3 posts and then break those links without them knowing what they're doing 100%.

With what you are proposing, someone can install, tweak the install for 3 months and turn on the network with a folder install as long as they have not pushed the publish button. Alternatively, if they write a "This is my new site" post or they create posts/pages to set up the new custom menu feature, they need to add a plugin to do the same.

Philosophically, it seems a bit out of sorts for a publishing platform to make things more difficult for the people who have an immediate interest in publishing content over those who don't.

If the site is less than a month old, some people may have to update a link or two, but they will get over it.

#14 follow-up: @nacin
14 years ago

If the site is less than a month old, some people may have to update a link or two, but they will get over it.

But they need to *know* fully that they are changing their blog. They need to confirm their actions in the opt-in affirmative. My proposal is that they should be required to add a filter in that case. If they can't add a filter, it's the same deal with constants -- then they shouldn't be running multisite in 3.0.

I am quite literally proposing that if it is not a completely empty install, then they may not install subdirectories, unless they trash all of their posts or add a filter.

#15 in reply to: ↑ 14 @wpmuguru
14 years ago

Replying to nacin:

But they need to *know* fully that they are changing their blog. They need to confirm their actions in the opt-in affirmative. My proposal is that they should be required to add a filter in that case. If they can't add a filter, it's the same deal with constants -- then they shouldn't be running multisite in 3.0.

The only thing your proposal confirms is that it's an empty install. It does not confirm that anyone knows anything. Example way around the filter (current or proposed):

  • Export posts, do a fresh install, enable the network, import posts

Replying to nacin:

I am quite literally proposing that if it is not a completely empty install, then they may not install subdirectories, unless they trash all of their posts or add a filter.

The only significant difference between what's currently in place and requiring an empty install is for people who are novice to WP and are planning on having a network when the site goes live. In that instance, what's currently in place allows them a month to get familiar with WP before turning on the network and extra admin screens. What you are proposing is push them to immediately enable the network after installing without stopping to learn anything about WP.

I understand (and appreciate) what you are trying to do. What's currently in place will prevent anyone with an established site from enabling the network until they do a bit of research. To novices, what you are proposing will make WP more confusing & intimidating.

#16 @nacin
14 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [14884]) Improved mayday calls in network.php when a subdirectory install isn't allowed. Also, /allow_folder_install/allow_subdirectory_install/g. fixes #12884, fixes #12931.

Note: See TracTickets for help on using tickets.