Is there an easy way of finding out what db tables are changed for each module?
I'm asking because I'm trying to figure out how to deploy and maintain my website. The live version is a community website, so users will be adding content. On the development side, I'll be making changes. I need to figure out if there's a way to only deploy the setting changes to the live version, so I don't clobber data the users have added. I'd rather not put the live site into maintenance mode as I fiddle with changes, and I certainly would like to avoid making changes to the live site while its live.
My thought was that if I only make cosmetic and settings changes, and the users only make content change, they both could coexist and I could push settings changes to the live site without a problem - but I figure this is easier said than done, and I'm looking or some advice.
Thanks.
Comments
What you are describing is a
What you are describing is a LOT easier said than done and a common cause for complaint among Drupal site administrators. In theory it's possible to figure this out but any code you write to handle the problem will have to be updated every time you install a new module, create a new content type, add a field to an existing content type, make a change to use profile fields, etc.
Also, given the fact that a relatively feature-rich Drupal deployment can easily create 80+ tables in your database what a lot folks end up doing is creating a test site where they can demo config changes before making them on the live site which I understand is exactly the kind of thing you're trying to avoid.
To date I haven't seen a satisfactory solution to the "drupal doesn't come with a test/preview mode" problem. If you come across something I'd definitely be interested in hearing about it.
Deployment Module
I believe this is the purpose of the http://drupal.org/project/deploy module but whether or not it's useful right now is a wholly different issue.
Our plan is simply to not ever try to move data like this after the site is already live. To avoid it:
Ken Winters
www.coalmarch.com
Ken Winters