WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#11816 closed enhancement (fixed)

Users should be able to switch from a standard single install to a Multi-Site Install

Reported by: jorbin Owned by: nacin
Milestone: 3.0 Priority: normal
Severity: normal Version:
Component: Multisite Keywords:
Focuses: Cc:

Description

As per the dev chat on 7 jan 09. We want to make it easy for users to move to a MS enviorment.

Attachments (2)

11816.diff (11.7 KB) - added by nacin 6 years ago.
Improvements to queries in populate_network(), also gettext. Matches up / fixes a string in ms-functions.php
11816.2.diff (1.6 KB) - added by nacin 6 years ago.
Some fixes for r12880

Download all attachments as: .zip

Change History (40)

comment:1 @PeteMall6 years ago

  • Cc PeteMall added

comment:2 @jorbin6 years ago

  • Cc jorbin added

I think one of the things that needs to be decided is if we want to have the script be one that is accessible from the backend or if we want it so that you have to visit a page(wp-admin/upgrade-to-ms.php ?), or if just defining a constant in wp-config.php will cause the next admin to login to be directed to a special page since users will need to set options such as subdomains vs. subdirectories etc.

comment:3 @prettyboymp6 years ago

Some quick notes for the devs that work on this from my personal script I've used before:

  1. rename following tables from base prefix to base prefix + '1_': 'comments', 'comment_replies', 'links', 'pollsa', 'pollsip', 'pollsq', 'postmeta', 'posts', 'term_relationships', 'term_taxonomy', 'terms'
  1. update user meta_key wp_capabilities to wp_1_capabilities
  1. if default 'admin' user doesn't exist, add users with 'admin' role to 'site_admins' option
  1. figure out which plugin tables may need to be renamed (not sure how you would do this)

comment:4 @themattharris6 years ago

  • Cc matt@… added

I think there should be an admin interface. at least explaining whats going to happen and (at least) reminding the admin to backup everything.

I'm thinking in a similar way to WordPress upgrades. Such that the site continues to work as is until the admin hits wp-admin. Then they get prompted about moving to multi-site.

comment:5 @wpmuguru6 years ago

  • Cc wpmuguru added

At this time, not all of the MU code has been added to trac. The files I added ealier this week were the files in MU that don't exist in WP (some were files that hadn't been removed from MU as they had in WP). There are a handful of files that are different between WP and MU. That code is not in trunk.

comment:6 follow-up: @filosofo6 years ago

This needs to be easily done or noisily forbidden for regular users. It's guaranteed that countless people will think, "all I have to do is set this constant and I can turn my site into wp.com!"

comment:7 @johnjamesjacoby6 years ago

  • Cc johnjamesjacoby added

Does it make sense to leave the original wp_ tables and just copy them with new wp_1_ prefix? Renaming is lighter, but potentially destructive. (Thinking along the lines of trash and/or undo if it borks.)

comment:8 in reply to: ↑ 6 @themattharris6 years ago

Replying to filosofo:

This needs to be easily done or noisily forbidden for regular users. It's guaranteed that countless people will think, "all I have to do is set this constant and I can turn my site into wp.com!"

I think so too. So maybe, on the screen that gets displayed a cancel option is presented or something like that. Come to think of it would it make sense to also provide a 'not yet' option to allow admins into their site without running the upgrade at that time - and instead display an admin notice reminding them it's a pending action? Same with those who cancelled.

Replying to johnjamesjacoby:

Does it make sense to leave the original wp_ tables and just copy them with new wp_1_ prefix? Renaming is lighter, but potentially destructive. (Thinking along the lines of trash and/or undo if it borks.)

Potentially with large sites I could see this leading to problems. Duplicating the table and all the meta information maybe too much for a single request (and some dbs) - although I have to admit i've not attempted it before so this could be a false statement. Renaming is also not that destructive. If it breaks then would we not rename back, and if really borked, use a recovery script that renames the tables back?

Is there any mileage in not changing the table names and having the core code instead use a 'first_site" prefix? Such that wp_posts works for single sites and as site 1 for multi-sites - and then subsequent sites get named wp_2_ and wp_3 etc. Just a thought?

comment:9 follow-up: @wpmuguru6 years ago

I'm not expecting to rename any tables or run queries on the database. I'm starting on the database class tomorrow and we'll see how far things are by the end of the weekend.

comment:10 in reply to: ↑ 9 @wpmuguru6 years ago

Replying to wpmuguru:

I'm not expecting to rename any tables or run queries on the database. I'm starting on the database class tomorrow and we'll see how far things are by the end of the weekend.

Sorry - other than the extra MU/multisite tables need to be created.

comment:11 @wpmuguru6 years ago

Now that I've had a bit of a break-

There were 2 conversations going on about conversion scripts. It wasn't clear who was talking about what. Up until Jane asked about a script, I thought people were talking about merging separate WP installs into a single multi-site install. From the dev chat:

"<Jane_> merge: donncha and wpmuguru are obvisouly already involved, anyone else? if any 2 people would want to collaborate on that script to go from single to multi, that would be cool
<scribu> miqrogroove: ain't it awesome :D

miqrogroove: </sarcasm>

<wpmuguru> Jane_: I have that"

I apologize that I didn't catch the jist of it earlier in the chat due to the confusion.

comment:12 @sirzooro6 years ago

  • Cc sirzooro added

