On Jan 29, 2010, at 11:53 AM, Ken Winters wrote:
Where possible, do everything in code rather than the database.
Right. Have a look at Features. It helps you export configuration to code and manage it. It does this by relying on other module's export APIs. If you're building a module with configuration options, take a look at CTools/export API for making them exportable. Using CTools/ export is best practice for exporting ATM, IMO. http://drupal.org/project/features http://drupal.org/project/ctools
Trying to merge two databases is a giant pain, but pushing new code and running update.php is fairly painless.
If you do have to make database changes after the client has already entered data, you'll want to script it (often using an importer).
- Ken Winters
On Jan 29, 2010, at 11:47 AM, Stewart Birch wrote:
Hello all
very early on in my Drupal learning process but have been asked to come up with a solution where the client will be entering content on the production site and we may very well be making structural changes ( css etc ) on DEV and changes to the site setup ( for example a page name or somesuch ) , is there a way to seperate the data entered for content types from everything else so when deploying a site to production we can do so without worrying about content being lost.
Thanks
Stewart
Alex Barth http://www.developmentseed.org/blog tel (202) 250-3633