Ya… you don’t want to do that. You local config file will be different of course and there are a number of domain references in the DB (not thousands mind you… but more than one or two). Also, WPMU creates the config file for you upon install and you mess things up if you swap it with another.
A config file would never be kept in a repo I don’t think.
To answer your last question, it is easy to move things to other folders but everything will break :o)
Why would you ever want to mirror all those core files anyway? The only place you would be doing your own development would be within the theme.
thanks some thousands for your answer 
.
Well ,the question about the folder is crucial, because right now the production environment is under a special folder, but eventually I want to move everything under the root, but only in the late testing phase, when everything is sort out.
will it be a mess? I think it’s better if I know now, thanks.
What do you suggest me to do in case?
The site will be a community site that I’m trying to develop together with other people, so we are using SVN to share the code, but I was hoping to have the same local testing environment too, but it’s not a big deal.
It’s tricky. I agree. I might register a subdomain for staging (say dev.mydomain.com) and get everything good to go there. I would not use a folder on production. BuddyPress isn’t happy living in a folder and I think it would be more of a pain to go live. If you use a subdomain, switch the domain over to http://www.mydomain.com when you’re ready to go live. But things will have to be changed in the DB (mostly in the wp_sitemeta table but also in a few other tables I think) and in the wp-config file.
But I’m no networking genius. So don’t listen to me!!! I’m mostly a designer / html guy. Maybe others have better ideas of how to manage development.
Put your site in maintenance and do a clean install, then copy your data/theme?
If you try to copy a wpmu install with buddypress, you’ll run into a lot of problems, its ten times easier to just do a clean install.
yes, for the install I can agree, but what about a DB?
The point is that I was planning to got until beta under a subdomain (actually a sub-folder, but I agree with David Lewis), and the switch to the main domain after the beta is finished. This would mean that a lot of users would be already registered and a lot of data inserted.
Please help, I need to know this asap.
“the switch to the main domain after the beta is finished. This would mean that a lot of users would be already registered and a lot of data inserted.”
Uh, bad plan. It’s not as easy as just single WP and switching the URL in a couple places. MU stores a LOT of basic info about the blogs in a multitude of places. As you’ve seen.
hmmm isn’t this considered a problem? I run an indie game development site for 12 years now and it’s time to refresh it. But, since I’m planning to add some features that are not by default in buddypress, I can’t just switch to the default BP, it wouldn’t make any sense for most of the users. Still, I have to test the features to introduce…
…I will use a subdomain by sure now, maybe it will help a little.
At most eventually we will use a redirect 
@Xevo: Where is “maintenance mode”. Is that a plugin? Also… that would only work if you have a new domain of course (i.e. if you don’t already have an old site up at that domain which you plan on replacing)
@Andrea_r: Ya… when I suggested just switching the domain I was assuming that the only user would be the developer… that you’d just use the remote server for development, testing and content population. If you have a bunch of users in there (esp. if they are active) and then change the domain… lots of things would break after the switch… every single member profile link for starters.
I guess as far as the DB goes… it boils down to what content you need to migrate. If you migrate the whole DB from one URL to another… lots of stuff will go boom. But if you do a fresh install on the live URL and only export/import the tables with page/post content… you’d be pretty safe. Would be nice I suppose if some uber geek wrote some migration scripts. Ultimately… the easiest thing is… if you have a new site on a new domain… just develop/test/populate with it in maintenance mode.
p.s. FYI… I did once successfully change a WPMU+BP URL. So it is possible. But I was the only user and the site had basically no content and no user blogs. Unfortunately… I did not document all of the DB and wp-config changes I had to make to make this work. But it wasn’t all that bad. I think I had to change the URL in maybe half a dozen places. I used the search function in PHPMyAdmin to sniff out the old URLs.
well, if I look for the domain inside the DB I can find a lot of entries, I suppose it’s enough to change them and the config file to make everything working, still it sounds dirty.
If also done dev locally, but set my hosts file to show the live domain on my local dev site. So the only one who could see the “new” site was me. And only on my computer.
Hi you all,
well well, I’m almost there, I have installed my local xampp, I have configured the virtual host to have 2 subdomains.
I have installed the principal blog in one of these subdomain.
I have done this because it’s very likely what I’m going to do in the production server.
So instead to have installed the principal blog in the domain root I have installed in a subdomain as I said, so far so good.
Then I have create the second blog, but naturally WPMU proposed me to install it under name2ndblog.sub.domain.com. Ok I have installed it anyway, but right after, using the setup panel, I have renamed all the entry to name2ndblog.domain.com.
It worked, meaning that in this way all the DB entries have been fixed and in fact name2ndblog.domain.com works. The only problem is that, while I can login in the name1stblog.domain.com I can’t login in the second one. Both blogs have the same user shared as admin, but when I try to login the second one, nothing happens, it just reload again the login page, without any error.
Ideas?
@nig3d I have no idea if this will help but did you try clearing your cookies for the site?
@Andrea_r That is brilliant and yet so simple (editing the host file). Why didn’t I think of that!?!
I haven’t clean the cookies but I tried it on several browsers. Anyway today I’ll try to install some environment that could allow me to debug the code, it’s a good way to start to learn how to fight problems 
Set up a test environment on your local pc and create your website, plain php and theme changes can be copied easily to a new place (another server for example), just db stuff needs to be implemented later, make sure to test this on your local pc before going to your live site.
When your sure the site is running correctly on your local pc and you found out a way to copy the db stuff to your fresh installation on your local pc, make a new clean install with the same settings on your live site, remember to notice members on this before doing the upgrade. Put your site behind a htacces maintenance referral, excluding your own ip, so you can still edit and test the site, but others get to see the maintenance page. If everything goes right, you’ll have your new site running in no time.
MAKE SURE TO BACKUP THE WHOLE OLD SITE BEFORE SWITCHING TO YOUR NEW ONE!
@ David: Yes there’s a plugin for wordpress that allows you to put it in maintenance mode as well, but then there would have to be a wp installed already, the above solution just refers to a html page through htaccess.
Hello back,
yesterday I verfied that the problem is in fact due to an invalid cookie generated by the page. Now, I managed to know that just using the debug feature of phped, but since phped is a commercial software, I don’t think everybody can afford to know about errors and debug the code in this way.
What I want to know is, can WP prompt me errors when they happen? Is there a output trace system to know what is going on? When an error occurs, can WP tell me why it happened?
In fact, I don’t have enough info yet to really understand what is going on! (even if I suppose that the problem is due to the fact I have installed the main blog inside a subdomain)