comment:13 @wpmuguru6 years ago

http://core.trac.wordpress.org/changeset/12757/trunk should have referenced this ticket as well.

comment:14 @wpmuguru6 years ago

Related ticket: #12021

comment:15 @sillybean6 years ago

  • Cc steph@… added

@nacin6 years ago

Improvements to queries in populate_network(), also gettext. Matches up / fixes a string in ms-functions.php

@nacin6 years ago

Some fixes for r12880

comment:16 @wpmuguru6 years ago

(In [12883]) block multisite enable on localhost and ip address, see #11816

comment:17 follow-up: @freddyware6 years ago

I don't suppose blocking the ordinary dotted IP addresses blocks the integer representation, which makes it into a single number without any dots/separators.

Then again, most people probably won't use integer IP addresses, so this might be a non-issue.

comment:18 in reply to: ↑ 17 @wpmuguru5 years ago

Replying to freddyware:

Then again, most people probably won't use integer IP addresses, so this might be a non-issue.

Multisite does not work correctly on an IP address, that's why it's being blocked.

comment:19 @nacin5 years ago

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

Taking this one per the dev chat.

Going to refresh 11816.2.diff first and get that in, looks like there's some stuff in there that is still worth it.

comment:20 @nacin5 years ago

(In [13610]) Move $base sanity check to from MS config template to ms-settings. see #11816

comment:21 @nacin5 years ago

(In [13611]) More network.php refinements. Bring wp-config and htaccess inline. Rename BLOGID_CURRENT_SITE to BLOG_ID_CURRENT_SITE for consistency with SITE_ID_CURRENT_SITE. see #11816

comment:22 @nacin5 years ago

(In [13613]) Remove htaccess.ms and wp-config.ms templates. These were brought inline in [13611]. see #11816

comment:23 @nacin5 years ago

(In [13614]) Add nag for missing authentication keys in network.php. See #11816

comment:24 follow-up: @wpmuguru5 years ago

Test install went fine for me.

comment:25 in reply to: ↑ 24 @nacin5 years ago

Replying to wpmuguru:

Test install went fine for me.

Do we still have a desire for wpfs in 3.0? So far, I've been laying the groundwork for the fallback/manual route, and it seems ready for wpfs if we're inclined.

Adding constants to wp-config.php is easy, but given WP_ENABLE_MULTISITE, it doesn't seem like a required feature for us to do this automatically.

Updating .htaccess is a Good Idea, but we should bring the rules into core better so we can use the existing functions (which, incidentally, doesn't use wpfs).

wpfs procedure would be:

  • Back up wp-config.php.
  • Add constants.
  • back up .htaccess.
  • Add rules to .htaccess.
  • wp_remote_get() the blog to make sure we didn't 500 the server.
  • (Revert if we did.)
  • Add blogs.dir.

comment:26 @nacin5 years ago

(In [13622]) Allow localhost in a multisite subdirectory install. More network.php improvements. see #12457 for localhost. see #11816

comment:27 @automattor5 years ago

(In [13633]) Jump right to network.php step 2 when an existing network is present. see #11816

comment:28 @nacin5 years ago

(In [13634]) Rename WP_ENABLE_MULTISITE to WP_ALLOW_MULTISITE to minimize confusion. Prevent direct access to network.php without the constant unless the install process was already started. see #11816 for network.php. see #11644

comment:29 @nacin5 years ago

(In [13637]) Check and error out on port numbers in Tools > Network, which aren't allowed in multisite. see #11816, see #11644

comment:30 @nacin5 years ago

(In [13638]) Expose a read-only network.php once multisite is enabled, to ensure access to original configuration such as rewrite rules. see #11816

comment:31 @nacin5 years ago

(In [13641]) Correct subdomain handling in network.php. Pass around boolean values instead of 'yes' and 'no'. see #11816

comment:32 @nacin5 years ago

(In [13642]) Store subdomain/subdirectory choice in sitemeta. For now, only used in case we return to network.php without constants. see #11816

comment:33 @nacin5 years ago

(In [13644]) Remove unused MU function and unnecessary separate includes file. see #11816

comment:34 follow-up: @dd325 years ago

Do we still have a desire for wpfs in 3.0? So far, I've been laying the groundwork for the fallback/manual route, and it seems ready for wpfs if we're inclined.

I'd really rather see it left for 3.1 at this stage, I was about to bring that topic up just before the menu was removed.

Removing the network menu from the default lineup has significantly reduced the number of people who will follow through with this route.

Of course, This now means that many will have to double-edit their wp-config.php files.

3.0 is the merge, 3.1 is a UX cleanup..

comment:35 in reply to: ↑ 34 @nacin5 years ago

Replying to dd32:

I'd really rather see it left for 3.1 at this stage

That's what I'm thinking as well. I'm quite pleased with how network.php has cleaned up, and I no longer see the process as a significant barrier for testing or release.

comment:36 @nacin5 years ago

(In [13655]) First pass at error handling for populate_network() and network.php. see #11816

comment:37 @nacin5 years ago

(In [13679]) Don't allow access to network.php if running an MU network. It is only for networks created in 3.0. see #11816. Also, fix MS htaccess logic, see #12136

comment:38 @nacin5 years ago

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

I'm satisfied with how this has turned out. Please open new tickets for anything else.

Note: See TracTickets for help on using tickets.