Making a subsite the main site – staging

Is this a multisite question? It sounds like these are simply two separate sites, installed in separate places (separate directories or separate servers), and when the time comes you will point mydomain.com at wherever the new site is.

So are you just sending content back to the main site?

Rod: I wish it were that. : ) This is a multisite issue – running 3.3.

Andrea: The core issue is that there is a team “redesigning” the main site – so in addition to content, I’m dealing with widgets, plugins, layout issues (same theme, but I use a framework system), etc. Typically on multisite installs I work with a local version (running MAMP) and change my local host file so that I don’t need to deal with any domain name changes in the database (my type of work deals with small multisite installations that are specific to some specialized content publishing – rarely with more than a dozen or so subsites).

When doing these sorts of redesigns, I need to have a non-local install to which various people can contribute. Moving content is easy enough, but it is all of the extra stuff.

I’m curious if there are any suggested methods for replacing these types of elements on the main site, with the product of a “staging” subsite.

I should also mention, that I’m dealing with a non-technical group – so solutions that would include code repository check-in, check-out and that sort of thing would likely be a non-starter for them.

So perhaps the question is really whether the main site can have a blog ID other then 1. If it can, then you can use a new site in the network for the design work, and when the time comes you can change the domain and path settings of the old and the new site so that mydomain.com goes to the new one, whatever its blog ID. You could try doing that in a local test network to see if anything bad happens.

I’m curious if there are any suggested methods for replacing these types of elements on the main site, with the product of a “staging” subsite.

I should also mention, that I’m dealing with a non-technical group – so solutions that would include code repository check-in, check-out and that sort of thing would likely be a non-starter for them.

For a project like that, if it were only one total site in the end, I woudl not use multisite to make a dev /production.

So perhaps the question is really whether the main site can have a blog ID other then 1.

Yes it can, and Ipstenu has written some posts about how it ultimately gets a little snarly.

Thanks, Andrea. Unfortunately, this is a true multisite environment, where there are about a dozen existing production subsites in addition to the existing primary.

My hope was that there was a straightforward solution to having a staging subsite that could be “easily” migrated to replace the primary site. I’ll search on Ipstenu’s posts and see about the issues regarding the blog ID. And if I come up with some magic method, will post back. Thanks again, all.

One other thought: Is there any way to (or danger in) manipulate the htaccess file so that the primary (mydomain.com) actually points to a subdomain (staging.mydomain.com). I suspect that would start getting into some complex things that could easily go sideways, but…

Hi airfoil, you could try the DeployMint plugin, I haven’t got round to using it myself yet but I heard about it a while ago and it sounds like it might cater for what you’re trying to do:

https://markmaunder.com/2011/08/19/deploymint-a-staging-and-deployment-system-for-wordpress/

My hope was that there was a straightforward solution to having a staging subsite that could be “easily” migrated to replace the primary site.

multisite is not the use case for this.

Nickyboy: Thanks – I’ve looked at DeployMint, but it really only deals with content, and doesn’t address architectural changes such as widgets, sidebar content, etc.

Andrea: Thanks. It seems clear that a multisite deployment is not an easy thing for staging. In our scenario, we have marketing and other stakeholders who need to contribute to a redesign. Since the only decent way to deal with this currently (from my experience) is to have a local install, I use MAMP and manipulate the hosts file so that things can be migrated easily without having to deal with changes to the domain name. Unfortunately, this means everything needs to funnel through a single point, and does not make it easy for a team to contribute. Really inefficient. The other approach I’ve used is the WordPress Search and Replace Tool. Since it accounts for serialized strings, it is a great, great thing for multisite developers. However, I still get a little queasy running this against a big database, fearing something will go sideways. I’ve done it, and it seems to work really well. But…

My real wish is that WP would not rely on having the FQDN embedded into the core data.

Out of curiosity, from your extensive experience in this area, is there some technical reason that the WP development team deals with things in this way, rather than using some sort of variable scheme in place of the primary domain name?

Check out how these guys do it: https://scotty-t.com/2012/01/18/wordpress-in-dev-qa-and-prod/

Ipstenu: Wow. A lot to digest, but a remarkable resource. In particular, the Output Buffering section. Not sure I fully have my head around it, but definitely gets me going in the right direction. Thanks.

is there some technical reason that the WP development team deals with things in this way, rather than using some sort of variable scheme in place of the primary domain name?

No idea – that was set up before my time. ?? I do know Mark would like to change this so it doesn;t save that info in so many freakin’ places, but it’s not even on the roadmap (I don;t think).