Posted by btmash on April 9, 2010 at 12:06am
Hi everyone,
I am working on a site which will, more likely than not, use the domain access module to manage content across the primary and subdomains and one question I had is how do you migrate a site that may be set up on dev.domain.com (and subsequent test.dev.domain.com to *.dev.domain.com) to domain.com (and subsequent test.domain.com and *.domain.com)? Any help and/or advice on this would be really helpful.
Regards,
Ashok
Comments
Do you mean once Domain
Do you mean once Domain Access is installed and the dev.example.com and www.example.com domains are set up?
I typically use symlinks & Drupal multisite capabilities for dev
I typically use symlinks & Drupal multisite capabilities for development & staging.
Ok, so I'm not positive what you're asking. seems your concerned with location of files on different servers. if not, probably quit reading now. ;-) I also haven't used domain access module... so again, you might consider the rest of this pointless... that said, and if I do happen to understand what you're trying to accomplish I'll build on your example
I'd have a "sites" directory that looks similar to this
sites/
sites/domain.com (a typical drupal folder which resolves for the production host and contains typical settings file & files/module/theme folders, etc)
sites/domain.com/settings.php
sites/domain.com/files
sites/domain.com/modules
sites/domain.com/themes
ok, nothing new so far. but here's where it gets interesting
sites/domain.localhost (same as above except this folder name obviously resolves on my local setup. therefore, I need a unique settings file for my workstation. now the fun part that makes it all work, everything else in this folder are symlinks to the folders in production-domain.com)
sites/domain.localhost/settings.php <-- just a file. unique for localhost
sites/domain.localhost/files <-- symlink (to above files folder --> sites/domain.com/files)
sites/domain.localhost/modules <-- symlink
sites/domain.localhost/themes <-- symlink
sites/dev.domain.com (same story. settings file unique for said host. everything else is a symlink to the folders in production-domain.com)
sites/test.dev.domain.com (same story. settings file unique for said host. everything else is a symlink to the folders in production-domain.com).
sites/ etc., etc., etc.
What this allows is for the files / theming / modules folder to always resolve to the production domain folder. e.g., sites/production-domain.com/files is valid regardless of the development or staging environment. and therefore any configuration in Drupal (configuration > File System) is always valid. Hope it helps
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Symlinks and the Systems Table
Hi Mike...
I love this idea of using symlinks and I really want to try and make this work. I find that it works for files uploaded into the sites/domain.com/files folder and saved correctly in the corresponding Files table, but not for the sites/domain.com/modules or sites/domain.com/themes folders that get saved in the Systems table. I'm wondering what's different about my setup and yours. The symlink setup is exactly the same. So I'm wondering if...
...maybe my virtual hosting is set up differently than yours? I'm on Ubuntu Linux and my hosts file contains the line: 127.0.1.1 domain.localhost and my host file looks like this:
...maybe you're mechanism for saving those themes and modules in the folders is different than mine? I simply cut and paste or use a drush make file. I suppose if you save your themes and modules into their respective folders before you create the symlink and install the site before you create the symlink, then the path will be correct for an initial install. But, once you create the symlink and use the domain.localhost to browse to your local site, even with the symlink, Drupal stores the domain.local path in the Systems table for any new modules and themes saved, at least for me.
What am I missing?
Any insight would be appreciated. Thanks in advance. :-)
-- lynn taylor
I guess I wasn't very clear
Sorry I wasn't very clear on this. Under typical multisite circumstances, I understand setting up a multisite and migrating content out from a dev environment into staging and eventually production (if the project requires it). In this scenario, its as christefano has described it:
1) Have a development site with the domain access module installed.
2) Migrate the content from development site to staging site.
So let's say as part of my development site dev.domain.com, I also had the domain access module set up to work with subsite1.dev.domain.com, subsite2.domain.com, ....subsiteN.domain.com
Now we introduce the staging and production servers (staging would consist of stage.domain.com, subsite1.stage.domain.com...subsiteN.stage.domain.com while production would be domain.com, subsite1.domain.com...subsiteN.domain.com)
So the content was created on the stage site (and pointed towards its appropriate subsites) and the time has come to make the site go live (thus out of the staging domain and into the production domain).
What are general practices to then move that structure (and possible content) over from the development domains over to stage/production? Would you set up domain aliases or is there something else that must be done during the db migration process?
I should have known you
I should have known you weren't asking an obvious question. So, now I'm not suggesting I have an answer. Mostly just that I'm curious about it now, and this is my thought process.
After reading your last post I'm still not sure I'm clear on your concerns, beyond searching for the typical Drupal holy grail of dev/stage/deploy?
As I understand it, domainaccess module allows multiple domains to share the same drupal database (users/content/configuration). What data are you concerned with as you push from stage to production? just content? just configuration?
I'm sure domainaccess is more sophisticated in approach, but in a nutshell it seems to me that it introduces new URL rewrite capabilities, for domains. It also provides user access based on those new URL rewrite capabilities. So it seems like you can treat development, staging, deployment, in the same way you do for a typical drupal site.
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
With Domain Access, all the
With Domain Access, all the domains are running in one Drupal instance. This means that you can move content from dev to staging to production by clicking a checkbox on the node edit form. It's not possible to move structural changes from one domain to another since all domains share the same structure in the database. An exception is if you use Domain Prefix, where specific domains can use their own tables for blocks, content types, etc. but that module doesn't provide a mechanism for deploying changes between domains.
In other words, Domain Access is great for moving content from one domain to another. It isn't good for deploying structural changes. The same can be said for Organic Groups.
Multiple Domains
To broaden this -- would it be possible for you and Mike to give a presentation about using multiple domains with one code set at an upcoming LA Drupal meetup? I believe you've said there's more than one way to go, Domain Access being one, and here you mention Domain Prefix. The pros and cons, etc.
Also, more about specifying which tables to share.
Love your presentations!
Susan
Sure! Is there anyone in the
Sure! Is there anyone in the LA Drupal community that would like to do this? I'm happy to do it and Mike probably is, too, but we just presented at the last meetup and I'd love to hear from someone who hasn't presented before (or hasn't presented in a while). I think we can definitely do it if there aren't any volunteers.
Just keep in mind that Domain Access is not the same as Drupal core's multi-site. Each approach appears roughly the same from a visitor's point of view but it's very different from the developer's point of view. Domain Access uses one Drupal codebase and one database while Drupal core multi-site can use one codebase and multiple databases. It can also be set up for multiple codebases and one database, which is useful to people stuck on shared hosting who have limits on how many databases they're allowed to use.
Also, Drupal core multi-site can be configured for shared tables between multiple codebases in order to do interesting things like single sign-on. Wth Domain Access, all database tables are shared automatically and node_access and user_access are used to determine who can see what content.
I don't mind presenting/copresenting on drupal and multisite.
I'd be quite happy to help present on this aspect. I've gone through the somewhat standard set of multisite installations, sites with limited shared information, and now sites with more specific needs :)
Anyways, regarding the question. To address what Mike asked, it was regarding content migration. For content type migration across the various sites, I was thinking of deploying the site using the features module so at the very least, core settings we want the site to deploy with (content types, views, and image cache presets). I will likely use the strongarm module as well to getting variable presets so that should hopefully go over smoothly. The environments for dev, stage, and production are separate (dev and stage are separate databases while production is an entirely separate server). I haven't been able to find much help on the matter quite yet so for now, I will likely run a script that goes through the file for a search/replace to change stage.domain.com to domain.com (and subsite1.stage.domain.com to subsite1.domain.com and so on). If I find anything else regarding migrating a site, I'll post it here (or talk about it in a presentation :))
Partial answer in domain project issue queue.
I decided to ask the same question on drupal.org and agentrickard provided a nice answer at http://drupal.org/node/766970.
I've opted to try and make a somewhat openended module which will help facilitate what he responded to me with and will update with what happens.
Answer resolved :)
Ken Rickard (agentrickard) gave me some excellent advice at http://drupal.org/node/766970 and I've posted my solution to the issue there as well. While the final site I deploy will still need to have some level of search/replace (need to find a nice way to post links to nodes without them getting stuck with a domain), the code in the above link should help with doing a migration of content from dev to stage to eventually production IFF you are using the domain access module.
Thank you to all that were trying to help me :)
Thanks so much for coming
Thanks so much for coming back to this thread sharing! Question. Answer. Plus code. Above & beyond! Awesome!
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Enabling multisite search
I've set up my multisite installation and now want to enable searching throughout my domain/subdomains.
Christefano pointed out you can put the tables in the settings.php file to search across. What is the format -- any chance you can paste in an post answer the code from that section of your settings.php file as an example?
Is the core search powerful enough for this, or do I need to go to Apache Solr or Lucerne Search? From the documentation/forum discussions, it seems none of the modules for multisite search are out-of-the-box ready. For example for the Apache Solr Multisite Search, it clearly says "Also - don't expect it to really work yet."
Would I create a search block on my primary site and then enable it on the child sites? Also, I'd like to create views where a child site only searches in selected subdomains -- can I grab which subdomains selectively in Views?
Guys, be gentle, I'm learning...
Susan
I'll take a stab at this
I'll take a stab at this answer (and I look forward to being told off on being completely wrong!). It is an excellent set of questions.
First off, are you using the domain access module to set up your multisite installation or are you doing a more typical multisite installation (separate sites defined in the sites directory)? It might help more with an answer to your question. Specifically with search, you don't have to change anything and all results will go to one specific table for all your domains.
Regarding table prefixing in settings.php, you should see
$db_prefix = '';. You would change that to be something like$db_prefix = array('default' => '<whatever your default table prefix is supposed to be...more likely than not, it remains blank>'
'shared_table_name' => '<whatever that table should start with>'
);
For the shared table, if you are sharing that table from another database (let's call that database db1), it could be something like 'db1.' so the database looks inside that database. Otherwise, it would be the prefix that table starts with (it is decently explained at http://drupal.org/node/147828).
Jeff Eaton best described core search as 'the best non-commercial open source PHP implementation of search that you will find included with a CMS. But that doesn't really say much". In your example, it will most likely work (especially if you are using the domain access module), but the search results are likely to be somewhat poor. Again speaking from using domain access and seeing some of the issues queue that Ken Rickard has answered, you can have results come in from specific domains (domain access has hooks that would help you out in accomplishing exactly this - I do not know the code off the top of my head but Ken has stated it is possible).
For views...again, this whole process is quite easy if you are using the domain access (and domain views) module. The only caveat to all this is that your content has to be published on both sites. You may, however, opt have one site be a source domain for the content and view all other views on your site only show the content source be that particular domain.
Let me know if that helps answer your questions.
search across subdomains
Thanks for such a complete answer -- this totally helps. I would love to use Domain Access with all its features, but I'm still on a shared host, so I could only do Multisites.