Opened 15 years ago
Closed 15 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)
Change History (40)
#3
@
15 years ago
Some quick notes for the devs that work on this from my personal script I've used before:
- rename following tables from base prefix to base prefix + '1_': 'comments', 'comment_replies', 'links', 'pollsa', 'pollsip', 'pollsq', 'postmeta', 'posts', 'term_relationships', 'term_taxonomy', 'terms'
- update user meta_key wp_capabilities to wp_1_capabilities
- if default 'admin' user doesn't exist, add users with 'admin' role to 'site_admins' option
- figure out which plugin tables may need to be renamed (not sure how you would do this)
#4
@
15 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.
#5
@
15 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.
#6
follow-up:
↓ 8
@
15 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!"
#7
@
15 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.)
#8
in reply to:
↑ 6
@
15 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?
#9
follow-up:
↓ 10
@
15 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.
#10
in reply to:
↑ 9
@
15 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.
#11
@
15 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.
#13
@
15 years ago
http://core.trac.wordpress.org/changeset/12757/trunk should have referenced this ticket as well.
@
15 years ago
Improvements to queries in populate_network(), also gettext. Matches up / fixes a string in ms-functions.php
#17
follow-up:
↓ 18
@
15 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.
#18
in reply to:
↑ 17
@
15 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.
#19
@
15 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.
#25
in reply to:
↑ 24
@
15 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.
#34
follow-up:
↓ 35
@
15 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..
#35
in reply to:
↑ 34
@
15 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.
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.